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

portmap segfault and gdb unusable

On Thu, May 31, 2007 at 02:46:51AM +0200, Thibaut VARENE wrote:
> On 5/30/07, Sébastien Bernard <seb@frankengul.org> wrote:
> >        I'm joining the oops text.
> It's not an Oops. It's "regular" userland fault.

Ok, I'm not really familiar with the parisc land. I've (wrongly) assumed that since
in the dmesg output, it should be related to the kernel (as it is on x86 and sparc).

It is not.

> [snip]
> >EXT3 FS on sda7, internal journal
> >EXT3-fs: mounted filesystem with ordered data mode.
> >eth0: CSR0 00a09000
> ^^^ this is a bit surprising. It's apparently the tulip driver puking
> something. Might be totally unrelated tho.
It maybe related to the hardware (two inboard ethernet interface + 1 quad board).

> >do_page_fault() pid=2163 command='portmap' type=15 address=0x823d3578
> >vm_start = 0x411ea000, vm_end = 0x411eb000
> Type 15 is dtlb fault (such as loading from NULL pointer...)
> >IASQ: 00002027 00002027 IAOQ: 411e6af3 411e6af7
> > IIR: 483a3dc9    ISR: 00002027  IOR: 823d3578
> > CPU:        0   CR30: aec90000 CR31: 10410000
> > ORIG_R28: 4039ebd8
> > IAOQ[0]: 0x411e6af0
> > IAOQ[1]: 0x411e6af4
> > RP(r2): 0x411e6ad4
> It's a library at fault here (0x4... addresses). Find which one goofed
> (ldd `which portmap`, find which library is linked to this address
> space) and disassemble it to find what happened, if you really care ;)

I do care (:p).
seb@hpnux:~/dev/portmap-6.0$ ldd /sbin/portmap
        libwrap.so.0 => /lib/libwrap.so.0 (0x40018000)
        libc.so.6 => /lib/libc.so.6 (0x4070e000)
        libnsl.so.1 => /lib/libnsl.so.1 (0x402f5000)
        /lib/ld.so.1 (0x400c2000)

So it seems to lie in the libc.so.6 (which happens to be libc6-2.5-9 in unstable).
It happens with kernel 2.6.18-4-parisc64 too. Maybe a userland problem.

More disturbing is the fact I can't debug the problem.

seb@hpnux:~/dev/portmap-6.0$ gdb ./portmap
rGNU gdb 6.6-debian
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "hppa-linux-gnu"...
Using host libthread_db library "/lib/libthread_db.so.1".
(gdb) r
Starting program: /home/seb/dev/portmap-6.0/portmap

Program received signal SIGSEGV, Segmentation fault.
0x4117fb8c in ?? ()
(gdb) bt
#0  0x4117fb8c in ?? ()
#1  0x4117fb70 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) b main
Breakpoint 1 at 0x1d0c: file portmap.c, line 178.
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /home/seb/dev/portmap-6.0/portmap
Cannot insert breakpoint 1.
Error accessing memory address 0x1d0c: Input/output error.

Why is this happening ?

> See http://wiki.parisc-linux.org/RegistersDump and
> http://www.fr.parisc-linux.org/faq/kernelbug-howto.html for more info.
> >NET: Registered protocol family 10
> >lo: Disabled Privacy Extensions
> >eth0: Setting full-duplex based on MII#1 link partner capability of 45e1.
> >hald-probe-stor(2898): unaligned access to 0xfb525d26 at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525d2a at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525d36 at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525d3a at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525f26 at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525f2a at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525f36 at ip=0x00014013
> >hald-probe-stor(2898): unaligned access to 0xfb525f3a at ip=0x00014013
> These are harmless.
> Aside the strange CSR0 printout I pointed out, I see nothing strange
> with this console dump. It doesn't tell anything about a kernel crash
> or whatever. Nothing in this dump should prevent proper functioning of
> the system...

Ok, that is quite comforting.
> T-Bone
> -- 
> Thibaut VARENE
> http://www.parisc-linux.org/~varenet/

Reply to: