Bug#544145: libc6-i686 - Segfaults on amd64/xen
On Sat, Aug 29, 2009 at 10:33:24AM +0200, Aurelien Jarno wrote:
> On Sat, Aug 29, 2009 at 09:14:40AM +0200, Bastian Blank wrote:
> > The system uses a amd64 kernel and userland on Xen.
> This flavour works perfectly on a non-Xen system. is there also some
> requirements on the compilation of glibc on Xen amd64, like on i386?
Not that I'm aware of. But the memory layout may be different.
Debugging a live binary is impossible as it already breaks before the
debugging setup.
A core file shows:
| #0 0xf7fb1000 in ?? ()
| #1 0xf7e0bdc8 in _init () at /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:24
This seems to come from /lib/i686/cmov/libpthread.so.0
| #2 0xf7fbf284 in call_init (l=0xf7dfd720, argc=1, argv=0xffa03094, env=0xffa0309c) at dl-init.c:70
| #3 0xf7fbf416 in _dl_init (main_map=0xf7fce670, argc=1, argv=0xffa03094, env=0xffa0309c) at dl-init.c:100
| #4 0xf7fb188f in _dl_start_user () from /lib/ld-linux.so.2
| (gdb) up
| #1 0xf7e0bdc8 in _init () at /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S:24
| 24 /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S: No such file or directory.
| in /build/buildd-eglibc_2.9-25-i386-IXOntq/eglibc-2.9/build-tree/i386-i686/nptl/crti.S
| Current language: auto; currently asm
| (gdb) disassemble
| Dump of assembler code for function _init:
| 0xf7e0bdc0 <_init+0>: push %ebp
| 0xf7e0bdc1 <_init+1>: mov %esp,%ebp
| 0xf7e0bdc3 <_init+3>: call 0xf7e0c380 <__pthread_initialize_minimal_internal>
| 0xf7e0bdc8 <_init+8>: call 0xf7e0c2c0 <frame_dummy>
| 0xf7e0bdcd <_init+13>: call 0xf7e18040 <__do_global_ctors_aux>
| 0xf7e0bdd2 <_init+18>: pop %ebp
| 0xf7e0bdd3 <_init+19>: ret
| End of assembler dump.
| (gdb) disassemble 0xf7e0c2c0
| Dump of assembler code for function frame_dummy:
This function seems to come from gcc.
| 0xf7e0c2c0 <frame_dummy+0>: push %ebp
| 0xf7e0c2c1 <frame_dummy+1>: mov %esp,%ebp
| 0xf7e0c2c3 <frame_dummy+3>: push %ebx
| 0xf7e0c2c4 <frame_dummy+4>: call 0xf7e0c230 <__i686.get_pc_thunk.bx>
| 0xf7e0c2c9 <frame_dummy+9>: add $0x11d2b,%ebx
| 0xf7e0c2cf <frame_dummy+15>: sub $0x4,%esp
| 0xf7e0c2d2 <frame_dummy+18>: mov -0x214(%ebx),%edx
| 0xf7e0c2d8 <frame_dummy+24>: test %edx,%edx
| 0xf7e0c2da <frame_dummy+26>: je 0xf7e0c2f1 <frame_dummy+49>
| 0xf7e0c2dc <frame_dummy+28>: mov -0x28(%ebx),%edx
| 0xf7e0c2e2 <frame_dummy+34>: test %edx,%edx
| 0xf7e0c2e4 <frame_dummy+36>: je 0xf7e0c2f1 <frame_dummy+49>
| 0xf7e0c2e6 <frame_dummy+38>: lea -0x214(%ebx),%eax
| 0xf7e0c2ec <frame_dummy+44>: mov %eax,(%esp)
| 0xf7e0c2ef <frame_dummy+47>: call *%edx
| 0xf7e0c2f1 <frame_dummy+49>: add $0x4,%esp
| 0xf7e0c2f4 <frame_dummy+52>: pop %ebx
| 0xf7e0c2f5 <frame_dummy+53>: pop %ebp
| 0xf7e0c2f6 <frame_dummy+54>: ret
| 0xf7e0c2f7 <frame_dummy+55>: nop
| 0xf7e0c2f8 <frame_dummy+56>: nop
| 0xf7e0c2f9 <frame_dummy+57>: nop
| 0xf7e0c2fa <frame_dummy+58>: nop
| 0xf7e0c2fb <frame_dummy+59>: nop
| 0xf7e0c2fc <frame_dummy+60>: nop
| 0xf7e0c2fd <frame_dummy+61>: nop
| 0xf7e0c2fe <frame_dummy+62>: nop
| 0xf7e0c2ff <frame_dummy+63>: nop
| End of assembler dump.
| (gdb) print {char[4]}0xf7fb1000
| $7 = "\177ELF"
Hmm, just below the dynlinker, we have the vdso. If I debug a binary
without using the i686/cmov libs then I miss the symbols for the vdso
so, it looks like they are never used.
Bastian
--
It would be illogical to assume that all conditions remain stable.
-- Spock, "The Enterprise Incident", stardate 5027.3
Reply to: