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

[Nikita Schmidt <cetus@snowball.ucd.ie>]

On Monday,  9 Nov, Paul Slootman wrote:
> 
> If you get a message like so:
> 
>     identd(15285): unaligned trap at 0000000120024a9c: 000000011ffffa34 2d 10
> 

Note: the operation is stq (opcode 2d) and the address is dword-aligned
(most probably an int variable).

> 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>.
> 

Looks very much like the case with netstat, where numbers were scanfed
with %ld into an int variable.

> 
> 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).

Looks pretty much OK.  Are you sure that's the line that causes the
trouble?  Usually I just run the program under gdb, having set a
breakpoint at the address reported by the kernel, and then print stack
trace.  That way unaligned traps can often be hunt down very quickly.

> 
> 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?)

I don't know for sure, but possibly changing the code size may shift
that int variable onto a quadword boundary, hiding the bug...

Nikita