Bug 382321
| Summary: | fvwm segfaults | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | nvwarr |
| Component: | fvwm | Assignee: | Adam Goode <adam> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | low | Docs Contact: | |
| Priority: | low | ||
| Version: | 8 | Keywords: | Reopened |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | 2.5.24-2.fc8 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-02-15 13:26:36 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Attachments: | |||
Created attachment 257981 [details]
Patch to fix this bug
fvwm-2.5.24-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 fvwm' (In reply to comment #2) > fvwm-2.5.24-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 fvwm' fvwm-2.5.24-1.fc8 has the same bug as 2.5.23. The function module_kill can be called with the parameter module equal to NULL. This then causes fvwm to crash with a segmentation fault in the same place in both versions. It may be possible to avoid the bug by changing things in the .fvwmrc, but a segfault is still a bug. My patch fixes the problem with 2.5.24-1.fc8 as well. I don't see any other obvious problems other than new "DEPRECATED" warnings in the error log...but they are in my .fvwmrc files. Interesting. Is it still crashing in the same place? Can you post a new backtrace, as well as the configuration that triggers the crash? Thanks. Created attachment 280791 [details]
fvwm configuration which triggers the bug
I've replaced the user, host and domain names, but otherwise the configuration
is as it was on my machine.
(In reply to comment #5) > Created an attachment (id=280791) [edit] > fvwm configuration which triggers the bug > > I've replaced the user, host and domain names, but otherwise the configuration > is as it was on my machine. Program terminated with signal 11, Segmentation fault. #0 0x080b1875 in module_kill (module=0x9ced7b0) at module_list.c:182 182 if (module == (*list)->module) (gdb) bt #0 0x080b1875 in module_kill (module=0x9ced7b0) at module_list.c:182 #1 0x080b1ad2 in FlushMessageQueue (module=0x9ced7b0) at module_list.c:1061 #2 0x0806c447 in My_XNextEvent (dpy=0x9cd4cf8, event=0xbff02c10) at events.c:4137 #3 0x0806c528 in HandleEvents () at events.c:3966 #4 0x0808e4df in main (argc=3, argv=0xbff036a4) at fvwm.c:2597 This is really the same place. The change of the declaration of module_list_remove from inline to static inline means that gdb now finds the correct line where the segfault occurs, but that is the only difference. Somehow module_kill is called with module_list being NULL. This is passed to module_list_remove as *list and then it does (*list)->module and segfaults. My patch simply tests module_list and if it is NULL returns silently. When that patch is applied, both 2.5.23 and 2.5.24 work fine. Hi, I have not been able to reproduce your crash. Which is the module that should fail to work (and therefore crash)? $ valgrind fvwm -display :1 ==4140== Memcheck, a memory error detector. ==4140== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al. ==4140== Using LibVEX rev 1732, a library for dynamic binary translation. ==4140== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP. ==4140== Using valgrind-3.2.3, a dynamic binary instrumentation framework. ==4140== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al. ==4140== For more details, rerun with: -v ==4140== ==4140== Syscall param writev(vector[...]) points to uninitialised byte(s) ==4140== at 0x3E05CCD89C: writev (writev.c:46) ==4140== by 0x3E07808A81: (within /usr/lib64/libxcb.so.1.0.0) ==4140== by 0x3E07808F9A: (within /usr/lib64/libxcb.so.1.0.0) ==4140== by 0x3E078090CA: (within /usr/lib64/libxcb.so.1.0.0) ==4140== by 0x3E0780A3E5: xcb_wait_for_reply (in /usr/lib64/libxcb.so.1.0.0) ==4140== by 0x3E07C4B08A: _XReply (xcb_io.c:364) ==4140== by 0x3E07C3F7A9: XSync (Sync.c:48) ==4140== by 0x44670E: main (fvwm.c:2440) ==4140== Address 0x50DF1FC is 4,444 bytes inside a block of size 8,680 alloc'd ==4140== at 0x4A04D1F: calloc (vg_replace_malloc.c:279) ==4140== by 0x3E07808C4E: xcb_connect_to_fd (in /usr/lib64/libxcb.so.1.0.0) ==4140== by 0x3E0780B024: xcb_connect (in /usr/lib64/libxcb.so.1.0.0) ==4140== by 0x3E07C4A3EB: _XConnectXCB (xcb_disp.c:78) ==4140== by 0x3E07C335B5: XOpenDisplay (OpenDis.c:168) ==4140== by 0x4477FA: main (fvwm.c:2147) [fvwm][CMD_EdgeResistance]: <<DEPRECATED>> The command EdgeResistance with three arguments is obsolete. Please use the following commands instead: [fvwm][]: <<DEPRECATED>> EdgeResistance 400 [fvwm][]: <<DEPRECATED>> Style * EdgeMoveDelay 400 [fvwm][]: <<DEPRECATED>> Style * EdgeMoveResistance 40 [fvwm][ReadDecorFace]: <<ERROR>> couldn't load pixmap win95-close-full.xpm [fvwm][ReadDecorFace]: <<ERROR>> couldn't load pixmap win95-maximize-full.xpm [fvwm][ReadDecorFace]: <<ERROR>> couldn't load pixmap win95-minimize-full.xpm [fvwm][FlocaleGetFontSet]: (*helvetica-medium-r-*-120-*) Missing font charsets: JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0 [fvwm][FlocaleGetFontSet]: (*helvetica*medium-r*12*) Missing font charsets: JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0 [fvwm][ParseBinding]: <<ERROR>> No such key: XF86Standby [fvwm][ParseBinding]: <<ERROR>> No such key: XF86Sleep [fvwm][ParseBinding]: <<ERROR>> No such key: XF86LightBulb [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-shadowman.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-sh1.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-letter.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-netscape.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-netscape.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-netscape.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-pdf.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-trebol.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-calc.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-periodic.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-windows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-windows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-pdf.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-penguin.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-windows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-connect.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-prefs.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-windows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-lock.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-lock.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-exclam.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-stop.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-turn.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-windows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-cross.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-exclam.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-modules.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-colors.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-cross.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-mouse.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-colors.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-raise.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-scroll-arrows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-x2.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-floppy.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-modules.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-shadowman.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-run.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-question.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-talk.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-pager.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-exp.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-pager.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-talk.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-exclam.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-turn.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-ray.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-recapture.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-modules.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-move.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-resize.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-raise.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-lower.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-iconify.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-stick.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-maxtall.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-maxwide.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-cross.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-bomb.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-scroll-arrows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-pencil.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-windows.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-ray.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-move.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-resize.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-iconify.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-cross.xpm [fvwm][scanForPixmap]: <<WARNING>> Couldn't load image from mini-bomb.xpm [fvwm][FlocaleGetFontSet]: (9x15bold) Missing font charsets: JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0, ISO10646-1 [fvwm][menustyle_parse_face]: <<ERROR>> couldn't load pixmap weird10dark.xpm [fvwm][FlocaleGetFontSet]: (*helvetica*bold-r*12*) Missing font charsets: JISX0208.1983-0, KSC5601.1987-0, GB2312.1980-0, JISX0201.1976-0 ==4140== ==4140== Conditional jump or move depends on uninitialised value(s) ==4140== at 0x46A431: set_focus_to_fwin (focus.c:187) ==4140== by 0x46A7C4: _SetFocusWindow (focus.c:952) ==4140== by 0x4294F2: HandleEnterNotify (events.c:2206) ==4140== by 0x426A39: dispatch_event (events.c:3927) ==4140== by 0x427169: HandleEvents (events.c:3968) ==4140== by 0x447374: main (fvwm.c:2597) (In reply to comment #7) > Hi, > > I have not been able to reproduce your crash. Which is the module that should > fail to work (and therefore crash)? Interesting. I'm not sure of the best way to find out which module is triggering the failure. I tried commenting things out in the .fvwm2rc file, but that just showed me that there are LOTS of ways to provoke the error. The first one I found was a MenuStyle command: MenuStyle "*" "mwm", Foreground Black, Background grey75, Greyed grey40, Font *helvetica-medium-r-*-120-*, "AnimationOff" It seems to be the Font argument that it doesn't like. Do the values of module->xname and module->xalias give anything useful? The former gives FvwmM4 and the latter gives the path to the .m4 file. There might be ways of getting a working setup by changing the .fvwm2rc file all over the place, but that is not really the point. The issue is a reference to (*list)->module when list == NULL. Clearly this shouldn't happen, but it does. So rather than expecting perfection from the functions which call module_kill, it is better to test this and ignore NULL pointers. That is what my patch does and with it fvwm works fine with my setup. As to the real cause, my suspicion is that the loop in My_XNextEvent in events.c which iterates using module_list_itr_next() screws up, because module_list_remove which is called from module_kill which is called from FlushMessageQueue, which is called from within the loop, changes the linked list, which we are iterating over. My guess is that it is not legitimate to call a function which changes the list from within a loop, which is iterating over the list. If that is the case, the only true fix, I can see would be to make FlushMessageQueue give a return value and use that to decide whether we need to rerun module_list_itr_init before continuing in the loop in My_XNextEvent. If this is true, it presumably means that the module which is causing the problem is the one run before the one where the segfault shows up! Created attachment 293564 [details]
Fixes a bug, which continued to iterate on a list, after the list was modified
To test this theory, I've made a new patch, which (without my original patch)
seems to fix the problem. This one makes FlushMessageQueue return an int which
is zero normally and non-zero if it has diddled with the module list. In
My_XNextEvent, I test this value and if it is non-zero, I call
module_list_itr_init again, to reinitialise the iterator.
So now I have two patches, which both seem to fix the problem. The original
patch is probably safer (it only makes a difference if the function is called
with a NULL list, which definitely only happens if something has gone wrong)
but it rather sweeps the bug under the carpet. The new patch addresses the real
problem but it could have side effects that I have missed (it works for me!)
The two patches are orthogonal, so it shouldn't be a problem to use both.
(In reply to comment #9) > Created an attachment (id=293564) [edit] > Fixes a bug, which continued to iterate on a list, after the list was modified Ooops, I've made a mistake. I tested this patch without removing the other one. Now, I've tested it separately and it does _NOT_ fix the problem. So please ignore the second patch. Hi, I still don't have a config file that will trigger this bug. Yes, I have a config with the bad MenuStyle option, but it works as in comment 7. Created attachment 294305 [details]
m4 configuration file for fvwm2 which reproduces the problem
Now I see why you couldn't reproduce the error. I sent you the config file
generated by fvwm after parsing with m4. However, it seems that the problem is
in the FvwmM4 module, so using that file doesn't reproduce the error.
I had wanted to avoid sending the .m4 file, because it pulls in other files,
which pull in other files etc. However, with a fair amount of editing, I have
produced a single monolithic m4 file, which (hopefully) doesn't pull in any
others, and which reproduces the error.
I run it with:
fvwm2 -cmd 'FvwmM4 -debug fvwm2rc_test.m4'
fvwm-2.5.24-2.fc7 has been submitted as an update for Fedora 7 fvwm-2.5.24-2.fc8 has been submitted as an update for Fedora 8 fvwm-2.5.24-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 fvwm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1474 (In reply to comment #15) > fvwm-2.5.24-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 fvwm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F8/FEDORA-2008-1474 Yes, this fixes it. Thanks! fvwm-2.5.24-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report. fvwm-2.5.24-2.fc7 has been pushed to the Fedora 7 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: fvwm segfaults with some errors in the input files Version-Release number of selected component (if applicable): 2.5.23 How reproducible: Always Steps to Reproduce: 1. Start fvwm with an error, which causes one of the modules to fail Actual results: Segmentation fault in module_kill (module_list.c:533) #0 0x080b11c5 in module_kill (module=0xa0e05d0) at module_list.c:533 #1 0x080b1422 in FlushAllMessageQueues () at module_list.c:1076 #2 0x0806bf37 in My_XNextEvent (dpy=0xa0c9f28, event=0xbfb8b970) at events.c:4136 #3 0x0806c018 in HandleEvents () at events.c:3965 #4 0x0808df6b in main (argc=3, argv=0xbfb8c404) at fvwm.c:2598 Expected results: fvwm should try to continue, write an error message or something, but not segfault. Additional info: module_kill calls the inline code module_list_remove(module, &module_list), but module_list is NULL. In the inline code, this is "list" and the line: if (module == (*list)->module) causes a segmentation fault. Adding the line: if (!module_list) return; at the beginning of module_kill fixes the problem. This is probably the cause of bug 233383, which was closed when the original poster found a workaround. However, I think this is really a bug which should be fixed.