#2122 SIGSEGV with some strange pointer casting

closed-fixed
Front-end
5
2014-08-14
2013-01-03
No

$ /build/sdcc/8330/bin/sdcc -mz80 -v
SDCC : z80 3.2.1 #8330 (Jan 3 2013) (Solaris i386)
$ cat test.c
#include <stdio.h>

typedef struct newtype {
char a;
int b;
void * c;
} newtype_t;

#define OFF(type, member) ((int)((((type *)NULL)->member)))

int VAR1 = OFF(newtype_t, c);
void * VAR2 = OFF(newtype_t, c);

$ /build/sdcc/8330/bin/sdcc -mz80 -c test.c
test.c:11: error 2: Initializer element is not constant
Caught signal 11: SIGSEGV

Yes, the code is wrong (transcription errors on my part) and a bit strange (needing the struct offsets in a non-Z80 environment for debugging a memory image in Unix), but it shouldn't produce a SEGV. The assignment to VAR1 correctly produces a warning, but the assignment to VAR2 generates the SEGV. The only difference between the two lines is the type of the target variable. Substituting '0' for 'NULL' produces the sane result.

I didn't get a core dump (SEGV appears to be caught and "gracefully" ignored), but the stack trace at the point of SEGV is:

$ truss -lf -t\!all -SSEGV /build/sdcc/8330/bin/sdcc -mz80 -c test.c
test.c:11: error 2: Initializer element is not constant
15582/1: Incurred fault #6, FLTBOUNDS %pc = 0x08241D66
15582/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000040
15582/1: Received signal #11, SIGSEGV [caught]
15582/1: siginfo: SIGSEGV SEGV_MAPERR addr=0x00000040
$ pstack 15582
15582: /build/sdcc/8330/bin/sdcc -mz80 -c test.c
08241d66 valForStructElem (0, 849cba8, feffe648, 820d3d2, 1, 9d3) + 2d6
0826bfca initValPointer (849cc08, 849c1b8, feffe698, 8220256, 849cc08, fe622000) + 17a
0826c7a7 initPointer (848cd48, 849bf70, 8367bb9, 1, 8368f77, 12e) + c7
0826f304 printIvalPtr (849bfe0, 849bf70, 848cd48, feffe724, 1, e8) + 44
08271391 emitRegularMap (1000, 0, 0, 0, 0, 0) + b11
08272297 emitMaps (feffe7b8, 1000, 0, 0, 0, 0) + 47
082728c1 glue (8410540, 0, 0, 8274f20, 1, 840fe58) + 71
082051a5 main (4, feffe8a4, feffe8b8, feffe898, 81fa002, 831ebb0) + af5
081fa063 _start (4, feffe9ec, feffea14, feffea1a, feffea1d, 0) + 83

SDCC was built from source. I don't build the other ports as I'm not interested in them, so I can't say for certain whether this is a Z80-specific issue or not. My feeling is that it is a generic C front end issue, as valForStructElem() appears in SDCCval.c.

Discussion

  • Philipp Klaus Krause

    • Category: --> Front-end
     
  • Maarten Brock

    Maarten Brock - 2013-12-22

    Fixed in SDCC 3.3.2 #8924.

     
  • Maarten Brock

    Maarten Brock - 2013-12-22
    • status: open --> closed-fixed
    • assigned_to: Maarten Brock
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks