Re: HPPA and Squeeze
> That way we all would avoid debian build problems and could concentrate
> on solving the issues with the SMP kernel itself.
The problem actually may be present in UP kernels. I had a segv this
morning building GCC with a UP 2.6.30.1:
adave@mx3210:~/gnu/gcc/objdir/hppa-linux/libjava$ gdb -c core /bin/sh
GNU gdb (GDB) 6.8.50.20090510-cvs
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "hppa-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
(no debugging symbols found)
BFD: Warning: /home/dave/gnu/gcc/objdir/hppa-linux/libjava/core is truncated: expected core file size >= 196608, found: 118784.
Reading symbols from /lib/ld.so.1...Reading symbols from /usr/lib/debug/lib/ld-2.9.so...done.
done.
Loaded symbols for /lib/ld.so.1
Reading symbols from /lib/libncurses.so.5...done.
Loaded symbols for /lib/libncurses.so.5
Reading symbols from /lib/libdl.so.2...Reading symbols from /usr/lib/debug/lib/libdl-2.9.so...done.
done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libc.so.6...Reading symbols from /usr/lib/debug/lib/libc-2.9.so...done.
done.
Loaded symbols for /lib/libc.so.6
Core was generated by `/bin/sh -c /home/dave/gnu/gcc/gcc/mkinstalldirs `dirname gnu/java/locale/Locale'.
Program terminated with signal 11, Segmentation fault.
#0 _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12,
trace_mode=0, open_mode=0) at dl-deps.c:224
224 dl-deps.c: No such file or directory.
in dl-deps.c
(gdb) bt
#0 _dl_map_object_deps (map=0x403d8880, preloads=0x40001398, npreloads=12,
trace_mode=0, open_mode=0) at dl-deps.c:224
#1 0x403b9bd4 in dl_main (phdr=0x10034, phnum=<value optimized out>,
user_entry=<value optimized out>) at rtld.c:1780
#2 0x403cb898 in _dl_sysdep_start (start_argptr=<value optimized out>,
dl_main=@0x403d7566: 0x403b8fe4 <dl_main>) at ../elf/dl-sysdep.c:239
#3 0x403b785c in _dl_start_final (arg=0xbfff2020, info=0xbfff2348)
at rtld.c:332
#4 0x403b7adc in _dl_start (arg=0xbfff2020) at rtld.c:560
#5 0x403b742c in _start () from /lib/ld.so.1
#6 0x403b742c in _start () from /lib/ld.so.1
#7 0x403b742c in _start () from /lib/ld.so.1
#8 0x403b742c in _start () from /lib/ld.so.1
#9 0x403b742c in _start () from /lib/ld.so.1
#10 0x403b742c in _start () from /lib/ld.so.1
#11 0x403b742c in _start () from /lib/ld.so.1
#12 0x403b742c in _start () from /lib/ld.so.1
#13 0x403b742c in _start () from /lib/ld.so.1
#14 0x403b742c in _start () from /lib/ld.so.1
#15 0x403b742c in _start () from /lib/ld.so.1
#16 0x403b742c in _start () from /lib/ld.so.1
^CQuit
For some reason, gdb does terminate the backtrace. Recent versions
of gdb also complain about core file truncation. Think the full stack
region is not being dumped.
As with most of the segvs that I have debugged in the past, the problem
occurs in the dynamic loader.
This is the tombstone:
Jul 5 04:07:31 mx3210 kernel:
Jul 5 04:07:31 mx3210 kernel: do_page_fault() pid=22068 command='sh' type=15 address=0x00000004
Jul 5 04:07:31 mx3210 kernel: Jul 5 04:07:31 mx3210 kernel: YZrvWESTHLNXBCVMcbcbcbcbOGFRQPDI
Jul 5 04:07:31 mx3210 kernel: PSW: 00000000000001000000000000001111 Not taintedJul 5 04:07:31 mx3210 kernel: r00-03 000000000004000f 00000000403d76a0 0000000
0403c2c23 00000000bfff2ac0
Jul 5 04:07:31 mx3210 kernel: r04-07 00000000403d76a0 000000000000000c 0000000
040001398 00000000403b0dc0
Jul 5 04:07:31 mx3210 kernel: r08-11 0000000000000000 0000000000000002 0000000
040000e88 00000000bfff2d08
Jul 5 04:07:31 mx3210 kernel: r12-15 000000004037e4b4 00000000bfff2c48 00000000403d76a0 0000000000000004
Jul 5 04:07:31 mx3210 kernel: r16-19 00000000bfff2c08 00000000bfff2bc8 00000000bfff2b88 00000000403d76a0
Jul 5 04:07:31 mx3210 kernel: r20-23 00000000bfff2d0f 0000000000000000 0000000040002000 0000000000000001
Jul 5 04:07:31 mx3210 kernel: r24-27 000000000000000c 0000000040001398 00000000400013a8 00000000000365e8
Jul 5 04:07:31 mx3210 kernel: r28-31 0000000000000000 0000000024242424 00000000bfff2e00 00000000403c45c3
Jul 5 04:07:31 mx3210 kernel: sr00-03 000000000000e800 000000000000e800 0000000000000000 000000000000e800
Jul 5 04:07:31 mx3210 kernel: sr04-07 000000000000e800 000000000000e800 000000000000e800 000000000000e800
Jul 5 04:07:31 mx3210 kernel:
Jul 5 04:07:31 mx3210 kernel: VZOUICununcqcqcqcqcqcrmunTDVZOUI
Jul 5 04:07:31 mx3210 kernel: FPSR: 00000000000000000000000000000000
Jul 5 04:07:31 mx3210 kernel: FPER1: 00000000
Jul 5 04:07:31 mx3210 kernel: fr00-03 0000000000000000 0000000000000000 0000000000000000 0000000000000000
Jul 5 04:07:31 mx3210 kernel: fr04-07 fffffffffffff000 0000000000000000 ffffffffffffff9c bff0000000000000
Jul 5 04:07:31 mx3210 kernel: fr08-11 0000000000000000 000000004055d400 0000000000000802 000000004055d400
Jul 5 04:07:31 mx3210 kernel: fr12-15 00000000401a7d6c 0000000000000000 00000000401a5e94 000000007f40c580
Jul 5 04:07:31 mx3210 kernel: fr16-19 000000007f40ab38 000000007f406c78 000000007f430000 000000007f430000
Jul 5 04:07:31 mx3210 kernel: fr20-23 000000004055d400 00000000404f8bcc 000000000000026a 0000003700000000
Jul 5 04:07:31 mx3210 kernel: fr24-27 0000000000000000 000000007f430000 000000004055d400 0000000000000803
Jul 5 04:07:31 mx3210 kernel: fr28-31 ffffffffffffffe9 000000007ec4bc88 000000004055d400 0000000000000803
Jul 5 04:07:31 mx3210 kernel:
Jul 5 04:07:31 mx3210 kernel: IASQ: 000000000000e800 000000000000e800 IAOQ: 00000000403c2b03 00000000403c2b07
Jul 5 04:07:31 mx3210 kernel: IIR: 0f88108c ISR: 000000000000e800 IOR: 0000000000000004
Jul 5 04:07:31 mx3210 kernel: CPU: 0 CR30: 00000002bf8fc000 CR31: 0000000040564000
Jul 5 04:07:31 mx3210 kernel: ORIG_R28: 00000000407a55c8
Jul 5 04:07:31 mx3210 kernel: IAOQ[0]: 00000000403c2b03
Jul 5 04:07:31 mx3210 kernel: IAOQ[1]: 00000000403c2b07
Jul 5 04:07:31 mx3210 kernel: RP(r2): 00000000403c2c23
$ disasm 0x0f88108c
0: 0f 88 10 8c ldw 4(ret0),r12
(gdb) p/x $pc
$1 = 0x403c2b00
(gdb) disass 0x403c2af0 0x403c2b10
Dump of assembler code from 0x403c2af0 to 0x403c2b10:
0x403c2af0 <_dl_map_object_deps+396>: cmpib,= 0,ret0,0x403c32c8 <_dl_map_object_deps+2404>
0x403c2af4 <_dl_map_object_deps+400>: ldi 0,r11
0x403c2af8 <_dl_map_object_deps+404>: ldw 34(r10),ret0
0x403c2afc <_dl_map_object_deps+408>: ldw -30(r3),r21
0x403c2b00 <_dl_map_object_deps+412>: ldw 4(ret0),r12
0x403c2b04 <_dl_map_object_deps+416>: stw r21,18(r3)
0x403c2b08 <_dl_map_object_deps+420>: ldw -34(r3),ret0
0x403c2b0c <_dl_map_object_deps+424>: stw r12,20(r3)
End of assembler dump.
(gdb) p/x $r10
$2 = 0x40000e88
(gdb) p/x *($r10 + 0x34)
$3 = 0x0
(gdb) p/x $r10 + 0x34
$4 = 0x40000ebc
(gdb) x/32x $r10
0x40000e88: 0x4029b000 0x40000e78 0x4029e5fc 0x40001118
0x40000e98: 0x40000bf0 0x40000e88 0x00000000 0x400010dc
0x40000ea8: 0x00000000 0x4029e5fc 0x00000000 0x00000000
0x40000eb8: 0x00000000 0x00000000 0x00000000 0x00000000
0x40000ec8: 0x00000000 0x00000000 0x00000000 0x00000000
0x40000ed8: 0x00000000 0x00000000 0x00000000 0x00000000
0x40000ee8: 0x00000000 0x00000000 0x00000000 0x00000000
0x40000ef8: 0x00000000 0x00000000 0x00000000 0x00000000
(gdb) p **preloads
$7 = {l_addr = 1077391360, l_name = 0x40000bd8 "/lib/libncurses.so.5",
l_ld = 0x403b0d18, l_next = 0x40000e88, l_prev = 0x403d8180,
l_real = 0x40000bf0, l_ns = 0, l_libname = 0x40000e44, l_info = {0x0,
0x403b0d20, 0x403b0d70, 0x403b0d68, 0x403b0d40, 0x403b0d48, 0x403b0d50,
0x403b0d88, 0x403b0d90, 0x403b0d98, 0x403b0d58, 0x403b0d60, 0x403b0d30,
0x403b0d38, 0x403b0d28, 0x0, 0x0, 0x0, 0x0, 0x0, 0x403b0d78, 0x0, 0x0,
0x403b0d80, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x403b0da8,
0x403b0da0, 0x0, 0x0, 0x0, 0x0, 0x403b0db8, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x403b0db0, 0x0 <repeats 26 times>}, l_phdr = 0x4037b034,
l_entry = 1077435232, l_phnum = 4, l_ldnum = 26, l_searchlist = {
r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x40000e40,
r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0,
l_nbuckets = 521, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0,
l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x4037b8e0, l_chain = 0x4037b8e0}, {
l_gnu_chain_zero = 0x4037b0bc, l_buckets = 0x4037b0bc},
l_direct_opencount = 0, l_type = lt_library, l_relocated = 0,
l_init_called = 0, l_global = 0, l_reserved = 1, l_phdr_allocated = 0,
l_soname_added = 0, l_faked = 0, l_need_tls_init = 0, l_used = 0,
l_auditing = 0, l_audit_any_plt = 0, l_removed = 0, l_contiguous = 1,
l_rpath_dirs = {dirs = 0x0, malloced = 0}, l_reloc_result = 0x0,
l_versyms = 0x0, l_origin = 0x40000e60 "/lib", l_map_start = 1077391360,
l_map_end = 1077616976, l_text_end = 1077616640, l_scope_mem = {0x403d89dc,
0x0, 0x0, 0x0}, l_scope_max = 4, l_scope = 0x40000da8, l_local_scope = {
0x40000d4c, 0x0}, l_dev = 536937216, l_ino = 641363, l_runpath_dirs = {
dirs = 0x0, malloced = 0}, l_initfini = 0x40001398, l_reldepsmax = 0,
l_reldeps = 0x0, l_feature_1 = 0, l_flags_1 = 0, l_flags = 0, l_idx = 0,
l_mach = {fptr_table_len = 0, fptr_table = 0x0}, l_lookup_cache = {
sym = 0x0, type_class = 0, value = 0x0, ret = 0x0}, l_tls_initimage = 0x0,
l_tls_initimage_size = 0, l_tls_blocksize = 0, l_tls_align = 0,
l_tls_firstbyte_offset = 0, l_tls_offset = 0, l_tls_modid = 0,
l_relro_addr = 0, l_relro_size = 0, l_serial = 2, l_audit = 0x40000e40}
Register $r10 contains the address of the next link map:
(gdb) p (*preloads)->l_next
$10 = (struct link_map *) 0x40000e88
(gdb) p *(*preloads)->l_next
$11 = {l_addr = 1076473856, l_name = 0x40000e78 "/lib/libdl.so.2",
l_ld = 0x4029e5fc, l_next = 0x40001118, l_prev = 0x40000bf0,
l_real = 0x40000e88, l_ns = 0, l_libname = 0x400010dc, l_info = {0x0,
0x4029e5fc, 0x0 <repeats 74 times>}, l_phdr = 0x4029b034,
l_entry = 1076477148, l_phnum = 7, l_ldnum = 31, l_searchlist = {
r_list = 0x0, r_nlist = 0}, l_symbolic_searchlist = {r_list = 0x400010d8,
r_nlist = 0}, l_loader = 0x403d8880, l_versions = 0x0, l_nversions = 0,
l_nbuckets = 0, l_gnu_bitmask_idxbits = 0, l_gnu_shift = 0,
l_gnu_bitmask = 0x0, {l_gnu_buckets = 0x0, l_chain = 0x0}, {
l_gnu_chain_zero = 0x0, l_buckets = 0x0}, l_direct_opencount = 0,
l_type = lt_library, l_relocated = 0, l_init_called = 0, l_global = 0,
l_reserved = 1, l_phdr_allocated = 0, l_soname_added = 0, l_faked = 0,
l_need_tls_init = 0, l_used = 0, l_auditing = 0, l_audit_any_plt = 0,
l_removed = 0, l_contiguous = 1, l_rpath_dirs = {dirs = 0x0, malloced = 0},
l_reloc_result = 0x0, l_versyms = 0x0, l_origin = 0x400010f8 "/lib",
l_map_start = 1076473856, l_map_end = 1076488476, l_text_end = 1076490240,
l_scope_mem = {0x403d89dc, 0x0, 0x0, 0x0}, l_scope_max = 4,
l_scope = 0x40001040, l_local_scope = {0x40000fe4, 0x0}, l_dev = 536937216,
l_ino = 641559, l_runpath_dirs = {dirs = 0x0, malloced = 0},
l_initfini = 0x0, l_reldepsmax = 0, l_reldeps = 0x0, l_feature_1 = 0,
l_flags_1 = 0, l_flags = 0, l_idx = 0, l_mach = {fptr_table_len = 0,
fptr_table = 0x0}, l_lookup_cache = {sym = 0x0, type_class = 0,
value = 0x0, ret = 0x0}, l_tls_initimage = 0x0, l_tls_initimage_size = 0,
l_tls_blocksize = 0, l_tls_align = 0, l_tls_firstbyte_offset = 0,
l_tls_offset = 0, l_tls_modid = 0, l_relro_addr = 0, l_relro_size = 0,
l_serial = 3, l_audit = 0x400010d8}
(gdb) p &(*preloads)->l_next->l_info
$14 = (Elf32_Dyn *(*)[76]) 0x40000ea8
(gdb) p (*preloads)->l_next->l_info
$15 = {0x0, 0x4029e5fc, 0x0 <repeats 74 times>}
(gdb) p/x 0x40000ea8 + 5 * 4
$17 = 0x40000ebc
So, the segmentation fault was caused by a 0x0 in the l_info field of
the link map for "/lib/libdl.so.2".
elf.h:#define DT_STRTAB 5 /* Address of string table */
This is the code that causes the segv:
const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
$ readelf -a /lib/libdl.so.2
...
Dynamic section at offset 0x25fc contains 27 entries:
Tag Type Name/Value
0x00000001 (NEEDED) Shared library: [libc.so.6]
0x00000001 (NEEDED) Shared library: [ld.so.1]
0x0000000e (SONAME) Library soname: [libdl.so.2]
0x0000000c (INIT) 0xc9c
0x0000000d (FINI) 0x20bc
0x00000019 (INIT_ARRAY) 0x3590
0x0000001b (INIT_ARRAYSZ) 4 (bytes)
0x00000004 (HASH) 0x2168
0x6ffffef5 (GNU_HASH) 0x134
0x00000005 (STRTAB) 0x47c
It would appear there should be a string table.
Carlos, what do you think?
Dave
--
J. David Anglin dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6602)
Reply to: