fscanf() trap (Found: How to track down unaligned traps)

[Paul Slootman <paul@wau.mis.ah.nl>]

On Tue 03 Nov 1998, Paul Slootman wrote:

> There's some way of tracking down where an unaligned trap happens with
> gdb (using the address the kernel reports to find the source location),
> but I can't find how to do it.  I was sure I had saved a message where
> this was explained, but now I can't find it :-(

OK, FYI:

If you get a message like so:

    identd(15285): unaligned trap at 0000000120024a9c: 000000011ffffa34 2d 10

you fire up gdb on identd (which must be linked with -g, and with
libc6.1-dbg) and type:

    info line *0x0000000120024a9c

which tells you:

Line 888 of "vfscanf.c" starts at address 0x120024a40 <_IO_vfscanf+10400>
   and ends at 0x120024aa4 <_IO_vfscanf+10500>.


It seems to be caused by the following line 193 in parse.c from identd:

    rcode = fscanf(fp, " %d , %d", &lport, &fport);

but I can't see why this should be a problem... lport and fport are both
int, and their addresses end in 0xc and 0x0 (so should be aligned
properly).

If I split the command up like so:

    rcode  = fscanf(fp, " %d , ", &lport);
    rcode += fscanf(fp, " %d", &fport);

then I don't get the trap...  Looks like a problem in the library
(optimizer bug?)


Paul Slootman
-- 
home: paul@wurtel.demon.nl | work: paul@murphy.nl | debian: paul@debian.org
http://www.wurtel.demon.nl | Murphy Software,   Enschede,   the Netherlands