Discussion:
./src/delta.c:231: checksum: Assertion failed
(too old to reply)
Warren Young
2016-02-09 08:22:54 UTC
Permalink
I was getting this from “fossil stash” for no obvious reason:

fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned char*)0)%4==0' failed.

Rebuilding both the local repo and the master repo didn’t help. Closing the current checkout and re-opening it did.

The number of uncommitted changes was rather large, so instead of attempting to put the fresh checkout back into the pre-failure state, I just backed up my changes outside of Fossil and let Fossil overwrite the changed files. (I re-opened the repo over the top of the previous checkout rather than do all of this in a new tree.)

As a test after re-opening the repo, I deleted part of a function and stashed that, then removed it from the stash. Stashing seems to work fine now.

Here’s the backtrace from the resulting SIGABRT core dump:


#0 0x00000035fee2ffc5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00000035fee2ffc5 in raise () from /lib64/libc.so.6
#1 0x00000035fee31a70 in abort () from /lib64/libc.so.6
#2 0x00000035fee29466 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000422c72 in checksum (zIn=<value optimized out>, N=<value optimized out>) at ./src/delta.c:231
#4 0x0000000000422f4f in delta_create (zSrc=0x13e8dde0 "", lenSrc=0, zOut=0x54183f "", lenOut=0, zDelta=0x13e8cf14 "5") at ./src/delta.c:372
#5 0x00000000004237f6 in blob_delta_create (pOriginal=<value optimized out>, pTarget=0x7fffaf5dccd0, pDelta=0x7fffaf5dcd10) at ./src/deltacmd.c:40
#6 0x000000000046a833 in stash_add_file_or_dir (stashid=<value optimized out>, vid=<value optimized out>, zFName=<value optimized out>) at ./src/stash.c:126
#7 0x000000000046a9d5 in stash_create () at ./src/stash.c:195
#8 0x000000000046af08 in stash_cmd () at ./src/stash.c:494
#9 0x0000000000447e55 in main (argc=<value optimized out>, argv=<value optimized out>) at ./src/main.c:804


This was with version [b8c7af5bd9], plus the patch I recently sent to the list, running on CentOS 5.

Since I purposely did not leave my local repo in a state where I can reproduce this, I don’t know if there’s any more help I can provide in tracking this down.

When I say that this happened for no obvious reason, I mean that I can’t tie this event to a prior event. The system didn’t crash, it was working just fine prior to the error, etc. This failure just seemed to come out of the blue.

The only odd thing is that this is probably the largest stash I’ve ever attempted. 38 files changed, and coming to about 2300 lines of diffs.

(Ever gone down a rat hole, got lost, and needed to teleport back to the surface? Yeah, one of those.)
Richard Hipp
2016-02-09 11:51:10 UTC
Permalink
Post by Warren Young
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
char*)0)%4==0' failed.
I wish you could reproduce this, because that is an important
assertion and I would really like to chase this to ground.
--
D. Richard Hipp
***@sqlite.org
Stephan Beal
2016-02-09 12:04:31 UTC
Permalink
Post by Richard Hipp
Post by Warren Young
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
char*)0)%4==0' failed.
I wish you could reproduce this, because that is an important
assertion and I would really like to chase this to ground.
Out of curiosity: what is the purpose of the type cast for the 0/NULL?

i've never seen that construct before except when required for overload
disambiguation in C++.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Richard Hipp
2016-02-09 12:39:57 UTC
Permalink
Post by Stephan Beal
Post by Richard Hipp
Post by Warren Young
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned
char*)0)%4==0' failed.
I wish you could reproduce this, because that is an important
assertion and I would really like to chase this to ground.
Out of curiosity: what is the purpose of the type cast for the 0/NULL?
i've never seen that construct before except when required for overload
disambiguation in C++.
The assert() is checking to ensure that its input buffer has the
correct alignment to allow the content to be access as an array of
32-bit integers. Accessing the input as an array of integers would
work regardless on Intel, but other platforms (ARM, Sparc) have
stricter alignment requirements.

