> The result of debugging in short: > In the version with segmentation fault (gcc 4.1.2): > > 33117 if (yychar == YYEMPTY) > (gdb) > 33120 yychar = YYLEX; > (gdb) > > Program received signal SIGSEGV, Segmentation fault. > yyparse () at fullParser.tab.c:33120 > 33120 yychar = YYLEX; > > > I don't get why it doesn't get to the breakpoint. Are there any > instructions, that are performed, that the debugger doesn't show? > > Debugging just lex.yy.c runs through without a "segmentation fault".
I'm not entirely certain, but isn't `YYLEX' a macro? If it is, the debugger isn't going to help you very much. This is one of the main reasons Stroustrup is so against the use of macros, and for what it's worth, I think he's right. You're going to have to find out what the definition of `YYLEX' is. I doubt very much that it's a bug in Flex or lex. However, it's not really a question for this list. I use Flex by itself occasionally, but I tend to write `yylex' by hand when using Bison. I suspect that `YYLEX' is trying to read from an invalid area of memory, and my prime suspect is an uninitialized pointer or one that's been deleted, but not set to 0. Maybe even one that has been set to 0, if `YYLEX' doesn't catch this error, which wouldn't surprise me. Laurence _______________________________________________ help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison