Menu
▾
▴
#1077 fluxbox-1.3.3 segfault
The attached ~/.fluxbox/ tar is the smalles subset of settings I could find that causes fluxbox 1.3.3 to segfault for me.
It's a combination of MerleyKay style + Overlay with modifications to that style + gmpc (Gnome Music Player Client) in the startup script. Why gmpc? I have no clue, maybe related to that it puts one of those icon things into the toolbar.
The segfault itself does not seem to be entirely deterministic. Sometimes it segfaults, sometimes it has graphical glitches in the toolbar. Maybe related to how long gmpc takes to start up?`!
Let me know if you can reproduce this at all, at all
Thank you :)
~/.fluxbox
do you have a (gdb) backtrace?
attached a bt full
gdb backtrace
which (git)-version of fluxbox was used to create that bt?
I thought I was using 1.3.3
I can grab a git and try with it later
gdb backtrace with today's git
attached a new bt with today's git
git log shows this to be the last commit in the version I used
commit 239e895826b2f843bc50cc6fef8108db174c33e8
Author: Mathias Gumz <akira at fluxbox dot org>
Date: Sun Jan 13 12:44:19 2013 +0100
Ensure textures have the correct size bevor applying 'bevel'
could you please report the compiler and the compiler-flags?
Using Gentoo ~amd64, gcc 4.6.3. Which compile flags do you want me to use? My default is -O2 -march=native -pipe, for debugging I used -O2 -pipe -ggdb or -O0 -pipe -ggdb...
Any debug messages I could add as would help you find the issue, let me know...
Thanks for your efforts!
i can't reproduce the situation right now with gcc-4.7.2 and amd64 and on debian and on xephyr. whatever that means :)
i checked the code with several memory-analysis tools (memcheck from valgrind, intels inspector, some more). not many point into the area the crash is happening. the bt points into some "double free" area of the code, but right now i am not able to identify it.
we will see, what we find in the future.
I tried "exec valgrind startfluxbox" instead of "exec startfluxbox" in the startup file. But when I do that fluxbox is really slow on start up and the segfault does not happen anymore... I'll attach a valgrind.txt anyway on the off chance there is anything you haven't seen yet in mine
valgrind (or most other augmenting techniques) will slow down the binary in question a lot, typical factors range from 2 to 200.
I also tried starting gmpc later using various sleep delays. In case it was somehow timing related (so it doesn't happen with a "slow" fluxbox). But no dice.
When I removed valgrind again, for some reason, fluxbox stopped segfaulting despite starting with same style, overlay, gmpc startup. It started segfaulting again when restoring the fluxbox-crash ~/.fluxbox thing. Unfortunately I didn't think of archiving the "doesn'tsegfault" state to find out what else changed.
Some weird issue this is. I'll just stick with 1.3.2 for now.
the strange thing i noticed was that the texture which should be rendered is 1px tall. i augmented my texture-render code here and even with your settings i was not able to get that 1px tall texture.
could you please attach the "changed" style file?
related: https://sourceforge.net/p/fluxbox/bugs/1116/
related: http://git.fluxbox.org/fluxbox.git/commit/?id=7b8fd2d81ad80a73564fc9fbb779f47568f12652
please report back, if this change fixes also this issue.
i consider this bug beeing a "duplicate" of #1116 (allthough you reported it first). the code received a very small window and was not prepared to deal with 'the sum can't be negative' (which is a optimistic assumption when one starts with a 1x1 window :))