Skip Menu |

This queue is for tickets about the Tk CPAN distribution.

Report information
The Basics
Id: 5606
Status: resolved
Worked: 1 hour (60 min)
Priority: 0/
Queue: Tk

People
Owner: Nobody in particular
Requestors: pajas [...] ufal.ms.mff.cuni.cz
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: weird segfault in getOpenFile
Date: Tue, 09 Mar 2004 20:15:18 +0000
To: bug-tk [...] rt.cpan.org
From: Petr Pajas <pajas [...] ufal.ms.mff.cuni.cz>
--=-=-= Content-Transfer-Encoding: quoted-printable Hi Nick, All, with Tk-804 beta_1[3-6] (but maybe all Tk-804 series) I'm experiencing strange random segfaults in getOpenFile (FBox) lately in one of my bigger application. First couldn't track it down because simple test cases didn't work. Finally I resulted with the following test case which makes it almost 100% reproducible (at least on my machines): __TEST_CASE__ #!/usr/bin/perl use Tk; use Tk::Canvas; # <-- important: without this line, all goes well $top=3DMainWindow->new(); $top->Button(-text=3D> "Open", -command=3D> sub { print $top->getOpenFile(),"\n" }) ->pack(-side=3D>'left',-padx=3D>'1'); MainLoop; __END__ Now how to use it to see the problem: 1) create a directory with many files (it is rather non-deterministic so you may need to try different numbers of files - I can see the problem with about 1050 files, but sometimes less than 1000 is sufficient) bash$ cd /tmp bash$ mkdir 0000 bash$ for s in `seq 1050`; do touch $s; done 2) now run the script above from /tmp (NOT FROM /tmp/0000) 3) click Open and select 0000 folder 4) double-click on a file 5) you should see sigsegv (if you don't, try again or choose different number of files and double check you run the script from a directory one level above 0000). You may actually start from any other directory, except for 0000/ itself, you may rename the files etc., all seems to give the same result, at least from time to time. But as I said, it is still very sensitive to conditions. I was able to run this through valgrind which wasn't possible with the whole application. The result, if it should be of any help, is below: bash$ valgrind ./_tred =3D=3D10730=3D=3D Memcheck, a.k.a. Valgrind, a memory error detector for x8= 6-linux. =3D=3D10730=3D=3D Copyright (C) 2002-2003, and GNU GPL'd, by Julian Seward. =3D=3D10730=3D=3D Using valgrind-2.0.0, a program supervision framework for= x86-linux. =3D=3D10730=3D=3D Copyright (C) 2000-2003, and GNU GPL'd, by Julian Seward. =3D=3D10730=3D=3D Estimated CPU clock rate is 1501 MHz =3D=3D10730=3D=3D For more details, rerun with: -v =3D=3D10730=3D=3D =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D valgrind's libpthread.so: KLUDGED call to: siglongjmp (cl= eanup handlers are ignored) =3D=3D10730=3D=3D Invalid read of size 4 =3D=3D10730=3D=3D at 0x41FBB052: Tk_TkwaitObjCmd (in /usr/lib/perl5/site= _perl/5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D by 0x41F91732: Call_Tk (in /usr/lib/perl5/site_perl/5.= 8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D by 0x41F94593: XSTkCommand (in /usr/lib/perl5/site_per= l/5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D by 0x41F946F3: XStoTclCmd (in /usr/lib/perl5/site_perl= /5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D Address 0x439F5AA8 is 20 bytes inside a block of size = 48 free'd =3D=3D10730=3D=3D at 0x4002D001: free (in /usr/lib/valgrind/vgskin_memch= eck.so) =3D=3D10730=3D=3D by 0x418F67CC: Tcl_Free (in /usr/lib/perl5/site_perl/5= .8.1/i586-linux-thread-multi/auto/Tk/Event/Event.so) =3D=3D10730=3D=3D by 0x418F682C: Tcl_DbCkfree (in /usr/lib/perl5/site_pe= rl/5.8.1/i586-linux-thread-multi/auto/Tk/Event/Event.so) =3D=3D10730=3D=3D by 0x41FC19D8: Tk_FreeTextLayout (in /usr/lib/perl5/si= te_perl/5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D =3D=3D10730=3D=3D Invalid read of size 4 =3D=3D10730=3D=3D at 0x41F96A4E: Lang_UntraceVar (in /usr/lib/perl5/site= _perl/5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D by 0x41FBB060: Tk_TkwaitObjCmd (in /usr/lib/perl5/site= _perl/5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D by 0x41F91732: Call_Tk (in /usr/lib/perl5/site_perl/5.= 8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D by 0x41F94593: XSTkCommand (in /usr/lib/perl5/site_per= l/5.8.1/i586-linux-thread-multi/auto/Tk/Tk.so) =3D=3D10730=3D=3D Address 0xB is not stack'd, malloc'd or free'd Segmentation fault. The troubles start somewhere within waitVariable in FBox.pm but that's probably all I can say. Due to lack of knowledge of ptk's guts I failed to investigate any further, but I'll be glad if someone had a look at it and found a fix before the final release is out since crashes in Open dialog (not talking about Save) will cause serious troubles to the end users :-( Thanks a lot, /Petr --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQBATKLYQfxdLDi03+IRArhxAJ9WO2xiRVat3S6cVDQ6UzeiCEjc6ACcDMae mPfEjJI5pDdnT8jq520cuy8= =c4kT -----END PGP SIGNATURE----- --=-=-=--
Fixed this by swapping perl stacks with PUSHSTACK before calling Tk level C code. So objv[] doesn't change under it.