sigsegv in bison 32bit / works in 64bit.

[gary artim-2]

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 }


_______________________________________________
help-bison@... http://lists.gnu.org/mailman/listinfo/help-bison

[gary artim-2]

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 <cheetomonster@...> 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 <gartim@...> 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      }
>>
>> _______________________________________________
>> help-bison@... http://lists.gnu.org/mailman/listinfo/help-bison
>
>

_______________________________________________
help-bison@... http://lists.gnu.org/mailman/listinfo/help-bison