Fluxbox frequently crashes (+backtrace)

[sillysloft]

Fluxbox quite frequently (several times a day, sometimes there are few hours between crashes, sometimes just few minutes or seconds) crashes on my machine without any apparent reason.

I observed this crash on 1.1.1, then I tried compiling newest GIT version. I got this stacktrace (from GIT version) when fluxbox crashed, leaving core dump:

Core was generated by `fluxbox'. Program terminated with signal 6, Aborted. #0 0x00007f6ec9abff45 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 64 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. in ../nptl/sysdeps/unix/sysv/linux/raise.c (gdb) bt #0 0x00007f6ec9abff45 in *__GI_raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00007f6ec9ac2d80 in *__GI_abort () at abort.c:88 #2 0x000000000041b12f in Fluxbox::handleSignal (this=0x203dc70, signum=11) at fluxbox.cc:1019 #3 <signal handler called> #4 0x0000000002223260 in ?? () #5 0x0000000000487282 in FbTk::SigImpl::Slot3<void, BScreen&, FluxboxWindow*, WinClient*>::operator() (client=<value optimized out>) at FbTk/Slot.hh:285 #6 FbTk::SigImpl::Signal3<void, BScreen&, FluxboxWindow*, WinClient*>::emit (client=<value optimized out>) at FbTk/Signal.hh:147 #7 FocusControl::setFocusedWindow (client=<value optimized out>) at FocusControl.cc:586 #8 0x0000000000415bc5 in Fluxbox::handleEvent (this=0x203dc70, e=0x7fffecd75e60) at fluxbox.cc:857 #9 0x0000000000416291 in Fluxbox::eventLoop (this=0x203dc70) at fluxbox.cc:503 #10 0x0000000000428e7b in main (argc=<value optimized out>, argv=0x7fffecd76438) at main.cc:295

Reported by: bilboq

[sillysloft]

Hi, I might have similar troubles. Fluxbox is crashing for me randomly but regulary (today it was already twice). I was able to get a crash report file from Apport which I am attaching.

I am running

igor@jubilee:~$ fluxbox -version Fluxbox 1.1.1 : (c) 2001-2008 Fluxbox Team

from Lucid repositories on

igor@jubilee:~$ lsb_release -rd Description: Ubuntu 9.10 Release: 9.10

I was experiencing the same behavior with 'standard' Karmic repositories fluxbox.

Original comment by: izemsky

[sillysloft]

Hmm, somehow I did not figure out how to attach a file. I get no other option available then 'No Files Currently Attached' - no 'Add file' as I do see by the comment:-(

If I will find a way to attach the file I can provide the Apport crash file (I think it is including core dump also).

Original comment by: izemsky

[sillysloft]

Hi, there is similar report concerning Ubuntu - I posted the files there: (dmesg, xorg.conf, lspci-vvnn, _usr_bin_fluxbox.1000.crash_2010_03_31, Xorg.0.log)

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/527075

Original comment by: izemsky

[sillysloft]

can you trigger the crash? reproducable?

Original comment by: akir

[sillysloft]

Yesterday I updated to Lucid 10.04. So far the crash did not occur to me. If it will I will post further information. Though I would not exactly call it reproducable - I had only one situation where it was occurring with about 5 - 10% probability but otherwise it occurred 'randomly' after clicking a mouse on a GUI control (e.g. button of GTK app but never when clicking fluxbox controls).

Does it make any sense to reproduce the bug in 9.10? (I still have the old system available - I could temporarily switch back to it)

Original comment by: izemsky

[sillysloft]

I figured out, that the crash is partially reproducable - when I use JOSM (program in java - from josm.openstreetmap.de), it is very likely that after about 15 or 30 minutes of using it fluxbox will crash, though I have not yet figured what exactly does cause the crash. However, if after the crash fluxbox is restarted (I've put "while true; do fluxbox;done" in ~/.Xsession so fluxbox will be restarted after crash, thus not logging me out of X session and not losing any work), further crashes seem to come faster (sometimes after further 5 or 10 minutes, sometimes after mere 5 seconds) I've not experienced crashes when JOSM is not running, or if it is running, but I am not actively using it, like when window with it is merely opened and being on background, so I guess something in JOSM must be the cause that triggers the crash.

Original comment by: bilboq

[sillysloft]

I suspect that I got the same issue on Solaris x86, fluxbox git from October 2009 (plus some patching to make the build work with the Sun compiler... akira might remember me -- Hi, it's me, Thomas *wink* ;-). This is the backtrace I get from the Sun debugger:

program terminated by signal ABRT (Abort) 0xfe979315: __lwp_kill+0x0015: jae __lwp_kill+0x23 [ 0xfe979323, .+0xe ] (dbx) where =>[1] __lwp_kill(0x1, 0x6), at 0xfe979315 [2] _thr_kill(0x1, 0x6), at 0xfe974188 [3] raise(0x6), at 0xfe921d73 [4] abort(0x80451e0, 0xfec02a00, 0xfe9ec000, 0x8045080, 0x8390e44, 0x80451c8), at 0xfe901bbd [5] Fluxbox::handleSignal(0x83751f8, 0xb), at 0x8170a49 [6] FbTk::SignalHandler::handleSignal(0xb, 0x0, 0x8045240), at 0x812b560 [7] __sighndlr(0xb, 0x0, 0x8045240, 0x812b520), at 0xfe975dbf [8] call_user_handler(0xb, 0x0, 0x8045240), at 0xfe96bab5 [9] sigacthandler(0xb, 0x0, 0x8045240, 0xf, 0x0, 0x0), at 0xfe96bbdf ---- called from signal handler with signal 11 (SIGSEGV) ------ [10] FbTk::SigImpl::Signal3<void,BScreen&,FluxboxWindow*,WinClient*>::emit(0xb6b6d6, 0xb6b6b6, 0x84355f8, 0x8431c70, 0x0, 0x0), at 0x8293b55 [11] FocusControl::setFocusedWindow(0x8431c70, 0x0), at 0x8180937 [12] Fluxbox::handleEvent(0x83751f8, 0x804584c), at 0x8170394 [13] Fluxbox::eventLoop(0x83751f8, 0x0), at 0x816d45f [14] main(0x1, 0x8046be8, 0x8046bf0, 0x80ca4bd), at 0x81a1742

So, this is triggered in FocusControl::setFocusedWindow(0x8431c70, 0x0) ... just like the initial report. I must assume that the two arguments mean the object instance pointer and a zero argument for WinClient *client (I'm not debugging C++ apps with dbx, usually). Anyhow... I'm trying to build current git HEAD ... with (more) debugging symbols -- although I didn't strip this binary, apparently the -g flag was missing during build. This will take some time... as I'm not yet prepared to just drop the Sun Compiler and you fluxbox folks have introduced some new GNU-isms, at least __FUNCTION__.

Original comment by: sobukus

[sillysloft]

I was able to build current git with Sun Studio after minor tweaking (#define __FUNCTION__ "something"), but that build doesn't even start for me:

program terminated by signal ABRT (Abort) 0xfe88a227: __lwp_kill+0x0007: jae __lwp_kill+0x15 [ 0xfe88a235, .+0xe ] Current function is Fluxbox::handleSignal 988 abort(); (dbx) where [1] __lwp_kill(0x1, 0x6), at 0xfe88a227 [2] _thr_kill(0x1, 0x6), at 0xfe88598f [3] raise(0x6), at 0xfe831ed3 [4] abort(0x8046230, 0xfec32a00, 0xfe8fd000, 0x8046194, 0xfe8798a1, 0xfec32a00), at 0xfe811d0d =>[5] Fluxbox::handleSignal(this = 0x83a4948, signum = 11), line 988 in "fluxbox.cc" [6] FbTk::SignalHandler::handleSignal(signum = 11), line 68 in "SignalHandler.cc" [7] __sighndlr(0xb, 0x0, 0x8046284, 0x82d6540), at 0xfe8875af [8] call_user_handler(0xb, 0x0, 0x8046284), at 0xfe87d290 [9] sigacthandler(0xb, 0x0, 0x8046284, 0xf, 0x0, 0x0), at 0xfe87d3ba ---- called from signal handler with signal 11 (SIGSEGV) ------ [10] std::list<FbTk::SigImpl::SlotHolder,std::allocator<FbTk::SigImpl::SlotHolder> >::erase(this = 0x8497e8c, position = CLASS), line 604 in "list" [11] FbTk::SigImpl::SignalHolder::disconnect(this = 0x8497e8c, slotIt = CLASS), line 69 in "Signal.hh" [12] FbTk::SignalTracker::leaveAll(this = 0x849acd0), line 270 in "Signal.hh" [13] FbTk::SignalTracker::~SignalTracker(this = 0x849acd0), line 225 in "Signal.hh" [14] IconButton::~IconButton(this = 0x849ab00), line 76 in "IconButton.cc" [15] __SLIP.DELETER__D(0x849ab00, 0x1), at 0x826ac8e [16] FbWinFrame::removeTab(this = 0x849902c, btn = 0x849ab00), line 625 in "FbWinFrame.cc" [17] FluxboxWindow::~FluxboxWindow(this = 0x8498b10), line 352 in "Window.cc" [18] __SLIP.DELETER__C(0x8498b10, 0x1), at 0x821572e [19] FluxboxWindow::attachClient(this = 0x84c0288, client = CLASS, x = -1, y = -1), line 614 in "Window.cc" [20] BScreen::createWindow(this = 0x83bea38, client = 14680086U), line 1317 in "Screen.cc" [21] BScreen::initWindows(this = 0x83bea38), line 701 in "Screen.cc" [22] Fluxbox::initScreen(this = 0x83a4948, screen = 0x83bea38), line 451 in "fluxbox.cc" [23] Fluxbox::Fluxbox(this = 0x83a4948, argc = 1, argv = 0x804726c, dpy_name = 0xfeab417c "", rcfilename = 0xfeab417c "", xsync = false), line 396 in "fluxbox.cc" [24] main(argc = 1, argv = 0x804726c), line 293 in "main.cc"

All that internal signal handling makes it difficult to see where the segmentation fault was raised... Is it IconButton::~IconButton() ? Well, that's a different crash in any case.

Original comment by: sobukus

[sillysloft]

• assigned_to: nobody --> akir
• status: open --> open-accepted

Original comment by: akir

[sillysloft]

Although it is very likely a different crash than the initial report, I'm updating with my latest experience here, since there's already context. But I'm aware that I'm hijacking this report somewhat. Sorry.

Another go with today's git. I need two hacks to build it with Studio 12 under Solaris: 1. #define __FUNCTION__ "GNUism" 2. #!/bin/bash in fluxbox-generate_menu

So I build with Sun Studio 12.1 under Solaris 10, CFLAGS=-g ... that is the result:

$ dbx /x86-64/SunOS/studio12/bin/fluxbox For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 7.7' in your .dbxrc Reading fluxbox Reading ld.so.1 Reading libnsl.so.1 Reading libsocket.so.1 Reading libSM.so.6 Reading libICE.so.6 Reading libX11.so.4 Reading libXft.so.2 Reading libfreetype.so.6 Reading libXrender.so.1 Reading libfontconfig.so.1 Reading libXpm.so.4 Reading libXinerama.so.1 Reading libXext.so.0 Reading libCstd.so.1 Reading libCrun.so.1 Reading libm.so.2 Reading libc.so.1 (dbx) run Running: fluxbox (process id 10860) Reading de_DE.UTF-8.so.3 Reading methods_unicode.so.3 Reading UTF-8%8859-1.so Reading 8859-1%UTF-8.so Reading UTF-8%UTF-8.so Reading libdl.so.1 Reading xlcUTF-8.so.2 Keys: Invalid key/modifier on line 52): OnDesktop Mouse3 :RootMenu Keys: Invalid key/modifier on line 53): OnDesktop Mouse1 :WorkSpaceMenu Reading libexpat.so.1.5.2 signal SEGV (no mapping at the fault address) in std::list<FbTk::SigImpl::SlotHolder,std::allocator<FbTk::SigImpl::SlotHolder> >::erase at line 604 in file "list" 604 (*(__link_type((*position.node).next))).prev = (*position.node).prev; (dbx) where =>[1] std::list<FbTk::SigImpl::SlotHolder,std::allocator<FbTk::SigImpl::SlotHolder> >::erase(this = 0x92acb0, position = CLASS), line 604 in "list" [2] FbTk::SigImpl::SignalHolder::disconnect(this = 0x92acb0, slotIt = CLASS), line 69 in "Signal.hh" [3] FbTk::SignalTracker::leave(this = 0x9c9600, id = CLASS, disconnect = true), line 251 in "Signal.hh" [4] FbTk::SignalTracker::leaveAll(this = 0x9c9600), line 270 in "Signal.hh" [5] FbTk::SignalTracker::~SignalTracker(this = 0x9c9600), line 224 in "Signal.hh" [6] SendToMenu::~SendToMenu(this = 0x9c92b0), line 75 in "SendToMenu.cc" [7] __SLIP.DELETER__C(0x0, 0x0, 0x0, 0x0, 0x0, 0x0), at 0x71fbbd [8] FbTk::Menu::remove(this = 0x996bd0, index = 7U), line 260 in "Menu.cc" [9] FbTk::Menu::removeAll(this = 0x996bd0), line 286 in "Menu.cc" [10] BScreen::rereadWindowMenu(this = 0x92a940), line 1487 in "Screen.cc" [11] BScreen::addExtraWindowMenu(this = 0x92a940, label = CLASS, menu = 0xa51ca0), line 897 in "Screen.cc" [12] Remember::initForScreen(this = 0x9ac780, screen = CLASS), line 1407 in "Remember.cc" [13] Fluxbox::initScreen(this = 0x9061b0, screen = 0x92a940), line 476 in "fluxbox.cc" [14] Fluxbox::Fluxbox(this = 0x9061b0, argc = 1, argv = 0xfffffd7fffdfe7d8, dpy_name = 0xfffffd7ffeeb99c8 "", rcfilename = 0xfffffd7ffeeb99c8 "", xsync = false), line 396 in "fluxbox.cc" [15] main(argc = 1, argv = 0xfffffd7fffdfe7d8), line 293 in "main.cc" (dbx) quit

Original comment by: sobukus

[sillysloft]

• status: open-accepted --> closed-fixed

Original comment by: lack

[sillysloft]

This signal handling bug has been fixed in the latest git as of:

commit a3b063292c003a32c72859f3eecc92de6e1dd132 Author: Jim Ramsay <i.am@jimramsay.com> Date: Wed Jul 14 11:36:00 2010 -0400

bugfix: another crash when cleaning up signals

While 769130f51a8f did fix one issue, it introduced another by changing the logic related to the new SignalTracker. The original logic (introduced in 9ad388c5bf16) was: -> in 'leave(Signal)', only call 'disconnect' -> in 'leaveAll()', call 'disconnect' and 'disconnectTracker' But 769130f51a8f inverted this, calling 'disconnectTracker' in both cases but only 'disconnect' in the 'leaveAll()' case, which would leave unattached signals around after calling 'leave(Signal)'.

This fix not only repairs the logic, but renames the ambiguous 'disconnect' boolean to something more explicit: 'withTracker'.

Original comment by: lack