Re: [Nasm-devel] Nasm crash / from elfout.c line ~ 1414

[Frank K. <fbk...@co...>]

Patrick MARIE wrote:

>   Hello,
> 
>   Recently, a FreeBSD (-current) port (transcode), became broken, due to
> to a nasm (lastest version) crash.
>   Here is the PR's url:
>     http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/60054
> 
>   Backtrace:
> 
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x280d0119 in strlen () from /lib/libc.so.5
> (gdb) bt
> #0  0x280d0119 in strlen () from /lib/libc.so.5
> #1  0xbfbfe8c4 in ?? ()
> #2  0x0805fe7a in elf_write () at output/outelf.c:1028
> #3  0x0805dc2b in elf_cleanup (debuginfo=1) at output/outelf.c:253
> #4  0x08049371 in main (argc=6, argv=0xbfbfe8c4) at nasm.c:284
> #5  0x08048d62 in _start ()
> 
> 
>   I quicky have a look to the code, and i've "located" the crash, in
> elfout.c, line 1414:
> 
>   /* this is the first stab, its strx points to the filename of the
>      the source-file, the n_desc field should be set to the number
>      of remaining stabs
>   */
>   WRITE_STAB(sptr, fileidx[0], 0, 0, 0, strlen(allfiles[0]+12));
> 
>   Having a look with printf on "allfiles[0]+12" let me think that this
> memory zone is allocated, but his content may not be initialised
> (depending of the numfiles value, and certainly many other things).
>  
>   So, why this '+12' ? May be this is a typo and it is
> 'strlen(allfiles[0])+12' ?

Hi Patrick,

Thanks for the report! I downloaded "transcode", and "swap.s" assembles 
fine for me with the command line "nasm -f elf swap.s" in both dos (box 
under win98) and Linux. Thinking you might have Nasm 0.98.37, which is 
known to be buggy, I tried that... and it still assembled. *Big* 
difference in the size of "swap.o" - the multiple SLINE records per line 
that 0.98.37 was doing, I think. I haven't got FreeBSD installed, so 
can't try it there.

I agree that line 1414 looks pretty suspicious. I have no idea what 
we're "supposed" to be doing there. Does your proposed change fix the 
problem in FreeBSD? Seems to make no difference at all, here(!) (only 
tried it in dos, so far...) Does dumping the "-g" switch allow it to 
assemble? (I'd expect so)

Later,
Frank