Matt Wagner (matt.c.wagner@uwrf.edu)
Mon, 28 Dec 1998 13:04:48 -0600 (CST)
i have experienced the same problems with rxvt in Redhat 5.2.
On Mon, 28 Dec 1998, Michal Jaegermann wrote:
> 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
>
>
----------------------------------
the SYSTEM owns you
SYSTEM, n.:
1: a regular union of principles or parts forming one entire thing.
2: the economic/capitalistic entity that exploits *your* life.
3: that strange attractor in your perception of the world that you
have dubbed as, "they".
wags@driver8.org http://www.driver8.org/
http://www.mw.driver8.org/
-- 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