Menu
▾
▴
#175 Strange segfault with 0.65
I use Blackbox 0.65 compiled with gcc 3.3 on a system
equivalent to Red Hat 8.0 (or 9.0) -- I have updated by
RPM to the latest packages.
Blackbox has the win9x_buttons and flatborder patches
applied.
It has worked fine like this for a few months now. But
yesterday I got three unexpected crashes for no
apparent reason. Blackbox simply dies and dumps core at
seemingly random moments.
I managed to grab a backtrace from the core file, which
I have attached.
I can't reproduce the problem, it just happens.
FWIW, my ~/.blackboxrc is chmod 400, so it doesn't get
overwritten on exit.
Logged In: YES
user_id=667423
It seems that the crash has something to do with passing
mem=nopentium to the kernel at boot time. I can't be 100%
sure that is the cause, but I noticed the crash happens
always when the machine was booted with mem=nopentium and
never without.
mem=nopentium helps me avoid some X freeze problems which
otherwise occur due to the NVidia video card + AMD processor
combination.
I've only recently started using mem=nopentium, that would
explain why the recent crashes.
I've grabbed a couple more gdb backtraces but they all look
different from each other. I'll attach them if needed.
Logged In: YES
user_id=231518
I am running Red Hat 9 (and was running 8.0) with a Duron
1.1Ghz and a Riva TNT2 card... and have been using the
nvidia drivers since I got the card. I have never ever used
the mem=nopentium switch in the kernel boot config, and have
not had any of these problems
are you updated with the latest nvidia driver patch and did
you follow the instructions to remove certain of the X
switches in XF86Config after installing it?
Logged In: YES
user_id=667423
To webdragon: Yes, I have the latest NVidia and the proper X
config flags. However, that doesn't seem relevant anymore
since I finally got a segfault while running without
'mem=nopentium'. I will upload the backtrace later today.
To developers: are the backtraces of any use? They seem
different from one another and I can keep uploading them,
but I hope there's any point in doing that.
Logged In: YES
user_id=667423
I've added a couple of backtraces (marked 4 and 9) that are
different from the one already here (marked 3).
Logged In: YES
user_id=667423
FWIW: since experiencing this problem I've resorted to using
a shell script as the main X session application. The script
(called waitbb and attached) launches BlackBox, waits for
it's process ID to die, logs its PID, the BlackBox PID and
the time, then starts BlackBox again. Now the moments when
BB dies are reduced from X dying to window bars flashing off
and on again so it's bearable.
Logged In: YES
user_id=459209
Looking at these backtraces, I can see the problem... you are
hitting the same abort(), just from different places. What is
happening is that the GCCache in 0.65.0 cannot find any free
GC's, so it spits out a message and creates a core dump
(obviously).
I don't know why this would start happening all of a sudden,
but I can say that the code in CVS has matured quite a bit
recently, and I have not seen problems of this kind. If this
persists for 0.65.0, I can take a look at it, but for now, I am
inclined to simply say "wait for 0.70.x"