#532 Strange behaviour with %define
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
Thanks for report! 2.10rc series is under review so for stable projects use 2.09.xx series (just for info).
hmm, have you tried 2.09.06?
ok, bug on double free confirmed with 2.09.06. i'll check, thanks again!
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 ?
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?
> 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.)
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!
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.