#2626 SDAS Segmentation fault when using .macro a lot (sdasstm8)

[Thomas]

The problem

In a SDCC / STM8 assembly project, I want to replace a recurrent assembly pattern with a macro. However, when I use a specific macro more often than 145 times I get a segmentation fault.

I use two similar macros. Removing one instance of one kind doesn't appear to allow adding more macro instances of the other kind.

SDCC Version

The problem happens in the SDCC Version 3.6.0, and also in the recent development version 3.6.6 #9921. Both show the following sdasstm8 version information:

sdas Assembler V02.00 + NoICE + SDCC mods  (STMicroelectronics STM8)

How to reproduce

• Load and expand https://github.com/TG9541/stm8ef/archive/v2.2.12.zip, expand the attached file "forth.zip" into the target folder (e.g. "stm8ef-2.2.12/")
• run "make BOARD=MAXDEV" in the target folder

~/stm8ef-2.2.12$ make BOARD=MAXDEV
mkdir -p out/MAXDEV
sdasstm8 -I. -I./MAXDEV -plosgffw out/MAXDEV/forth.rel forth.asm
sdcc -mstm8 -oout/MAXDEV/MAXDEV.ihx main.c out/MAXDEV/forth.rel

• replace forth.asm with the file forth.segf.asm in the attached archive -> crash

~/stm8ef-2.2.12$ cp forth.segf.asm forth.asm 
~/stm8ef-2.2.12$ make BOARD=MAXDEV
mkdir -p out/MAXDEV
sdasstm8 -I. -I./MAXDEV -plosgffw out/MAXDEV/forth.rel forth.asm
make: *** [forth.rel] Segmentation fault (core dumped)

• using one instance of the macro "HEADER" less doesn't lead to a crash

~/stm8ef-2.2.12$ cp forth.ok.asm forth.asm 
~/stm8ef-2.2.12$ make BOARD=MAXDEV
mkdir -p out/MAXDEV
sdasstm8 -I. -I./MAXDEV -plosgffw out/MAXDEV/forth.rel forth.asm
sdcc -mstm8 -oout/MAXDEV/MAXDEV.ihx main.c out/MAXDEV/forth.rel

What I can contribute to the solution

• run more tests
• run gdb sessions (with some assistance from someone with more gdb experience)

[Thomas]

Please run "make BOARD=MINDEV" instead of the make target described in the bug report.

[Thomas]

gdb shows the following:

Starting program: /home/thomas/source/stm8s/stm8ef/sdasstm8 -I. -I./CORE -plosgffw out/CORE/forth.rel forth.asm

Program received signal SIGSEGV, Segmentation fault.
fgetm (ptr=0x61d950 "", len=1023, fp=0x0) at ../asxxsrc/asmcro.c:998
998         if (nfp->lstptr == NULL) {

[Thomas]

asxxsrc/asmcro.c uses FILE *fp for representing macro instances. On my machine the number of file handles is limited to 1024 but increasing the limit for open files to 2048 doesn't change anything (ulimit -Sn returns 2048).

Edit: according to comments in the listing, macro processing behaves as if there were file handles to include files. It doesn't appear to depend on OS files, though.

Edit: the problem is related to macros containing "," (comma).

[Thomas]

The problem has nothing to do with how often .macro is used: macro parameters don't hande string values consistently.

Given the following macro:

        .macro  stringtest string
        .ascii  string
        .endm

The second macro call below, with a string containing ",", will lead to a segmentation fault:

        .ascii     "no,problem"
        stringtest "OK"
        stringtest "seg,fault"

However, there is a general problem with string delimeters in macros. The following macro call leads to Error: <q> missing or improper operators, terminators, or delimiters

        .ascii     "no;problem"
        stringtest "delimiter;error"

I guess it's better to close this issue, and open a new one.

[Thomas]

Should one of the SDCC/SDAS maintainers read this, here is a band-aid which will make SDAS point the user to the offending line instead of crashing:

Index: sdas/asxxsrc/asmcro.c
===================================================================
--- sdas/asxxsrc/asmcro.c   (revision 9930)
+++ sdas/asxxsrc/asmcro.c   (working copy)
@@ -992,6 +992,10 @@
         }
         ip = ptr;


+        if (fp == NULL) {
+                fprintf(stderr, "?ASxxxx-Internal-fgetm(fp)-Error srcline %d.\n\n", srcline);
+                asexit(ER_FATAL);
+        }
         nfp = (struct macrofp *) fp;
         np = nfp->np;
}

[Thomas]

Ken Yap found out that using octal escapes instead of "delimiting chars" (e..g ",") doesn't lead to a crash.

See https://github.com/TG9541/stm8ef/issues/259 for more information and the applied workaround.

By the way, the patch above would really help some SDCC users to find macros that won't work because of a bug deep in the macro feature. A crash with "Segmentation fault (core dumped)¨ without any line number information is not nice.

[Philipp Klaus Krause]

The patch has been applied in [r11332].

[Tobias Diedrich]

FWIW asmlnk.txt also documents that there is another way to escape these besides using octal escapes:

stringtest  ^"should work"

But this escape method doesn't work in the current version AFAICS: https://sourceforge.net/p/sdcc/bugs/3150/