The input to checksum() should normally be a pointer to a buffer
obtained from malloc(). And such buffers should always be 8-byte
aligned (or 4-byte aligned on Windows). So I'm not sure how this is
happening. There must be some path somewhere in Fossil whereby
delta_create() or delta_apply() is called with a pointer into the
middle of an allocated buffer, rather than a pointer to the beginning
of the buffer.

Any help in tracking down that call is appreciated.
--
D. Richard Hipp
***@sqlite.org
Stephan Beal
2016-02-09 12:43:21 UTC
Permalink
Post by Richard Hipp
work regardless on Intel, but other platforms (ARM, Sparc) have
stricter alignment requirements.
i'm powering up the ARM now to try to reproduce it.

But how does the (unsigned char *) cast on the NULL pointer affect the
result of (z-0)?
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Stephan Beal
2016-02-09 12:45:06 UTC
Permalink
Post by Stephan Beal
Post by Richard Hipp
work regardless on Intel, but other platforms (ARM, Sparc) have
stricter alignment requirements.
i'm powering up the ARM now to try to reproduce it.
But how does the (unsigned char *) cast on the NULL pointer affect the
result of (z-0)?
Isn't there a danger of the compiler optimizing out that -0? Or is that the
reason for the cast?
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Richard Hipp
2016-02-09 12:48:33 UTC
Permalink
Post by Stephan Beal
But how does the (unsigned char *) cast on the NULL pointer affect the
result of (z-0)?
That was my effort to convert a pointer into an integer in a way that
is portable across a variety of compilers.
--
D. Richard Hipp
***@sqlite.org
Stephan Beal
2016-02-09 13:51:51 UTC
Permalink
Post by Stephan Beal
Post by Richard Hipp
work regardless on Intel, but other platforms (ARM, Sparc) have
stricter alignment requirements.
i'm powering up the ARM now to try to reproduce it.
Unfortunately no such luck:

i mangled 75 files (some replaced completely, some trimmed to their own
head -20/tail -10 lines) and was able to stash and unstash:

[***@host:~/fossil/fossil/www]$ f diff | wc -l
51302
[***@host:~/fossil/fossil/www]$ fst | grep MOD -c
75
[***@host:~/fossil/fossil/www]$ f stash save -m 'assert test'
REVERT test/amend.test
REVERT test/clean.test
REVERT test/cmdline.test
REVERT test/comment.test
...
[***@host:~/fossil/fossil/www]$ f stash pop
UPDATE test/amend.test
UPDATE test/clean.test
UPDATE test/cmdline.test
UPDATE test/comment.test
UPDATE test/contains-selector
...

[***@host:~/fossil/fossil/www]$ f ver
This is fossil version 1.35 [7cadfc9736] 2016-02-07 23:35:16 UTC
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Andy Bradford
2016-10-05 06:59:32 UTC
Permalink
The input to checksum() should normally be a pointer to a buffer
obtained from malloc(). And such buffers should always be 8-byte
aligned (or 4-byte aligned on Windows). So I'm not sure how this is
happening. There must be some path somewhere in Fossil whereby
delta_create() or delta_apply() is called with a pointer into the
middle of an allocated buffer, rather than a pointer to the beginning
of the buffer.
In some cases, the input to checksum(), specifically, zIn (which is
actually zOut in the caller delta_create), may not actually be obtained
from malloc(). I am able to reproduce this particular assertion with the
following:

$ touch file
$ fossil add file
ADDED file
$ fossil commit -m added
New_Version: 5c966f6fe56d2efd262865f0a504fd102bb0c078
$ fossil mv file other
RENAME file other
$ mv file other
$ fossil stash save -m renamed
assertion "(z - (const unsigned char*)0)%4==0" failed: file "./src/delta.c", line 231, function "checksum"
Abort trap (core dumped)

