Re: sigsegv in bison 32bit / works in 64bit.

[gary artim]

ok, I can do that, but it seem to be in the interplay of what is
parsed and my code. for example
my rules are:


list:           /* nothing */
        | list '\n'
        | list asgn '\n'        { code2(pop, STOP); return 1; }
        | list expr '\n'        { code2(print, STOP); return 1; }
        | list error '\n'       { yyerrok; }
        ;
asgn:     VAR '=' expr          { code3(varpush, (Inst)$1, assign); }
        ;
expr:     NUMBER                { code2(constpush, (Inst)$1); }
        | VAR                   { code3(varpush, (Inst)$1, eval); }
        | asgn
        | BLTIN '(' expr ')'    { code2(bltin, (Inst)$1->u.ptr); }
        | '(' expr ')'
        | expr '+' expr         { code(add);   }
        | expr '-' expr         { code(sub);   }
        | expr '*' expr         { code(mul);   }
        | expr '/' expr         { code(divv);   }
        | expr '^' expr         { code(power); }
        | '-' expr %prec UNARYMINUS     { code(negate); }
        ;

the input of:

a=1

segfault on the pop. so my code, pushvar, (Inst)$1, assign will run and it's
at runtime that it happens. Being new to creating a stack based machine,
maybe I'm missing the boat?

if i run the code and eliminate the execute() function it doesn't seg.
         for (initcode(); yyparse(); initcode()) {
                printf("before execute\n");
                displaysym();
                displayprog();
                /* execute(prog); */
        }

it gets quite confusing.

-- g.

On Wed, Nov 4, 2009 at 4:44 PM, Chris verBurg <address@hidden> wrote:
>
> The first thing I think you should check is to comment out all your code so
> that you have just the grammar.  Run that with your known input to see if it
> still crashes.  If it does, then we know it's a parser problem; if not, it's
> probably something with your code.
>
> setjmp/longjmp scare me..
>
> -Chris
>
>
> On Wed, Nov 4, 2009 at 4:01 PM, gary artim <address@hidden> wrote:
>>
>> Hi --
>>
>> I'm new to the list and bison. I'm running bison (linked from yacc) on
>> Fedora. I've been trying to figure out why my code segfaults on 32 bit
>> machines. I've tried this on linux versions of gentoo, fedora and in
>> both cases the code segs on the 32 bit machine and runs on the 64 bit.
>> I realize that it could be an alignment issue. I've instrumented my
>> code to see the runtime stack and they look the same. I'm hoping
>> someone has stumbled across this before? I was following the Pike book
>> " the Unix Programming Environment". My code is generated from tux.y
>> (attached) and some gdb output is listed below. Any help in how to
>> debug this would be great. I think what is happening is that the tux.y
>> uses a STOP instruction to signal an end to running. the STOP is
>> defined: #define STOP (Inst) 0. And line 30 of pop has a stack pointer
>> set to this which causes a read of memory loc 0 (a no no), but why
>> would this behave different on 64bit machines? Any help would be great
>> and appreciated much!
>>
>>
>> thanks,
>>
>> -- Gary
>>
>> This GDB was configured as "i586-redhat-linux-gnu".
>> For bug reporting instructions, please see:
>> <http://www.gnu.org/software/gdb/bugs/>...
>> (gdb) r
>> Starting program: /home/gartim/4_64/tux4
>> a=1
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x005eee43 in memmove () from /lib/libc.so.6
>> Missing separate debuginfos, use: debuginfo-install glibc-2.10.1-5.i686
>> (gdb) bt
>> #0  0x005eee43 in memmove () from /lib/libc.so.6
>> #1  0x08049482 in pop () at code.c:30
>> #2  0x080494f5 in execute (p=0x804c3a0) at code.c:51
>> #3  0x08048a20 in main (argc=1, argv=0xbffff5b4) at tux.y:67
>> (gdb) list code.c:30
>> 25      {
>> 26              if (stackp <= stack)
>> 27                      execerror("stack underflow", (char *) 0);
>> 28              *stackp--;
>> 29              //printf("[[%x]]\n", *stackp);
>> 30              return *stackp;
>> 31      }
>>
>> _______________________________________________
>> address@hidden http://lists.gnu.org/mailman/listinfo/help-bison
>
>