#1076 fluxbox-1.3.3 ArrangeWindowsVertical crashes
In my .fluxbox/keys I have this set up:
Super_R :ExecCommand urxvt
Shift Super_R :ArrangeWindowsVertical
So when I press the right windows key, it spawns urxvt. But Shift + Right Windows Key arranges windows.
When I press Super_R to get urxvt, and Shift Super_R to immediately arrange it, fluxbox hangs. Nothing works anymore, top shows fluxbox eating 100% CPU. I can still move the mouse pointer but not actually click on anything. I can reproduce the issue instantly by pressing Super_R and Shift Super_R a couple of times. Maybe a problem if ArrangeWindowsVertical runs at the same time a new window is created?
Attaching to the process with strace shows nothing whatsoever; attaching with gdb shows eventloop updating timers.
(gdb) bt full
#0 0x00000000004ceb23 in _M_lower_bound (__y=0x72d148 <(anonymous namespace)::s_timerlist+8>, __k=@0x7fff06a6e238: 0x1b55240, __x=0x1b0f1d0, this=<optimized out>)
at /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_tree.h:1090
No locals.
#1 find (__k=@0x7fff06a6e238: 0x1b55240, this=0x72d140 <(anonymous namespace)::s_timerlist>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_tree.h:1536
No locals.
#2 find (__x=@0x7fff06a6e238: 0x1b55240, this=0x72d140 <(anonymous namespace)::s_timerlist>) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4/bits/stl_set.h:605
No locals.
#3 FbTk::Timer::updateTimers (fd=<optimized out>) at Timer.cc:212
t = 0x1b55240
timeout = <optimized out>
rfds = {fds_bits = {0 <repeats 16 times>}}
tm = {tv_sec = 0, tv_usec = 0}
it = <optimized out>
now = 3204058027
end_time = 28372168
#4 0x0000000000418ac8 in Fluxbox::eventLoop (this=0x1a3b8b0) at fluxbox.cc:533
disp = 0x1a3a0d0
#5 0x000000000040acc4 in main (argc=1, argv=0x7fff06a6e808) at main.cc:494
opts = {session_display = ":1", rc_path = "/home/andreas/.fluxbox", rc_file = "/home/andreas/.fluxbox/init", log_filename = "", xsync = false}
errbuf = 0x0
i18n = @0x72ce20: {m_locale = "en_US.UTF-8", m_multibyte = true, m_utf8_translate = false, m_catalog_fd = 0x1a17260}
outbuf = 0x0
log_file = <incomplete type>
exitcode = 1
fluxbox = {_M_ptr = 0x1a3b8b0}
restarting = <optimized out>
restart_argument = "\274"
I'm getting this problem too. 100% cpu usage, mouse is movable nothing else. Although I'm getting it randomly it seems, I've bound CTRL + arrows to move windows, CTRL+SUPER+arrows to resize windows with MoveLeft/MoveRight and that also seems to be enough to crash it.
Had to downgrade to 1.3.2 where it works fine, impossible to use 1.3.3 atm :( This seems like a serious issue.
(Running bleeding edge Arch Linux 64bit)
The high cpu use and only being able to move the mouse sounds exactly like what happens when you trigger the worst case of the "flickering titlebar tooltip gets pinned to the mouse cursor - ID: 3590078" bug.
Maybe they have the same root cause?
I wonder if one of the timing changes in 1.3.3 broke some code that depended on the old behavior?
I had the flickering toolbar as well, but not in relation with the hangs.
I tried adding debugging messages and it seems the hang happens outside the ArrangeWindows. That's only what triggers the hang somehow. I'm still using the (apparently?) buggy version of fluxbox fine and stable, so far no crashes as long as I don't try to (frequently) arrange windows.
Unfortuantely I can not make heads or tails of the code where the hang occurs, so someone more experienced will have to dive in and have a look
yep, it's the timer code. i changed that a bit in 2012-08 / 2012-09 with commits 541c8c407b7ba8dd10f85bb48bcb5900270b3f84 / 59d097bcead9b349e20a4ec193d76330e6899e53
it's most likely something in that area, most likely the 2nd one. we will figure it out.
Great, thanks and keep up the good job with Fluxbox!
please try:
http://dev.darkshed.net/fluxbox/timer_fix.diff
that diff appears to give me a segfault or something
*** glibc detected *** /usr/bin/fluxbox: free(): invalid next size (normal): 0x00000000027e9d40 ***
compiler, os? did you make a clean build?
Gentoo ~amd64, gcc 4.6.3, tried both with and without Gentoo's own patches. Also compiled it manually (configure make make install to /usr/local/ after uninstalling fluxbox in /usr - and getting rid of it again with make uninstall - I'll have to verify whether this catched everything).
The crash happens with and without the timer_fix.diff. It doesn't happen when I rename my ~/.fluxbox (so it makes a fresh one). I did make some configuration changes there yesterday so I assume something now triggers the crash with 1.3.3, whereas it works fine with 1.3.2.
I'm in a bit of a pickle now as whatever was letting me reproduce the 100% CPU hang so far, does no longer happen at all with a fresh ~/.fluxbox (and just the hotkeys added). So right now I can't reproduce the hang anymore but instead get a segfault.
I'll do some more testing now... sorry for all the confusion
give me a bt of the segfault and we'll figure it out. the fix should have addressed the 100%cpu thingy. the crash might be something different.
OK, using the MerelyKay style with this ~/.fluxbox/overlay http://bpaste.net/show/69289/ seems to be involved in causing the segfault http://bpaste.net/show/69297/ , at least it's not happening any more with that overlay removed. And I can reproduce the timer hangs again, wheee.
I can reproduce the hang without your timer_fix everytime, with the timer_fix so far I didn't manage to.
I'm possibly more or less not definitely rejecting the idea that in no way with any amount of uncertainty that I undeniably do or do not know whether your patch fixes the issue. But it seems probably to be the case if hanging is indeed what isn't happening.
the bt regarding the crash points into the rewritten render code. open a new bug with the backtrace and the style. and please attach the backtrace as a file, not a link to a site which might delete that backtrace any time.
so, does this timer_fix.diff makes the ArrangeWindows crash?
...thought I'd replied to this.
timer_fix.diff appears to work (maybe someone can provide a second opinion)
the other segfault seems unrelated, I created a new ticket
fxied with 4d307dcd10af9d817ff5c05fc40ae7487564cb31