libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[libunwind] SIGSEGV trying unw_get_reg on Linux_IA64


From: Mensing, Joerg
Subject: [libunwind] SIGSEGV trying unw_get_reg on Linux_IA64
Date: Tue, 15 Feb 2005 15:49:36 +0100

Hello,

Enviroment Linux SLES9/ia64 (gcc 3.3.3-43.24, glibc-2.3.3-98.28):

1) I am happily using libunwind.0.98.3 for MaxDB stack backtrace on SuSE 
Linux_ia64/SLES9 x86_64 and ia64.
I do a 'configure; make AF_CFLAGS=-fPIC;make install' locally and link my 
programs with 
        '-lgcc_eh $UNWINDLIBS/libunwind-ia64.a $UNWINDLIBS/libunwind.a'
which allows me to use the libunwind as a 'stack backtrace only' 
implementation. I know the glibc unwinder is buggy and not ABI conform, but i 
am loading DLL's compiled with the 'original' unwinder that throw exceptions 
which are caught in the main executable. Without this trick exception unwinding 
is not handled correctly...

I found a small problem during dumping registers in my stack backtrace code 
pinned to down to

        unw_get_reg(&cursor, registerIndex, &regValue);

For registerIndex 140 (alias nat12) in src/ia64/unwind_i.h line 96 a NULL 
pointer is dereferenced leading to SIGSEGV:

(gdb) where
#0  _ULia64_uc_addr (uc=0x60000fffffff9e70, reg=140, nat_bitnr=0x0)
    at unwind_i.h:96
#1  0x4000000000011e70 in _ULia64_scratch_loc (c=0x6000000000025b30, reg=140, 
    nat_bitnr=0x60000fffffff9d60 "\022\232") at Gregs.c:198
#2  0x4000000000012d90 in _ULia64_access_reg (c=0x6000000000025b30, reg=140, 
    valp=0x6000000000009990, write=0) at Gregs.c:324
#3  0x4000000000010310 in _ULia64_get_reg (cursor=0x6000000000025b30, 
    regnum=140, valp=0x6000000000009990) at Gget_reg.c:33
#4  0x40000000000055d0 in eo670_UnixTraceStack ()


I modified my libunwind source locally to work around it:

$ diff unwind_i.h_ori unwind_i.h_fixed 
96c96,99
<       *nat_bitnr = reg - UNW_IA64_NAT;
---
>       if ( nat_bitnr )
>       {
>         *nat_bitnr = reg - UNW_IA64_NAT;
>       }

Could you please verify my patch and if it is ok, incorporate it in your 
sources ?

2) Before i call the stack backtrace code, i set an emergency hook by using 
sigsetjmp() to protect the running database server. I do not expect a SIGSEGV 
really, but you never know (see problem 1). The 'setsetjmp()' is currently the 
orginal one, that comes with the glibc. It seems to do really strange things 
with the stack frame. If a single step behind sigsetjmp() call the gdb suddenly 
reports. The stack is not really corrupted! If i leave the scope of 'sub()' the 
gdb can produce the stack backtrace again...

#0  sub () at t.c:9
#1  0x0000000000000000 in ?? ()
Previous frame identical to this frame (corrupt stack?)

I verifed this with a primitive example (cc -g -o t t.c):
---->8---->8---->8---- t.c ---->8---->8---->8---- 
#include <stdio.h>
#include <signal.h>
#include <setjmp.h>

sigjmp_buf emergencyJmp;

void sub() {
    if ( 0 == sigsetjmp( emergencyJmp, 1) ) {
        printf("Behind sigsetjmp\n");
    }
}

int main(int argc, char *argv[]) {
    sub();
    return 0;
}
---->8---->8---->8---- t.c ---->8---->8---->8---- 

I tried to link libunwind-setjmp.a ( cc -g -o t t.c libunwind-setjmp.a ) to 
work around this glibc feature, but i failed also.
(gdb) where
#0  __sigsetjmp () at ia64/sigsetjmp.S:40
#1  0x4000000000000860 in sub () at t.c:8
#2  0x0000000000000000 in ?? ()

I can use sigsetjmp() on Linux_x86_64 with libunwind and still get a stack 
backtrace but on Linux_ia64 i have to remove the sigsetjmp() calls to get it. 
Is there any workaround for that?

3) Do you have any more news about the missing glibc unwinding info which does 
not allow to unwind beyond system call on linux_x86_64? The comments in your 
Bug report http://sources.redhat.com/bugzilla/show_bug.cgi?id=595 does not 
really seem promising and i see no other way to get stack backtrace in a signal 
handler for linux_x86_64 without it.... For linux_x86 i returned to use 
assembler stack backtrace coding and live with the immenant danger of general 
-fomit-frame-pointers usage on Linux_x86

4) I would make me much more happy not to link with -lgcc_eh.... Maybe i missed 
that discussion, but will (or has) your unwinder (or at least a compatible 
implementation) replace (or replaced) glibc's buggy unwinder in a standard 
distribution (i.e. Plans for LSB 3.0) ? I could forward it as an issue to LSB 
3.0 group if you like!

Best regards
Jörg Mensing
SAP AG
NW DT MaxDB&liveCache Berlin
Rosenthalerstr. 30
D-10178 Berlin
Germany

reply via email to

[Prev in Thread] Current Thread [Next in Thread]