#532 Strange behaviour with %define

closed-fixed
nobody
5
2011-03-07
2011-03-05
Anonymous
No

I tried compiling a code like this (nasm 2.09.04):

%define IFNDEF %ifndef
%define ENDIF %endif

IFNDEF foo
;bar
ENDIF

but I get an error:

$ nasm test.mac
test.mac:4: error: label or instruction expected at start of line
test.mac:6: error: label or instruction expected at start of line

when I invoke nasm -e it prints:

$ nasm -e test.mac
%line 3+1 test.mac

%ifndef foo

%endif

what is basicaly what I want and what in this form compiles ok. Driven by curiosity I tried invoking nasm -a on my source file and with that it crashed:

$ nasm -a test.mac
test.mac:1: error: label or instruction expected at start of line
test.mac:2: error: label or instruction expected at start of line
test.mac:4: error: parser: instruction expected
*** glibc detected *** nasm: double free or corruption (!prev): 0x081147b8 ***
======= Backtrace: =========
/lib/libc.so.6(+0x6b861)[0xb7663861]
/lib/libc.so.6(+0x6d0c8)[0xb76650c8]
/lib/libc.so.6(cfree+0x6d)[0xb76681ad]
/lib/libc.so.6(fclose+0x152)[0xb76538c2]
nasm[0x804b175]
nasm[0x804c6f7]
/lib/libc.so.6(__libc_start_main+0xe6)[0xb760ebb6]
nasm[0x8049131]
======= Memory map: ========
08048000-080cf000 r-xp 00000000 08:17 29454250 /usr/bin/nasm
080cf000-080d0000 r--p 00086000 08:17 29454250 /usr/bin/nasm
080d0000-080d1000 rw-p 00087000 08:17 29454250 /usr/bin/nasm
080d1000-08120000 rw-p 00000000 00:00 0 [heap]
b7400000-b7421000 rw-p 00000000 00:00 0
b7421000-b7500000 ---p 00000000 00:00 0
b759a000-b75b4000 r-xp 00000000 08:17 20983347 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1
b75b4000-b75b5000 r--p 00019000 08:17 20983347 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1
b75b5000-b75b6000 rw-p 0001a000 08:17 20983347 /usr/lib/gcc/i686-pc-linux-gnu/4.4.3/libgcc_s.so.1
b75b6000-b75f8000 rw-p 00000000 00:00 0
b75f8000-b7738000 r-xp 00000000 08:15 866952 /lib/libc-2.11.2.so
b7738000-b773a000 r--p 0013f000 08:15 866952 /lib/libc-2.11.2.so
b773a000-b773b000 rw-p 00141000 08:15 866952 /lib/libc-2.11.2.so
b773b000-b773e000 rw-p 00000000 00:00 0
b7767000-b7768000 rw-p 00000000 00:00 0
b7768000-b7769000 r-xp 00000000 00:00 0 [vdso]
b7769000-b7785000 r-xp 00000000 08:15 867489 /lib/ld-2.11.2.so
b7785000-b7786000 r--p 0001b000 08:15 867489 /lib/ld-2.11.2.so
b7786000-b7787000 rw-p 0001c000 08:15 867489 /lib/ld-2.11.2.so
bf8cb000-bf8ed000 rw-p 00000000 00:00 0 [stack]
Przerwane

Discussion

  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-05

    Thanks for report! 2.10rc series is under review so for stable projects use 2.09.xx series (just for info).

     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-05

    hmm, have you tried 2.09.06?

     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-05

    ok, bug on double free confirmed with 2.09.06. i'll check, thanks again!

     
  • Wojciech Migda

    Wojciech Migda - 2011-03-05

    I have not tried 2.09.06 bc it is not in gentoo's portage tree. I can see you've reproduced double free on 2.09.06, but what do you think about the nasm's problem with the shown preprocessor directives construction ? Is it a bug or a design ?

     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-05

    for me looks like a bug but to be sure I need to find some spare time for review, I'll try to resolve this in a couple of days, ok?

     
  • nasm64developer

    nasm64developer - 2011-03-06

    > what do you think about the nasm's problem with
    > the shown preprocessor directives construction ?
    > Is it a bug or a design ?

    It's by design.

    The preprocessor attempts to handle preprocessor
    directives before it expands single-line macros, let
    alone multi-line macros. See pp_getline() towards
    the end of the function.

    (This actually becomes visible in your -e example,
    where %ifndef and %endif still show in the output.)

     
  • Nobody/Anonymous

    ok, as nasm64developer the preproc issue is a feature so wontfix it for a while.
    meanwhile the double free (which is actually simply fclose called on same
    file pointer several times) is fixed and will be in 2.09.07 release.

    Thanks a lot for reporting this problem!

     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-07

    This item has been resolved; the fix has been checked into git (http://repo.or.cz/w/nasm.git) and will be in the next release.
    You can usually also obtain a nightly snapshot at http://www.nasm.us/; the snapshot robot usually runs some time between 07:00 and 09:00 UTC, but sometimes runs immediately if there was no previous snapshot for today.

     
  • Cyrill Gorcunov

    Cyrill Gorcunov - 2011-03-07
    • status: open --> closed-fixed
     

Log in to post a comment.