Given that blob_zero initializes pBlob->aData here:

http://www.fossil-scm.org/index.html/artifact/831a63c8c61dbfdb5fe629a473cd7b01104478fc?txt=1&ln=262+266

Then, stash tries to read a file that is empty:

http://www.fossil-scm.org/index.html/artifact/ced32acae9b125f723c6473f30cdfdf8b530dc37?txt=1&ln=123+126

In this case, pBlob->aData has not been allocated by malloc() because
the file was empty (file size of 0 so the blob was never altered from
its initial state). And sure enough, the address of memory for zIn (a
buffer pointing to pBlob->aData) on one invocation on my system:

Breakpoint 4, checksum (zIn=0x36127dfb "", N=0) at delta.c:226
226 static unsigned int checksum(const char *zIn, size_t N){

$ echo 'puts [expr {0x36127dfb % 4}]' | tclsh
3

Which is why the assertion fails.

I propose that blob_delta_create should use blob_materialize instead of
blob_buffer here:

http://www.fossil-scm.org/index.html/info/75ddc3687acbdb32

Thanks,

Andy
--
TAI64 timestamp: 4000000057f4a4f8
Warren Young
2016-10-05 15:04:57 UTC
Permalink
Post by Andy Bradford
I propose that blob_delta_create should use blob_materialize instead of
http://www.fossil-scm.org/index.html/info/75ddc3687acbdb32
That’s a nice bit of detective work, Andy! I can’t imagine what possessed you to keep pursuing it for 8 months, but thank you. :)
Andy Bradford
2016-10-05 19:42:47 UTC
Permalink
That's a nice bit of detective work, Andy! I can't imagine what
possessed you to keep pursuing it for 8 months, but thank you. :)
Haha, well, it was a bit less glamorous than 8 months of investigations.
:-) I was trying to get the stash-fixes branch ready to merge to trunk
and the first thing I did was create an empty file, rename it, and then
attempt to stash it. I got the assert and remembered that we hadn't yet
solved the problem, primarily because nobody was ever able to reproduce
it, so I dug up the old thread.

Thanks,

Andy
--
TAI64 timestamp: 4000000057f557db
Stephan Beal
2016-02-09 12:50:34 UTC
Permalink
Post by Warren Young
This was with version [b8c7af5bd9], plus the patch I recently sent to the
list, running on CentOS 5.
Can you post the configure/build options you used?

The trunk tests are currently running on my ARM (no idea how long that will
take), and then i'll try it out with a large stash of diffs, but it
might(?) only happen with certain build options.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Warren Young
2016-02-10 15:35:10 UTC
Permalink
Post by Stephan Beal
Can you post the configure/build options you used?
Well, you kind of nailed it. I’ve reproduced the problem thusly:

f set mv-rm-files 1
f mv foo.c bar.c
f stash

I always enable --with-legacy-mv-rm in my Fossil builds, and always set the option to make fossil mv/rm behave like POSIX mv/rm.

However, this nonstandard option is not at fault per se. This also triggers it with a default build:

mv foo.c bar.c
f mv --soft foo.c bar.c
f stash

So, the problem is trying to stash a renamed file.

If it matters — since alignment was brought up — this is a 64-bit Intel box. This program prints “8, 4” here:

#include <stdio.h>

int main(void)
{
printf("%d, %d\n", sizeof(unsigned char*), sizeof(int));
}
Ross Berteig
2016-02-10 23:48:40 UTC
Permalink
Post by Warren Young
....
mv foo.c bar.c
f mv --soft foo.c bar.c
f stash
So, the problem is trying to stash a renamed file.
Given this nice, concise, and obviously minimal script to cause fossil
stash to fail, I added it to our regression tests. First I had to create
test/stash.test which I modeled after test/revert.test since there are
huge similarities between fossil stash save and fossil revert both in
function and in output.

Two interesting results turn up from that effort.

