Michal Jaegermann (michal@ellpspace.math.ualberta.ca)
Mon, 28 Dec 1998 11:19:00 -0700 (MST)
Designer 7 wrote:
>
> Anyone tried using rxvt on alpha?
Yes, I am using it all the time for some years (on alpha).
> I'm on kernel 2.1.131 w/ac11. Rxvt
> keeps crashing with segmentation fault and core dump.
There is probably a long list of different versions of rxvt, recompiled
with different headers and so on.
> I recompiled from source (with -g, no -O?), same problem. Then I tried
> to debug, but I'm not an expert with gdb (can anyone help?).
Type 'info gdb'. There are also some graphic front ends to gdb
(like xgdb - if my memory serves me right). It is also a good idea
to run gdb from emacs (M-x gdb); gdb has extensive on-line help.
gdb can be also attached to an already running process ('help attach'
at gdb prompt).
BTW - it is usually a good idea to compile for debugging with -O2,
or at least -O, flag; but not with -fomit-frame-pointer. Once you
will gain some experience with debugging with gdb you will see why.
True, some variables may "disappear" but gains are bigger than
losses.
> I got a
> message saying "dl-debug.c: file does not exist" when i tried a 'list'
> after rxvt seg faults.
Does it exist? Maybe you have to add a directory to a list of
directories searched ('help dir' at gdb prompt).
> I tried a 'info line *0x????????' on the
> addresses that were outputed by gdb. This got me the message: "no line
> info for 0x???????". Backtrace didn't give anything useful either.
This sounds like one of two classics:
- either there is "off-by-one" error somewhere and you write
past memory you allocated in a form of an automatic array on stack
- or somebody is passing int to a function which expects long
or vice-versa (this bug is masked on Intel processor as long and
int happen there to have the same size) or something of a similar
kind.
In both cases you already messed up your stack and an information
you are trying to read is garbled and invalid. You have to stop
the whole process before that and trace down, step-by-step, to find out
what is killing your stack. Attaching 'strace' to your process and
analizing its output while you performed actions leading to a crash
can be of help here.
There are other ways to kill your stack but the two above are the
most popular. There can be a bad interaction with your kernel
(some structures are misaligned) but in theory rxvt is a user space
application and it should not care at all what kernel you are
running. This theory may be not entirely true in practice :-) but
rxvt is not something which has to mess up with network packets,
or something of that sort, so the theory should generally apply.
> Anyways... I'm going to try to figure out how to use gdb better... but
> in the mean time, does anyone know of this problem already? And is there
> a fix? Any suggestions on using gdb?
This is a bit of mystery as I am using rxvt with various Red Hat
distributions and I never seen something even close. When you ask
questions like that an information about your enviroment and versions
of things you are using can be a crucial one. It is missing from
what you posted.
Michal
-- To unsubscribe: send e-mail to axp-list-request@redhat.com with 'unsubscribe' as the subject. Do not send it to axp-list@redhat.com
This archive was generated by hypermail 2.0b3 on Sun Jan 24 1999 - 14:47:45 PST