Segmentation Fault in yyparse() method

Hi,

I'm a german student (so sorry for my bad english).

I'm working at my bachelor thesis and I'm having a little
problem with
Bison/Flex.

 

I'm using a Bison/Flex application, that was written by
another student for
his bachelor thesis. The application runs without any
trouble, if it is
compiled with gcc version 3.3.6, but with every other gcc
version (e.g.
4.1.2) I tested, it throws a "segmentation fault"
error.

 

I debugged it and it crashes in the bison generated
yyparse() method in the
yybackup section.

 

/* YYCHAR is either YYEMPTY or YYEOF or a valid look-ahead
symbol.  */

if (yychar == YYEMPTY)

{

    YYDPRINTF ((stderr, "Reading a token: "));

    yychar = YYLEX; <---

}

 

In the gcc-3.3.6 compiled version it jumps into the yylex()
method and runs
through without complaints.

 

Because I don't really understand exactly what happens in
this piece of
code, I have no idea what is going wrong. 

 

Does Anybody have a good hint for me?

 

 

More Detailed information in the Attached Readme file.

The File is quite big. The bison generated code is about
39000 lines of
code(The "Segmentation fault is in line 33120)

 

I worked with:

bison 2.3

flex 2.5.33

gcc 4.1.2

 

Jonas Stahl


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

EL MAR, 13-11-2007 A LAS 17:07 +0100, JONAS STAHL ESCRIBIó:
> 
>     YYCHAR = YYLEX; <---

MOST LIKELY A BUG IN YOUR YYLEX () IMPLEMENTATION. YOU
SHOULD DEBUG IT
THERE.

CLAUDIO

-- 
CLAUDIO SAAVEDRA <CSAAVEDRAALUMNOS.UTALCA.CL>



_______________________________________________
HELP-BISONGNU.ORG
HTTP://LISTS.GNU.ORG/MAILMAN/LISTINFO/HELP-BISON

> I'm a german student (so sorry for my bad english).

It doesn't seem that bad to me, but if you have trouble with
anything,
just write in German.  I understand it and I think some
other people here
do, too.

> I'm using a Bison/Flex application, that was written by
another student
> for
> his bachelor thesis. The application runs without any
trouble, if it is
> compiled with gcc version 3.3.6, but with every other
gcc version (e.g.
> 4.1.2) I tested, it throws a "segmentation
fault" error.
>

Well, my guess is that it's trying to reading from an
invalid address.

>
> In the gcc-3.3.6 compiled version it jumps into the
yylex() method and
> runs
> through without complaints.
>

One of those strange mysteries one has with computers.

>
>
> Because I don't really understand exactly what happens
in this piece of
> code, I have no idea what is going wrong.
>
>
>
> Does Anybody have a good hint for me?
>

Run your application under the control of a debugger, such
as GDB, and do
a backtrace when the program crashes.  Then put a breakpoint
before the
error and run the program again.  Examine the values of
variables and the
contents of pointers around where the error occurs.

> More Detailed information in the Attached Readme file.

>
> The File is quite big. The bison generated code is
about 39000 lines of
> code(The "Segmentation fault is in line 33120)

Please try the above suggestions first (unless someone comes
up with a
better answer in the meantime).  I never look at other
peoples' code
except under duress.

Laurence Finston




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

Jonas Stahl wrote:
> Hi,
> 
> I'm a german student (so sorry for my bad english).
> 
> I'm working at my bachelor thesis and I'm having a
little problem with
> Bison/Flex.
> [snip]
> Does Anybody have a good hint for me?

Well, is the use of bison/flex required? My initial reaction
when I saw
the code was "Why the hell is he writing a parser for a
very specific
XML file format with bison/flex?". Unless the use of
bison/flex is
required, I would strongly recommend using libxml2 to parse
the XML
(heck, given that the idea is to transform LaTeX XML to text
suitable
for screen readers, I think it's likely that an XSL
transform is the
best way to go).

As others have suggested, it's likely that the error is in
your flex
code, not in the grammar. Of course, since you also seem to
use lots of
fixed-length char arrays it's certainly possible the crash
is the result
of some buffer overflow that would be hard to debug.

> More Detailed information in the Attached Readme file.
> 
> The File is quite big. The bison generated code is
about 39000 lines of
> code(The "Segmentation fault is in line 33120)

Never send generated files unless specifically asked to;
it's
unnecessary since it can be assumed that those people on
this list who
are inclined to help you will have bison and flex. Also
avoid the use of
compression tools other than zip, gzip and bzip2, to ensure
maximal
portability across platforms.



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

Ok, first thanks for the replies. I already debugged it with
gdb before
writing to the mailing list. Cause I'm not very used to
debugging C Code it
didn't help me very much. 

The result of debugging in short:

The debugger jumps from main() to yyparse() and the error
occurs at the
first time the code gets to this code passage (after about
10 steps in
yyparse). 


In the running version without "segmentation
fault", which was compiled with
gcc 3.3.6

33117     if (yychar == YYEMPTY)
(gdb) 
33120         yychar = YYLEX;
(gdb) 

Breakpoint 1, yylex () at lex.yy.c:4500
4500            if ( !(yy_init) )

As you see the debugger gets to the breakpoint at the first
line of yylex().
The few variables around, yychar, YYEMPTY and yy_init have
the same value in
both versions.


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".

Jonas Stahl



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

> Well, is the use of bison/flex required? My initial
reaction when I saw
> the code was "Why the hell is he writing a parser
for a very specific
> XML file format with bison/flex?". Unless the use
of bison/flex is
> required, I would strongly recommend using libxml2 to
parse the XML
> (heck, given that the idea is to transform LaTeX XML to
text suitable
> for screen readers, I think it's likely that an XSL
transform is the
> best way to go).

The application wasn't written by me. It's a bachelor thesis
of a former
student. I think his first attempt was to work on the LateX
file without
converting to xml. But it turned out to be easier to
transfer to MathML
first. And maybe the time was too short to skip to another
tool(or he just
didn't find it ^^)


> Never send generated files unless specifically asked
to; it's
> unnecessary since it can be assumed that those people
on this list who
> are inclined to help you will have bison and flex. Also
avoid the use of
> compression tools other than zip, gzip and bzip2, to
ensure maximal
> portability across platforms.

Ok, just wanted to save some of your time, because
generating it, takes much
more time than downloading it 




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

> 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-bisongnu.org http
://lists.gnu.org/mailman/listinfo/help-bison