Re: [fossil-users] crash while running 'fossil pull' on Linux
On 8/18/2014 19:39, Eric Rubin-Smith wrote: warning: Can't read pathname for load map: Input/output error. Core was generated by `/home/eric/fossil-src-20140612172556/fossil update'. Program terminated with signal 11, Segmentation fault. #0 0xb75bffb0 in ?? () from /lib/i386-linux-gnu/libcrypto.so.1.0.0 (gdb) where #0 0xb75bffb0 in ?? () from /lib/i386-linux-gnu/libcrypto.so.1.0.0 #1 0xefcdab89 in ?? () #2 0x98badcfe in ?? () #3 0x10325476 in ?? () #4 0xc3d2e1f0 in ?? () #5 0x402a84b0 in ?? () #6 0x in ?? () That looks like a corrupted stack to me. Try running it under Valgrind. It will stop the program right where the damage occurs, rather than after the damage has propagated far enough that it's trying to escape memory protection boundaries. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] crash while running 'fossil pull' on Linux
Stephan Beal wrote: On Tue, Aug 19, 2014 at 7:31 PM, Warren Young war...@etr-usa.com wrote: On 8/18/2014 19:39, Eric Rubin-Smith wrote: warning: Can't read pathname for load map: Input/output error. That looks like a corrupted stack to me. Try running it under Valgrind. +1 I ran it under valgrind already and mentioned the results in the OP -- you probably missed that in my wall of text :-). The upshot is that valgrind's imposed slow-down causes us not to reach the bad path. So no help there. If you follow my post through to the end, though, you will see that the call to 'xfer_accept_file' in xfer.c line 1641 is strongly implicated by my gdb session. If you go and look at that function, you will see a call to blob_extract on line 139 that passes 'n', where 'n' was obtained above from the incoming data (xfer.c line 130). It seems very likely that we are placing too much trust in this 'n' during 'blob_extract'... though this is just my suspicion of course, not a certainty. and while i'm here: thank you for the tremendously detailed bug report. no problem. I've been on the receiving end of tickets like teh software doesn't work 4 me can u plz fix it enough times to try to avoid inflicting similar pain. :-) -- Eric A. Rubin-Smith ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] crash while running 'fossil pull' on Linux
On Mon, Aug 18, 2014 at 9:39 PM, Eric Rubin-Smith eas@gmail.com wrote:
I have taken a wire capture of the cleartext client-server interaction
and can share that with the devs privately if they would like.
Please
Also, can you reproduce the problem with -O0 instead of -O2 or -Os or
whatever it is that you currently are using?
1640 if( blob_eq(xfer.aToken[0],file) ){
Knowning the content of the xfer object just before the above line runs,
might provide a clue.
(gdb)
0x08048330 in ?? ()
(gdb)
Cannot find bounds of current function
(gdb)
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] crash while running 'fossil pull' on Linux
On 8/19/2014 11:50, Eric Rubin-Smith wrote: Try running it under Valgrind. I ran it under valgrind already and mentioned the results in the OP -- you probably missed that in my wall of text :-). No, I just stopped reading when I saw the characteristic smashed stack gdb output. :) valgrind's imposed slow-down causes us not to reach the bad path. That suggests a race condition, which usually means a threading or TCP stream packetization problem. With Fossil, I don't believe either to be the case. What I do believe is that Valgrind's parakeets and instrumentation code move things around in memory, which can cause code that used to break to start succeeding by accident. no problem. I've been on the receiving end of tickets like teh software doesn't work 4 me can u plz fix it enough times to try to avoid inflicting similar pain. :-) What amazes me is how often you see that sort of report from other developers. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
