[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Segmentation fault using lalr1.cc

From: Tim Van Holder
Subject: Re: Segmentation fault using lalr1.cc
Date: 23 Jan 2003 09:51:59 +0100

On Thu, 2003-01-23 at 08:49, Paul Eggert wrote:
> Thanks for the bug report.  Does this patch fix things for you?

It fixes the segfault I reported, but runs into another one, which
I couldn't debug properly, but seemed to be triggered inside
After rebuilding bison with -gstabs+3 debugging worked better and
showed this:

Program received signal SIGSEGV, Segmentation fault.
0x0806e05e in quotearg_buffer_restyled (buffer=0x807f6a0 "\"lalr1.cc\"",
buffersize=256, arg=0x0, argsize=4294967295,
    quoting_style=c_quoting_style, o=0xbffff2f0) at quotearg.c:256
256       for (i = 0;  ! (argsize == SIZE_MAX ? arg[i] == '\0' : i ==
argsize);  i++)

which results from a call of quotearg_style(<style>, spec_defines_file)
(again in scan-skel.l).

75      "@output_header_name@"  QPUTS (spec_defines_file);

This is because lalr1.cc also has '#include @output_header_name@'.
With that wrapped in an m4_if as well, bison no longer crashes.
Of course it would be nicer if bison's code was changed to handle this
better; otherwise hand-written skeletons would become a lot harder to
debug. I don't see why bison couldn't/shouldn't warn "Skeleton uses
@output_header_name@ which is only available if the -d option is given"
(or something similar).

BTW, 'bison -S lalr1.cc foo.y' still produces a .c file; this seems a
bit odd.

Tim Van Holder <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]