#220 Bus error / Segmentation Fault

closed-fixed
None
5
2013-05-25
2001-11-11
No

The following program excerpt generates a "bus error" or "Segmentation fault" depending on which platform it is run on. It fails with the most current version of SDCC in CVS and also version 2.2.1:

// Illustrates a "bus error" / "Segmentation fault"
typedef struct _BC_ {
char HEAD;
char TAIL;
char DATA[1];
} BC;

void bufferPut(BC *b) {
b->HEAD != b->TAIL;
b->DATA[b->HEAD] = 1;
}

I ran GDB on the core dump, and although I have SDCC compiled with debugging enabled (-ggdb), I didn't get much meaningful stuff in the backtrace:

#0 0x70005174 in strcmp ()
#1 0x0004437c in ?? ()
#2 0x000484a4 in ?? ()
#3 0x00048a80 in ?? ()
#4 0x00057780 in ?? ()
#5 0x00042510 in ?? ()
#6 0x0000f6e8 in ?? ()
#7 0x000184a4 in ?? ()
#8 0x00002d84 in ?? ()
#9 0x00009340 in ?? ()
#10 0x00001c4c in ?? ()
#11 0x00001a7c in ?? ()

Alex Karahalios

Discussion

  • Johan Knol

    Johan Knol - 2001-11-13

    Logged In: YES
    user_id=63512

    probably already fixed

     
  • Johan Knol

    Johan Knol - 2001-11-13
    • milestone: --> 100456
    • priority: 5 --> 2
    • status: open --> open-works-for-me
     
  • Alex Karahalios

    Alex Karahalios - 2001-11-15

    Logged In: YES
    user_id=361551

    This error is back again with the CVS version of SDCC

     
  • Alex Karahalios

    Alex Karahalios - 2001-11-16

    Logged In: YES
    user_id=361551

    I forgot to attach the GDB backtrace. Here it is:

    #0 0x70005174 in strcmp ()
    #1 0x00044da0 in aopPut (aop=0x2becb0, s=0xc5e70 "r4", offset=2878648) at gen.c:1063
    #2 0x00048ee8 in adjustArithmeticResult (ic=0x2b6750) at gen.c:2961
    #3 0x000494c4 in genPlus (ic=0x2b6750) at gen.c:3082
    #4 0x000581d8 in gen51Code (lic=0x2b4850) at gen.c:8889
    #5 0x00042f28 in mcs51_assignRegisters (ebbs=0x2b7e30, count=2) at ralloc.c:2561
    #6 0x0000fdd0 in eBBlockFromiCode (ic=0x0) at SDCCopt.c:895
    #7 0x00018b8c in createFunction (name=0x2b1560, body=0x2b3bc0) at SDCCast.c:4188
    #8 0x0000343c in yyparse () at SDCC.y:168
    #9 0x00009a18 in main (argc=990944, argv=0xbffffab0, envp=0xbffffac0) at SDCCmain.c:1534
    #10 0x00002320 in _start ()
    #11 0x00002150 in start ()

     
  • Alex Karahalios

    Alex Karahalios - 2001-11-16

    Logged In: YES
    user_id=361551

    OK, I have stepped this through with GDB and can see why it crashes (but I don't know enough about the code generator to fix it):

    gen.c:1063: if (strcmp (aop->aopu.aop_str[offset], s))
    offset = 2
    aop->aopu.aop_str[] = "a", "b", NULL, NULL
    s = "r4"

    Notice that the array is being over-indexed and NULL is being passed as a pointer to strcmp.

    Placing tests around the offending line and not executing the code causes other similar problems to crop up in other spots. At this point I have no idea how to fix this, so hopefully someone familiar with gen.c will look at it.

     
  • Johan Knol

    Johan Knol - 2001-11-17

    Logged In: YES
    user_id=63512

    Fixed in ralloc.c:packRegsForAccUse() (most ports).

    As could be seen in .dumprassgn, iTemp10 (b->DATA) had no
    registers assigned. That's because the size of the array is
    1 and was only used once in the next icode, so
    packRegsForAccUse() decided that it could be left in acc.
    This decision was made before the (useless) "b->HEAD !=
    b->TAIL;" was optimized out.
    In general this should not be done for aggregates, because
    they are really pointers (in this case generic thus 3
    bytes).

    Wonder why packRegsForAccUse only want 1 byte operands.

    Johan

     
  • Johan Knol

    Johan Knol - 2001-11-17
    • assigned_to: nobody --> johanknol
    • milestone: 100456 --> fixed
    • priority: 2 --> 5
    • status: open-works-for-me --> closed-fixed
     

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

Sign up for the SourceForge newsletter:





No, thanks