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

Bug#220584: upgrade to 2.3.2.ds1-10 makes everything linked to libpthread segfault



On Thursday 13 November 2003 16:12, Daniel Jacobowitz wrote:

> Ldd says that it's using the copy in /lib, right?

couscous:/lib# ldd /bin/ls
        librt.so.1 => /lib/librt.so.1 (0x4001c000)
        libacl.so.1 => /lib/libacl.so.1 (0x4002e000)
        libc.so.6 => /lib/libc.so.6 (0x40035000)
        libpthread.so.0 => /lib/libpthread.so.0 (0x40167000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
        libattr.so.1 => /lib/libattr.so.1 (0x401b7000)

> > > (C) Can you get gdb to show you where something is crashing?

(gdb) run
Starting program: /bin/ls 
(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...(no debugging symbols found)...[New Thread 16384 (LWP 11477)]
(no debugging symbols found)...(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 16384 (LWP 11477)]
0x00000000 in ?? ()
(gdb) info shared
From        To          Syms Read   Shared Object Library
0x4001db20  0x40021940  Yes         /lib/librt.so.1
0x4002f4c0  0x40032efc  Yes         /lib/libacl.so.1
0x4004abc0  0x40140278  Yes         /lib/libc.so.6
0x4016b070  0x40172cd0  Yes         /lib/libpthread.so.0
0x40000be0  0x40011d5f  Yes         /lib/ld-linux.so.2
0x401b7d60  0x401b928c  Yes         /lib/libattr.so.1
(gdb) backtrace
#0  0x00000000 in ?? ()
(gdb) info registers
eax            0x40173200       1075261952
ecx            0x53     83
edx            0xbffff7c4       -1073743932
ebx            0x40173d38       1075264824
esp            0xbffff7d8       0xbffff7d8
ebp            0xbffffb14       0xbffffb14
esi            0x400164e0       1073833184
edi            0x40173200       1075261952
eip            0x0      0x0
eflags         0x10206  66054
cs             0x23     35
ss             0x2b     43
ds             0x2b     43
es             0x2b     43
fs             0x0      0
gs             0x0      0
(gdb) x/10i $pc
0x0:    Cannot access memory at address 0x0
(gdb) 

Hmmm. I don't know anything about the stack layout on IA32 - but I guess
the address at $esp is the return address - seems to make sense from the 
output below.

(gdb) x/16 $esp
0xbffff7d8:     0x4016df9d      0x400166ac      0x40017054      0xbffffa70
0xbffff7e8:     0x00000022      0x53203223      0x4420504d      0x4e206e6f
0xbffff7f8:     0x3620766f      0x3a363120      0x323a3330      0x45432031
0xbffff808:     0x30322054      0x00003330      0x00000000      0x00000000
(gdb) x/16i 0x4016df9d-0x20
0x4016df7d <pthread_initialize+457>:    xchg   %eax,%ebp
0x4016df7e <pthread_initialize+458>:    rorb   $0x0,0x1a093(%ebx)
0x4016df85 <pthread_initialize+465>:    movzbl %al,%eax
0x4016df88 <pthread_initialize+468>:    mov    %eax,(%edx)
0x4016df8a <pthread_initialize+470>:    call   0x4016dda0 <__libc_dl_error_tsd>
0x4016df8f <pthread_initialize+475>:    mov    0x17c(%ebx),%esi
0x4016df95 <pthread_initialize+481>:    mov    %eax,%edi
0x4016df97 <pthread_initialize+483>:    call   *0xa4(%esi)
0x4016df9d <pthread_initialize+489>:    mov    (%eax),%eax
0x4016df9f <pthread_initialize+491>:    mov    %eax,(%edi)
0x4016dfa1 <pthread_initialize+493>:    lea    0xffffa068(%ebx),%eax
0x4016dfa7 <pthread_initialize+499>:    mov    %eax,0xa4(%esi)
0x4016dfad <pthread_initialize+505>:    jmp    0x4016ddd8 <pthread_initialize+36>
0x4016dfb2 <pthread_initialize+510>:    sub    $0x8,%esp
0x4016dfb5 <pthread_initialize+513>:    push   $0x0
0x4016dfb7 <pthread_initialize+515>:    lea    0xfffff000(%ebx),%eax

%esi points to _rtld_global:
(gdb) x/16i $esi     
0x400164e0 <_rtld_global>:      mov    $0x740016e,%eax
0x400164e5 <_rtld_global+5>:    add    %al,(%eax)
0x400164e7 <_rtld_global+7>:    add    %cl,(%eax)
0x400164e9 <_rtld_global+9>:    jo     0x400164ec <_rtld_global+12>
...


> Some of that should be useful.

I certainly hope so :-)

cheers
-- vbi


-- 
Worst Vegetable of the Year:
	The brussels sprout.  This is also the worst vegetable of next year.
		-- Steve Rubenstein

Attachment: pgp8hciFv5xMk.pgp
Description: signature


Reply to: