Menu
▾
▴
[Tcl-bugs] [ tcl-Bugs-1462248 ] core dump on Linux while [read]ing file
|
From: SourceForge.net <no...@so...> - 2006-04-03 17:43:31
|
Bugs item #1462248, was opened at 2006-03-31 08:50 Message generated for change (Comment added) made by andreas_kupries You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1462248&group_id=10894 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: 25. Channel System Group: current: 8.4.12 Status: Open Resolution: None Priority: 9 Submitted By: Matthias Kraft (matzek) Assigned to: Andreas Kupries (andreas_kupries) Summary: core dump on Linux while [read]ing file Initial Comment: Hi *, I occassionally get a core dump from a Sig11 on Linux (x86_64) while reading plain files. It seems to depend on the content of the file. The Tcl interpreter is built from unmodified sources and does not contain any extensions. It was built using gcc 4.0.2 with -m32 to get i386 compatible executables. % parray tcl_platform tcl_platform(byteOrder) = littleEndian tcl_platform(machine) = x86_64 tcl_platform(os) = Linux tcl_platform(osVersion) = 2.6.13-15.7-smp tcl_platform(platform) = unix tcl_platform(user) = makr tcl_platform(wordSize) = 4 % set tcl_patchLevel 8.4.12 As I just noticed, it also only happens if env(LANG) is set to an UTF-8 encoding, e.g. de_DE.UTF-8 or en_US.UTF-8. Having a file like the attached "crashme" file, I'll do the following then ... % set f [open crashme] file3 % while {![eof $f]} {read $f 4096} Segmentation fault (core dumped) Backtrace: #0 0x5561858c in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0x5561858c in memcpy () from /lib/tls/libc.so.6 #1 0x080a973b in ReadChars (statePtr=0x810c338, objPtr=0x810cff0, charsToRead=74, offsetPtr=0xffffac18, factorPtr=0xffffac14) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclIO.c:4818 #2 0x080a91f3 in DoReadChars (chanPtr=0x8114510, objPtr=0x810cff0, toRead=74, appendFlag=0) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclIO.c:4488 #3 0x080a90dd in Tcl_ReadChars (chan=0x8114510, objPtr=0x810cff0, toRead=4096, appendFlag=0) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclIO.c:4410 #4 0x080aeaf6 in Tcl_ReadObjCmd (dummy=0x0, interp=0x80fc4f0, objc=3, objv=0x80ff78c) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclIOCmd.c:365 #5 0x080629e9 in TclEvalObjvInternal (interp=0x80fc4f0, objc=3, objv=0x80ff78c, command=0x0, length=0, flags=0) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclBasic.c:3085 #6 0x08090f25 in TclExecuteByteCode (interp=0x80fc4f0, codePtr=0x810c3b8) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclExecute.c:1419 #7 0x08090106 in TclCompEvalObj (interp=0x80fc4f0, objPtr=0x8105e58) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclExecute.c:981 #8 0x08063c7d in Tcl_EvalObjEx (interp=0x80fc4f0, objPtr=0x8105e58, flags=131072) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclBasic.c:4049 #9 0x080a1f85 in Tcl_RecordAndEvalObj (interp=0x80fc4f0, cmdPtr=0x8105e58, flags=131072) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclHistory.c:142 #10 0x0804ab09 in Tcl_Main (argc=-1, argv=0xffffb5c8, appInitProc=0x804a461 <Tcl_AppInit>) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclMain.c:392 #11 0x0804a45a in main (argc=1, argv=0xffffb5c4) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/tclAppInit.c:90 (gdb) up #1 0x080a973b in ReadChars (statePtr=0x810c338, objPtr=0x810cff0, charsToRead=74, offsetPtr=0xffffac18, factorPtr=0xffffac14) at /home/makr/cvs/M214/ginfix2/openSrc/tcl8.4/unix/../generic/tclIO.c:4818 4818 memcpy((VOID *) (nextPtr->buf + nextPtr->nextRemoved), (VOID *) src, I noticed that memcpy() got fed with srcLen=-22: (gdb) print srcLen $1 = -22 (gdb) print src $2 = 0x812528e "" (gdb) print nextPtr->buf $3 = "\201�212\027" (gdb) print nextPtr->nextRemoved $4 = 38 (gdb) print nextPtr->buf + nextPtr->nextRemoved $5 = 0x81252c6 "" I also just noticed ActiveTcl's tclsh8.4 (8.4.11) does also core dump... % parray ::activestate::ActiveTcl ::activestate::ActiveTcl(arch) = linux-ix86 ::activestate::ActiveTcl(as,mode) = normal ::activestate::ActiveTcl(build) = 162119 ::activestate::ActiveTcl(buildtime,fmt) = Tue Jul 19 10:40:31 AM PDT 2005 ::activestate::ActiveTcl(buildtime,sec) = 1121794831 ::activestate::ActiveTcl(maturity) = final ::activestate::ActiveTcl(product) = ActiveTcl ::activestate::ActiveTcl(release) = 8.4.11.0 % set f [open crashme] file3 % while {![eof $f]} {read $f 4096} Speicherzugriffsfehler (core dumped) Althouth this core does not give much away, it apparently crashes at the same position: #0 0x556c158c in memcpy () from /lib/tls/libc.so.6 (gdb) bt #0 0x556c158c in memcpy () from /lib/tls/libc.so.6 #1 0x555c535e in ReadChars () from /usr/local/ActiveTcl/lib/libtcl8.4.so #2 0x555c4fca in DoReadChars () from /usr/local/ActiveTcl/lib/libtcl8.4.so #3 0x555c4eb0 in Tcl_ReadChars () from /usr/local/ActiveTcl/lib/libtcl8.4.so #4 0x555c9582 in Tcl_ReadObjCmd () from /usr/local/ActiveTcl/lib/libtcl8.4.so #5 0x5558eb27 in TclEvalObjvInternal () from /usr/local/ActiveTcl/lib/libtcl8.4.so #6 0x555b2faa in TclExecuteByteCode () from /usr/local/ActiveTcl/lib/libtcl8.4.so #7 0x555b2475 in TclCompEvalObj () from /usr/local/ActiveTcl/lib/libtcl8.4.so #8 0x5558fbe7 in Tcl_EvalObjEx () from /usr/local/ActiveTcl/lib/libtcl8.4.so #9 0x555bf6f4 in Tcl_RecordAndEvalObj () from /usr/local/ActiveTcl/lib/libtcl8.4.so #10 0x555d3565 in Tcl_Main () from /usr/local/ActiveTcl/lib/libtcl8.4.so #11 0x080488aa in main () kind regards -- Matthias Kraft PS: SF won't let me upload the file as it is 512 kB, please download from here: http://www.matkraft.de/files/crashme ---------------------------------------------------------------------- >Comment By: Andreas Kupries (andreas_kupries) Date: 2006-04-03 10:43 Message: Logged In: YES user_id=75003 Ok, there is something odd going on here. I can repro the crash only when using the script interactively. The moment I go non-interactive things are OK. And replacing the while-loop with a large read of the whole file makes it go away as well. This general elusivity, i.e. vanishing at the slighest change, points to a memory-smash somewhere. :( Yep, very likely. Changing the size of blocks read by even one character, up or down, causes the crash to vanish as well ... changing the -buffersize in tandem with the #chars read is not effective, the crash vanishes. Changing the buffersize alone makes it vanish as well. Ah, one case is different: -buffer 4095, read 4096 blocks ... This seems to hang the tclsh instead of crashing it. ---------------------------------------------------------------------- Comment By: Don Porter (dgp) Date: 2006-04-03 10:17 Message: Logged In: YES user_id=80530 no crash for me using the tip of either development branch. Tested on both Solaris and Linux/Alpha. Can anyone reproduce the crash? ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2006-04-03 10:15 Message: Logged In: YES user_id=75003 Thanks for your efforts ... They were partly for naught. I am unable to repro the bug on my i386 machine using the crashme3 file with crash.tcl script. I get some nice output in the form 3/12288 >>> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 2/8192 >>> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 1/4096 >>> 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 However, I can reproduce the seg.fault using the original large crashme file and using the trivial code in your initial report. Just one change was necessary, "fconfigure $f -encoding utf-8". This was on a i386 machine, i.e 32bit, tclsh 8.4.13 (not yet released, near CVS head essentially), compiled with a gcc 2.95.3. The only part which seems to be the same in both your and my crash is the encoding, utf-8. Based on that my guess is that it is the utf8 code which gets into trouble for specific byte-sequences in the input. This is the next thing to check, using a debug build and other instrumentation to get a look into the behaviour. So, for now I can definitely confirm that there is crash, even if the exact cause is not yet known. ---------------------------------------------------------------------- Comment By: Matthias Kraft (matzek) Date: 2006-04-03 06:34 Message: Logged In: YES user_id=330806 Attaching a reduced example file. Although the behavior to reproduce changed a little, the core dump still looks the same. With this file the crash occurs on Linux x86_64, i386 and s390x. With the full file the crash also occurs on AIX 5.2 and HP-UX 11i. Will attach a script to reproduce the crash with this example file... ---------------------------------------------------------------------- Comment By: Matthias Kraft (matzek) Date: 2006-04-03 05:10 Message: Logged In: YES user_id=330806 If I understand the code correctly, the file crashme contains random data. It is generated to have some file to test procedures used for data conversion and unpacking archives. I currently have no smaller file, I'll try to produce one, but no luck so far. Tried halving the search, first half, second half, a moving window half the size - but it doesn't crash then. % fconfigure $f -blocking 1 -buffering full -buffersize 4096 -encoding utf-8 -eofchar {} -translation auto ---------------------------------------------------------------------- Comment By: Andreas Kupries (andreas_kupries) Date: 2006-03-31 09:29 Message: Logged In: YES user_id=75003 Ideas regarding the crashme file. Compress it to see if the result goes below the upload limit of SF. gzip, or bzip2. Also, have you found smaller files exhibiting the problem ? Maybe a halving search ? First half of crashme crashing it ? Second half ? The half-size section centered on the middle of the file ? If yes, we can try to divide further. Given the reference to LANG I consider it interesting to find out what system encoding is chosen by Tcl. Better, what default encoding for the channel you open. Can you add a 'puts [fconfigure $f]' statement to your script before you start reading ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=110894&aid=1462248&group_id=10894 |
