Thus said Stephan Beal on Sat, 20 Feb 2016 04:46:51 +0100:
> 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
_______________________________________________
fossil-users mailing list
[email protected]
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