First, I don't reproduce the assertion failure on my 32-bit Windows
build. This might not be surprising at all, it could absolutely be a
quirk of having 32-bit integers and 64-bit pointers as documented for
the OP's configuration.

Second, I don't get a stash saved at all.

My case starts from a clean checkout that has three unedited files. It does

fossil mv --soft f1 f1new

which as expected renamed the file in the repository but not on the
disk. It then says

fossil stash -m "B 2016-02-09"

which says

ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new

and does not create any stash entry.


What was fossil stash supposed to do in this circumstance? The early
test case (modeled after fossil revert's behavior) modeled the stashed
rename oddly as well, but at least it did model it.
--
Ross Berteig ***@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
Warren Young
2016-02-11 01:23:06 UTC
Permalink
Post by Ross Berteig
What was fossil stash supposed to do in this circumstance?
OP expects the stash to be as capable as bundles, differing only in where the archived data are stored and how each archive is named. (Stash IDs vs bundle file names.) If bundles can remember a moved or deleted file, the stash should, too.
Andy Bradford
2016-02-11 06:41:25 UTC
Permalink
which as expected renamed the file in the repository but not on the
disk. It then says
fossil stash -m "B 2016-02-09"
Did you mean:

fossil stash save -m "B 2016-02-09"
ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new
What was fossil stash supposed to do in this circumstance?
It marked the file as being renamed but did not change the disk, as
documented in ``fossil help mv'':

WARNING: If the "--hard" option is specified -OR- the "mv-rm-files"
setting is non-zero, files WILL BE renamed or moved on disk
as well. This does NOT apply to the 'rename' command.

Options:
--soft Skip moving files within the checkout.
This supersedes the --hard option.
--hard Move files within the checkout.


You asked Fossil to prepare the repository for a file move, but never
moved the files. Then when you attempted to stash the change, Fossil
complained because it expected to find f1new, but you never renamed f1
to f1new. If you had also then done ``fossil status'' it would have
reported f1new as MISSING.

Andy
--
TAI64 timestamp: 4000000056bc2d39
Ross Berteig
2016-02-11 18:06:54 UTC
Permalink
Post by Andy Bradford
which as expected renamed the file in the repository but not on the
disk. It then says
fossil stash -m "B 2016-02-09"
fossil stash save -m "B 2016-02-09"
Yes, typo in transcribing to email. The actual command is buried inside
test/stash.test inside a call to stash-test. (In the current checkin,
hidden inside an if {false} {} block pending this discussion.)
Post by Andy Bradford
ERROR: no such file: c:/Users/Ross/Documents/tmp/fbuild/stash/f1new
What was fossil stash supposed to do in this circumstance?
It marked the file as being renamed but did not change the disk, as
documented in ``fossil help mv'': ....
Right. "It" being fossil mv, not fossil stash save. That seems to be the
condition in which the OP reports seeing the assertion fail at
delta.c:231, which I'm trying to replicate in a test case.
Post by Andy Bradford
....
You asked Fossil to prepare the repository for a file move, but never
moved the files. Then when you attempted to stash the change, Fossil
complained because it expected to find f1new, but you never renamed f1
to f1new. If you had also then done ``fossil status'' it would have
reported f1new as MISSING.
So is this the expected behavior then?

Fossil help stash says "save the current changes... as a new stash" but
is silent about the case of a rename marked in the repo but not
completed on disk.

Since the purpose (as I understand it) of the fossil stash command is to
allow partially completed work to be set aside and recalled later, it
seems logical (and necessary) that renames are part of what it saves.

What does fossil revert do in this circumstance?

It says:

REVERT f1
DELETE f1new
"fossil undo" is available to undo changes to the working checkout.

and has now forgotten the pending rename.

I think that fossil stash save *should* do the same thing. It doesn't.

So what I'm really asking here is whether that MISSING error produced by
fossil stash save represents a bug (shortcoming at least) in the
documentation or a bug in the stash itself?
--
Ross Berteig ***@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
Ross Berteig
2016-02-11 20:38:11 UTC
Permalink
Post by Ross Berteig
What does fossil revert do in this circumstance?
REVERT f1
DELETE f1new
"fossil undo" is available to undo changes to the working checkout.
and has now forgotten the pending rename.
I think that fossil stash save *should* do the same thing. It doesn't.
I've updated the test case in stash.test to call this a knownBug.

While looking at revert.test, I noticed another interesting edge case
surrounding renames:

$ fossil mv f1 f1old
$ mv f1 f1old
$ echo "hi" > f1
$ fossil add f1
$ fossil revert

Replacing "revert" with "stash" causes SQLite to freak out:

SQLITE_CONSTRAINT: {abort at 19 in [INSERT INTO stashfile(stashid,
rid, isAdded, isRemoved, isExec, isLink,origname, newname,
delta)VALUES(1,:rid,:isadd,:isrm,:isexe,:islink,:orig,:new,:content)]:
UNIQUE constraint failed: stashf}

This is now tested in stash.test, and also marked as a knownBug.
--
Ross Berteig ***@CheshireEng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
Richard Hipp
2016-02-11 13:05:18 UTC
Permalink
Post by Warren Young
Post by Stephan Beal
Can you post the configure/build options you used?
f set mv-rm-files 1
f mv foo.c bar.c
f stash
I cannot seem to repro the problem.

Can you please run your example for me, capture the failure in a
debugger, and send a stack trace?
--
D. Richard Hipp
***@sqlite.org
Warren Young
2016-02-12 16:45:34 UTC
Permalink
Post by Richard Hipp
Post by Warren Young
Post by Stephan Beal
Can you post the configure/build options you used?
f set mv-rm-files 1
f mv foo.c bar.c
f stash
I cannot seem to repro the problem.
It seems the problem is repository-specific. I also fail to reproduce it in a fresh repository and in a different long-running (but smaller) Fossil repo I have here.
Post by Richard Hipp
Can you please run your example for me, capture the failure in a
debugger, and send a stack trace?
I ran it inside a debugger this time instead of doing a post-hoc core file analysis. Here’s the transcript, which gives a backtrace pretty much identical to the one in the initial post:


$ fossil move --hard something other-thing
$ gdb `which fossil`
(gdb) run stash save -m 'reverted file rename'
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x2aaaaaaab000
fossil: ./src/delta.c:231: checksum: Assertion `(z - (const unsigned char*)0)%4==0' failed.

Program received signal SIGABRT, Aborted.
0x00000035fee2ffc5 in raise () from /lib64/libc.so.6
(gdb) bt
#0 0x00000035fee2ffc5 in raise () from /lib64/libc.so.6
#1 0x00000035fee31a70 in abort () from /lib64/libc.so.6
#2 0x00000035fee29466 in __assert_fail () from /lib64/libc.so.6
#3 0x0000000000422c72 in checksum (zIn=<value optimized out>, N=<value optimized out>) at ./src/delta.c:231
#4 0x0000000000422f4f in delta_create (zSrc=0xbb3f60 "", lenSrc=0, zOut=0x54183f "", lenOut=0, zDelta=0xb6b4b4 "5") at ./src/delta.c:372
#5 0x00000000004237f6 in blob_delta_create (pOriginal=<value optimized out>, pTarget=0x7fffffffe330, pDelta=0x7fffffffe370) at ./src/deltacmd.c:40
#6 0x000000000046a833 in stash_add_file_or_dir (stashid=<value optimized out>, vid=<value optimized out>, zFName=<value optimized out>) at ./src/stash.c:126
#7 0x000000000046a9d5 in stash_create () at ./src/stash.c:195
#8 0x000000000046af08 in stash_cmd () at ./src/stash.c:494
#9 0x0000000000447e55 in main (argc=<value optimized out>, argv=<value optimized out>) at ./src/main.c:804


I ran the second fossil command under valgrind and didn’t get any earlier failure, so we’re probably not dealing with secondary damage due to memory corruption.

In the interest of science, I did the above tests with the same version of Fossil as originally reported, but then retested with tip of trunk, with no change.

I’ve also tested this on 64-bit CentOS 7 with a recent Fossil 1.35 build, and it reproduces with this same repository over there, too. That’s two very different glibcs and kernels, for what that’s worth. (About 7 years apart.)

I then attempted to reproduce it on OS X 10.10, but got a very different result, which I will detail in a separate email, titled “Further rename stashing oddities”. For now, just consider it “correct” with respect to the behavior expressed in the existing Fossil code.

Thinking, then, that the assertion failure might somehow be a Linux-specific thing, I tried all of this on an Ubuntu Server 14.04 LTS test VM which has never seen Fossil *or* this problem repository. Lo and behold, the problem reproduced.

To test the “Linux-specific” hypothesis, I tried it on a FreeBSD 10 box and got exactly the same behavior as on OS X.

And finally, to round things off, I tried it on a 64-bit Windows 10 machine, with both a Cygwin build from source (~3 weeks old) and the native fossil.exe v1.34 downloaded from fossil-scm.org. The Cygwin build gave the Linux behavior, while the native build gave the more correct (but still not entirely kosher) BSD behavior.


I’ve run fossil test-integrity on one of the problem Linux boxes, and it runs without error:

104007 non-phantom blobs (out of 104007 total) checked: 0 errors
low-level database integrity-check: ok


So what next? Maybe set a breakpoint somewhere in delta_create() and dump some variables?
Andy Bradford
2016-02-20 04:04:19 UTC
Permalink
i see lots of 0x7ffffff....s in there, and i happen to know that
se=... is indeed a stack-allocated object. i'm a bit surprised that
argv is, but not overly so.
Yeah, I guess it's more common than I thought and I'm not used to such
big stack values.

$ echo 16i7FFFFFFFE330p | dc
140737488347952

Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
pTarget=0x7fffaf5dccd0:

Breakpoint 4, blob_delta_create (pOriginal=0xcf7c6318, pTarget=0xcf7c6300,
pDelta=0xcf7c6330) at deltacmd.c:28
28 int blob_delta_create(Blob *pOriginal, Blob *pTarget, Blob *pDelta){
(gdb) bt
#0 blob_delta_create (pOriginal=0xcf7c6318, pTarget=0xcf7c6300,
pDelta=0xcf7c6330) at deltacmd.c:28
#1 0x146000c0 in stash_add_file_or_dir (stashid=1, vid=Variable "vid" is not available.
) at stash.c:126
#2 0x146002dc in stash_create () at stash.c:195
#3 0x14600a3a in stash_cmd () at stash.c:499
#4 0x145d48c9 in main (argc=5, argv=0xcf7c66b4) at main.c:804

Sorry for wasting everyone's time, I just noticed that there was a huge
difference in what the OP reported and what I was seeing, but clearly
there are some architectural differences that lead to a huge stack
address in some cases and I wondered if somehow the addresses were
wrong---case ignored. :-)

Thanks,

Andy
--
TAI64 timestamp: 4000000056c7e5e7
Warren Young
2016-02-20 04:31:42 UTC
Permalink
Post by Andy Bradford
Notice here that my stack has much smaller numbers pTarget=0xcf7c6300 vs
I’m on a 64-bit machine. If yours OS or executable is 32-bit, that explains it.

Also, different OSes use different defaults in how they present the address space to applications.
Stephan Beal
2016-02-20 02:01:56 UTC
Permalink
Post by Warren Young
Post by Warren Young
#5 0x00000000004237f6 in blob_delta_create (pOriginal=<value optimized
out>, pTarget=0x7fffffffe330, pDelta=0x7fffffffe370) at ./src/deltacmd.c:40
I could be wrong, but those seem like extreme memory addresses...
Anyone?
Stack-allocated. All buffers are.
--
----- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
Loading...