FvwmIconMan crashes with segmentation fault some time after 20211017

[anubhav-x672d61]

Thanks for reporting your bug here! The following template will help with giving as much information as possible so that it's easier to diagnose and fix.

Upfront Information

Please provide the following information by running the command and providing the output.

• Fvwm3 version (run: fvwm3 --version)

fvwm3 1.0.5 (1.0.4-123-g0fe58f0d) with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

fvwm3 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of fvwm under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING.

• Linux distribution or BSD name/version

FreeBSD stable/13 (commit hash: 4081882c41)

• Platform (run: uname -sp)

FreeBSD amd64

Expected Behaviour

FvwmIconMan would not crash from first start up; will show the windows as configured.

Or, it would actually run & not crash when started via menu even without my own configuration.

Actual Behaviour

FvwmIcon has been crashing on start up (started via StartFunction) some time after 20211017 (have been using/trying by building fvwm3 from GitHub source).

Enabling logging

fvwm3 has a means of logging what it's doing. Enabling this when reproducing the issue might help. To do this, either change the means fvwm3 is started by adding -v as in:

fvwm3 -v

or, once fvwm3 has loaded, send SIGUSR2 as in:

pkill -USR2 fvwm3

The resulting logfile can be found in $HOME/.fvwm/fvwm3-output.log

[1648635719.884879] FScreenInit: Using RandR 1.6 [1648635720.047967] main: Loading window states via (null) [1648635720.931938] main: couldn't find/load [0]: ~/.fvwm/config [1648635720.932051] main: couldn't find/load [1]: ~/local/fvwm3.2022-0316/share/fvwm3.2022-0316/config [1648635720.932102] main: couldn't find/load [2]: ~/.fvwm/.fvwm2rc [1648635720.932155] main: couldn't find/load [3]: ~/.fvwm2rc [1648635720.932206] main: couldn't find/load [4]: ~/local/fvwm3.2022-0316/share/fvwm3.2022-0316/.fvwm2rc [1648635720.932274] main: couldn't find/load [5]: ~/local/fvwm3.2022-0316/share/fvwm3.2022-0316/system.fvwm2rc [1648635720.932370] main: couldn't find/load [6]: ~/local/fvwm3.2022-0316/etc/system.fvwm2rc [1648635721.034482] initPanFrames: freeing panframes [1648635721.034685] initPanFrames: finished setting up per-monitor panframes [1648635724.028519] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.034876] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.041781] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.048257] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.054881] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.427029] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.451071] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.474575] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.737487] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.806770] setup_window_placement: Expanding screen from 'null' -> '' [1648635724.998375] setup_window_placement: Expanding screen from 'null' -> '' [1648635744.306890] setup_window_placement: Expanding screen from 'null' -> '' [1648635792.242276] is_pan_frame: Window is PanFrame right [1648635792.845455] HandleEnterNotify: handled paging for VGA-0 (0) [1648635792.845637] is_pan_frame: Window is PanFrame right [1648635901.502436] setup_window_placement: Expanding screen from 'null' -> ''

Steps to Reproduce

How can the problem be reproduced? For this, the following is helpful:

• Reduce the problem to the smallest fvwm configuration example (where possible). Start with a blank config file (fvwm3 -f/dev/null) and go from there.

Same crash & backtrace happens with only the default configuration (& none of my configuration) ...

fvwm3 -v

... but not with ...

fvwm3 -v -f /dev/null

... IconMan appears via FvwmConsole in this case; windows are listed as expected.

• Does the problem also happen with Fvwm2?

Include your configuration with this issue.

Does Fvwm3 crash?

If fvwm3 crashes then check your system for a corefile. This is platform dependant, however, check if:

• corefiles are enabled (ulimit -c)
• A corefile might be in $HOME or /tmp/.
• If you're using Linux (with systemd), check coredumpctl list. coredumpctl may need installing separately.

If you find a corefile, install gdb and run:

gdb /path/to/fvwm3 /path/to/corefile

If you're using coredumpctl then use:

coredumpctl debug

Then from within the (gdb) prompt, issue:

bt full

... and include the output here.

(gdb) bt full #0 strcmp () at /src-ports/freebsd/lib/libc/amd64/string/strcmp.S:21 No locals. #1 0x0000000000234803 in monitor_resolve_name ( scr=0xffffffff00000042 <error: Cannot access memory at address 0xffffffff00000042>) at FScreen.c:198 m = 0x0 #2 0x00000000002356d6 in FindScreen (arg=, screen=) at FScreen.c:689 tmp = {mouse_ev = 0x843e8d4a4, name = 0x843e8d4a8 "\001", xypos = {x = 1, y = 0}} m = 0x0 #3 FScreenGetScrRect (arg=arg@entry=0x820684d40, screen=screen@entry=FSCREEN_BY_NAME, x=x@entry=0x843e8d41c, y=y@entry=0x843e8d420, w=w@entry=0x843e8d424, h=h@entry=0x843e8d428) at FScreen.c:738 m = #4 0x00000000002266d3 in X_init_manager (man_id=man_id@entry=0) at x.c:749 arg = {mouse_ev = 0x0, name = 0xffffffff00000042 <error: Cannot access memory at address 0xffffffff00000042>, xypos = {x = 1089037328, y = 8}} man = i = geometry_mask = 15 height = width = y = x = #5 0x000000000021ae67 in main (argc=, argv=0x820684f80) at FvwmIconMan.c:303 i = 0

