Description of problem: Version-Release number of selected component (if applicable): Perl-Tk loaded on 2007 April, 8th (Tk807.02?-10) An old proved perl program get segfaults How reproducible: Always. Attached is small file with an unfolded loop asking of yes_no question. It has been extracted from a program doing a cycle edition -> latex -> viewing (here ask repeat or goto print) Steps to Reproduce: 1.Use the file attached: 2.After three choices, you got a segfault on my machine. FC6 3. Actual results: Expected results: NO SEGFAULT Additional info: The program worked fine since FC3
Created attachment 151990 [details] a small perl program using Tk
perl-Tk-804.028-1.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Tk'
perl-Tk-804.028-1.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Tk'
Hm, after an update to perl-Tk-804.028-1.fc7 and adding in 'testask' test program from comment #1 eight more lines $action = yes_no($f); print $action,"\n"; I got the following results: $ perl testask 0 0 0 0 Segmentation fault $ perl testask 1 1 1 1 1 1 1 1 1 Segmentation fault $ perl testask 0 0 0 0 0 0 Segmentation fault That is not precisely repeatable. It appears that one has to click fast enough in a succession to segfault (so with a random placement of new windows this is hard to achieve). As you can see a number of tries also changes and I got also "clean" series. OTOH I tried to reproduce that with perl-Tk-804.028-1.fc9 on a "rawhide" test installation and this was much harder. On a number of tries I got a segfault once on 17th answer (after a number of "action lines" was increased once again). Both F7 and rawhide installation are on x86_64 hardware but different machines.
With perl-Tk-debuginfo loaded I managed to get a core and a backtrace. It looks like follows for perl-Tk-804.028-1: Core was generated by `perl testask'. Program terminated with signal 11, Segmentation fault. #0 0x00002aaaaeff0ba6 in Tk_GetOptionValue (interp=0xb57b40, recordPtr=0xb0f820 " W�", optionTable=<value optimized out>, namePtr=<value optimized out>, tkwin=0xb35720) at tkConfig.c:2280 2280 if (optionPtr->specPtr->type == TK_OPTION_SYNONYM) { (gdb) where #0 0x00002aaaaeff0ba6 in Tk_GetOptionValue (interp=0xb57b40, recordPtr=0xb0f820 " W�", optionTable=<value optimized out>, namePtr=<value optimized out>, tkwin=0xb35720) at tkConfig.c:2280 #1 0x00002aaaaefa9f69 in FrameWidgetObjCmd (clientData=0xb0f820, interp=0xb57b40, objc=3, objv=0x7c5638) at tkFrame.c:772 #2 0x00002aaaaef8119b in Call_Tk (info=<value optimized out>, items=3, args=0x7c5638) at tkGlue.c:2283 #3 0x00002aaaaef826c0 in XStoWidget (my_perl=0x604010, cv=<value optimized out>) at tkGlue.c:2664 #4 0x0000003dd6490826 in Perl_pp_entersub () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so #5 0x0000003dd648a0ee in Perl_runops_standard () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so #6 0x0000003dd6437d9c in perl_run () from /usr/lib64/perl5/5.8.8/x86_64-linux-thread-multi/CORE/libperl.so #7 0x00000000004017bc in main () In frame 0 optionPtr->specPtr comes as (const Tk_OptionSpec *) 0x0 so it is not that surprising that an attempt to derefernce it segfaults. The whole *optionPtr looks like this: {specPtr = 0x0, dbNameUID = 0x31 <Address 0x31 out of bounds>, dbClassUID = 0xffffffffffff3fff <Address 0xffffffffffff3fff out of bounds>, defaultPtr = 0x3fffffffffff, extra = {monoColorPtr = 0x0, synonymPtr = 0x0, custom = 0x0}, flags = 0} Is this value legitimate or this is a symptom of a "generic trouble" in a perl mulithreading support? Replacing on line 2277 'if (optionPtr == NULL)' with 'if (optionPtr == NULL || optionPtr->specPtr == NULL )' should prevent that segfault but I have no idea if this just papers over symptomps and/or has other nasty side-effects.
I have been debugging this the whole evening and on the way adding sort of the same patch. This does prevent it from crashing in a couple of occasions but so harder you can still trigger a crash because eventually optionPtr->specPtr->type is broken (or better specPtr contains crap). I currently believe that this is related to what is mentioned in tkGlue.c:2269: " /* BEWARE if Tk code does a callback to perl and perl grows the stack then args that Tk code has will still point at old stack. Thus if Tk tests args[i] *after* the callback it will get junk. (Note it is only vector that is at risk, SVs themselves will stay put.) So we pre-emptively swap perl stack so any callbacks which grow their stack don't move our "args" */ " because there stuff gets called but values for args make sense: e.g. right before a crash: args: 0x7c59c8, args[2]: 0x96D010 I am really clueless atm.
I have located the issue and worked around it. Please give it a try. Builds can be found in koji but should also hit updates-testing with the next push. rawhide -> http://koji.fedoraproject.org/koji/buildinfo?buildID=30137 f8 -> http://koji.fedoraproject.org/koji/buildinfo?buildID=30136 f7 -> http://koji.fedoraproject.org/koji/buildinfo?buildID=30138
> I have located the issue and worked around it. Please give it a try If not anything else you surely made triggering the issue much harder. :-) I tried a number of times and failed while previously I could get that segfault with a relative ease. Not entirely surprising looking at your patch. I also run few other tests and they seem to be doing fine. In particular those from 'demos' subdirectory of sources.
perl-Tk-804.028-1.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
perl-Tk-804.028-2.fc7 has been pushed to the Fedora 7 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Tk'
perl-Tk-804.028-1.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
perl-Tk-804.028-2.fc8 has been pushed to the Fedora 8 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update perl-Tk'
perl-Tk-804.028-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report.
perl-Tk-804.028-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.