Bug 382321 - fvwm segfaults
fvwm segfaults
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: fvwm (Show other bugs)
8
All Linux
low Severity low
: ---
: ---
Assigned To: Adam Goode
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-11-14 07:31 EST by nvwarr
Modified: 2008-02-18 22:13 EST (History)
0 users

See Also:
Fixed In Version: 2.5.24-2.fc8
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-15 08:26:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch to fix this bug (324 bytes, patch)
2007-11-14 07:31 EST, nvwarr
no flags Details | Diff
fvwm configuration which triggers the bug (56.21 KB, text/plain)
2007-12-07 03:01 EST, nvwarr
no flags Details
Fixes a bug, which continued to iterate on a list, after the list was modified (2.10 KB, patch)
2008-01-31 04:56 EST, nvwarr
no flags Details | Diff
m4 configuration file for fvwm2 which reproduces the problem (81.69 KB, application/x-m4)
2008-02-08 02:31 EST, nvwarr
no flags Details

  None (edit)
Description nvwarr 2007-11-14 07:31:14 EST
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.
Comment 1 nvwarr 2007-11-14 07:31:14 EST
Created attachment 257981 [details]
Patch to fix this bug
Comment 2 Fedora Update System 2007-12-03 00:34:49 EST
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'
Comment 3 nvwarr 2007-12-06 02:28:27 EST
(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.
Comment 4 Adam Goode 2007-12-06 10:43:55 EST
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.
Comment 5 nvwarr 2007-12-07 03:01:33 EST
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.
Comment 6 nvwarr 2007-12-07 03:05:49 EST
(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.
Comment 7 Adam Goode 2008-01-20 00:13:40 EST
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)
Comment 8 nvwarr 2008-01-31 03:51:15 EST
(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!
Comment 9 nvwarr 2008-01-31 04:56:24 EST
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.
Comment 10 nvwarr 2008-01-31 05:13:51 EST
(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.
Comment 11 Adam Goode 2008-02-03 19:16:55 EST
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.
Comment 12 nvwarr 2008-02-08 02:31:00 EST
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'
Comment 13 Fedora Update System 2008-02-09 03:29:26 EST
fvwm-2.5.24-2.fc7 has been submitted as an update for Fedora 7
Comment 14 Fedora Update System 2008-02-09 03:30:10 EST
fvwm-2.5.24-2.fc8 has been submitted as an update for Fedora 8
Comment 15 Fedora Update System 2008-02-12 23:55:56 EST
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
Comment 16 nvwarr 2008-02-15 08:26:36 EST
(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!
Comment 17 Fedora Update System 2008-02-18 22:11:35 EST
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.
Comment 18 Fedora Update System 2008-02-18 22:13:08 EST
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.

Note You need to log in before you can comment on or make changes to this bug.