Extra Information

• Anything else we should know?

• Feel free to take a screen capture or video and upload to this issue if you feel it would help.

• Attach $HOME/.fvwm/fvwm3-output.log from the step above.

[anubhav-x672d61]

Some hours ago I tried again at the commit f0ed978d39, c 20220526 that resulted in the same crash (now FreeBSD stable/13 is at commit fb231965f9b, c 20211116). I should have noted earlier -- which also applies to the commit mentioned -- that the crashes have happened when FreeBSD, thus FVWM, was running as guest in VirtualBox (6.30) on Windows.

OTOH there have not been any crashes of FvwmIconMan when running on FreeBSD 14 (at commit c11e64ce513, c 20220624) directly on the hardware. FVWM compiled here is also at the same commit of f0ed978d39. Having used FVWM on FreeBSD 14 for a while without issues what had gave me the false hope of trying again in the virtual machine. X-[

[anubhav-x672d61]

I have also filed a bug against the FreeBSD port x11-wm/fvwm3 (version 1.0.4_2) ...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265291

... in case problem could be somewhere in FreeBSD in VM.

[tigersharke]

Please provide the following information by running the command and providing the output.

Fvwm3 version (run: fvwm3 --version)

fvwm3 1.0.5 (released) with support for: ReadLine, XPM, PNG, SVG, Shape, XShm, SM, Bidi text, XRandR, XRender, XCursor, XFT, NLS

fvwm3 comes with NO WARRANTY, to the extent permitted by law. You may redistribute copies of fvwm under the terms of the GNU General Public License. For more information about these matters, see the file named COPYING.

Although the commit above was built from is 4d646ca

Linux distribution or BSD name/version

FreeBSD stable/13 (commit hash: 4081882c41)

Platform (run: uname -sp)

FreeBSD amd64

I do not mean to suggest that the above issue does not exist, only that in my experience it does not appear so: my own build (https://github.com/tigersharke/fvwm3-dev outside of ports directory but same method, mechanisms) of fvwm3 is very current, and I use FreeBSD 13-stable directly. I use the default config along with extension to my own configs. I specifically added to my config, to test the issue: DestroyFunc StartFunction AddToFunc StartFunction

• I Test (Init) Module FvwmIconMan

Aside from that, I normally use FvwmButtons with FvwmIconMan swallowed which also has been working fine for me.

I offer above as clarity. May it be only a VirtualBox issue?

[anubhav-x672d61]

I have also filed a bug against the FreeBSD port x11-wm/fvwm3 (version 1.0.4_2) ...

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265291

FreeBSD port maintainer Felix P had provided a test patch ...

https://bz-attachments.freebsd.org/attachment.cgi?id=235341
# Adds around line 742 of "modules/FvwmIconMan/x.c".
arg.name = NULL

... which allowed FvwmIconMan to show window listing as expected instead of crashing.

[Zirias]

Hi, maintainer of the FreeBSD port here ... as the reporter of the crash just confirmed, the following patch (against 1.0.4, note 1.0.4 also needs backporting a few changes that correctly handle this NULL value) avoids the crash:

--- modules/FvwmIconMan/x.c.orig        2022-07-18 23:18:50 UTC
+++ modules/FvwmIconMan/x.c
@@ -742,6 +742,7 @@ void X_init_manager (int man_id)
     char *scr;
     fscreen_scr_arg arg;
     arg.mouse_ev = NULL;
+    arg.name = NULL;
 
     geometry_mask = FScreenParseGeometryWithScreen(
       man->geometry_str, &man->geometry.x, &man->geometry.y,

I have doubts this is actually a fix, but without this initialization, the field will be used uninitialized further down the stack (in FScreen.c/monitor_resolve_name, passing it to strcmp). So maybe it will help to find a correct fix ;)

edit: Ok, the reporter was quicker than me...

[ThomasAdam]

Hi @Zirias

I think this patch is correct -- in most cases where fscreen_scr_arg arg is used, it's doing so not based directly on the screen name.

Please can you submit an actual PR which addresses this issue for me, and I'll merge it in.

[deepsummersee]

Hi,

I'm running into the same issue that @anubhav-x61 reported back in March on my Arch machine. FvwmIconMan will sometimes not start up at all when FVWM is (re)starting, and inputting Module FvwmIconMan into the console will only start FvwmIconMan occasionally (retries are necessary). This is still a persistent bug. I'm running the fvwm-git package from the AUR and, at the time of this comment, is version fvwm3 1.0.6 (1.0.5-56-g3d6e704d). If it is relevant, my uname -a output is: Linux T480 6.1.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 31 Dec 2022 17:40:35 +0000 x86_64 GNU/Linux