Re: [Bug report / Bison 1.875] %destructor directive causing segfault during compilation

[Jeannot_Langlois]

Hi guys,



I've attempted a trace of this segfaulting "%destructor" directive problem
(which I've described in detail at the bottom of this email).  

Here's a backtrace of "bison -t -d -l --report=all ircparser.y" (obtained
using DDD 3.3.1 and GDB 5.3 on BISON 1.875 latest-release version AFAIK)
showing the location of the offending code:


________________________________________________________________
__libc_startmain()                libc.so.6
main()                            main.c:157
output()                          output.c:646
output_skeleton()                 output.c:576
symbol_printers_output()          output.c:444
escaped_file_name_output()        output.c:127
quotearg_style()                  quotearg.c:614
quotearg_n_style()                quotearg.c:600
quotearg_n_options()              quotearg.c:560
quotearg_buffer()                 quotearg.c:503
quotearg_buffer_restyled()        quotearg.c:481
________________________________________________________________



So, according to this, it seems to me that something is wrong in file "lib/quotearg.c"
within this function:


________________________________________________________________
static size_t quotearg_buffer_restyled (char *buffer, 
                                        size_t buffersize, 
                                        char const *arg, 
                                        size_t argsize, 
                                        enum quoting_style quoting_style,
                                        struct quoting_options const *o)
________________________________________________________________


According to GDB, calling context of "quotearg_buffer_restyled" is:  

________________________________________________________________
buffer=0x8072740 "\"/home/johndoe/projects/jbtparser.bison/ircparser.y\"",
buffersize=256, 
arg=0x0, 
argsize=4294967295, 
quoting_style=c_quoting_style, 
o=0xbffff7b0
________________________________________________________________


The segfault occurs around these lines, located at the end of the function
:

________________________________________________________________
(...)

  if (len < buffersize)
    buffer[len] = '\0';
  return len;

(...)
________________________________________________________________



According to DDD, "return len;" triggers a segfault...  or maybe it is "buffer[len]
= '\0';" ???

I have yet to figure out the precise context which causes this segfault,
but at least, this trace is a good starting point (IMHO).


I hope this report might be useful to any of you.  If I find anything more,
I'll repost.  Don't hesitate to contact me for any questions pertaining to
this.


Thanks folks! :-)




Jeannot_Langlois wrote:

Hi guys,


I am currently working on an IRC language grammar parser which makes extensive use of dynamically-allocated memory (through standard malloc() calls) in semantic actions.  The custom value types I use are "char" and "char*" (as you'll see below).  I need to dynamically allocate memory in semantic actions for strings (char* types) so I can copy/concatenate/form them using sprintf() after memory allocation.  Then, later, higher-level rules can obtain the dynamically-allocated strings (from lower-level rules) and then insert complete, syntaxically-correct strings in an AST.

Here's a typical example of what I'd like to accomplish in the lower-level rules's semantic actions (O_PREFIX and R_PREFIX are char* [types], while T_COLON and T_SPACE are char [tokens]):

--------------------------------------------------------------------------------------------------------------------
O_PREFIX:
    T_COLON R_PREFIX T_SPACE            {
                                            $$ = malloc(1 + strlen(R_PREFIX) + 1);
                                            sprintf($$, "%c%s%c", $1, $2, $3);
                                        }
;   
--------------------------------------------------------------------------------------------------------------------

This code should not cause any problems at all, but....  I don't want any memory leaks !  

So, when discarded, the dynamically-allocated string's memory is lost and wasted --  I want it to be properly freed.  I discovered the "%destructor" directive in the Bison 1.875 "info" pages, which should precisely do that, but, as I've just noticed, this directive is still really experimental (at least with Bison 1.875 I am using from what I can see), so here's a bug report of a problem I've encountered while attempting to generate C code from my ircparser.y file using "%destructor".  I hope this might be useful to you guys.


Here's relevant sections of my ircparser.y file :

---- [ircparser.y extract] ----
/* BISON DECLARATIONS */

%token-table        /* token table */
%pure-parser        /* reentrant parser */
%defines            /* output extra item calculus debug file */
%glr-parser         /* generalized LR algorithm */

%union  /* data types */
{
    char chr;        /* character */
    char* str;       /* string */
    int val;         /* integer (??NOT USED -- DELETE ME??) */
}

...

/*
 * TOKENS (terminal symbols)
 */
%token <chr> T_NUL
%token <chr> T_LF
%token <chr> T_CR
%token <chr> T_COLON
... and I have many others like these...

...

/*
 * RULES (non-terminal symbols)
 */
%type <str> R_MESSAGE
%type <str> O_PREFIX
%type <str> R_PREFIX
... and I have many others like these too...

...

/* DESTRUCTORS */
%destructor { free ($$); } R_MESSAGE
%destructor { free ($$); } O_PREFIX
%destructor { free ($$); } R_PREFIX
... then I have other lines like these for every %type line I have defined.
-------------------------------

Here's the output I get when I attempt to generate a C parser from my ircparser.y file :


address@hidden:~$ bison -t -d -l --report=all ircparser.y
ircparser.y: conflicts: 7 shift/reduce, 7 reduce/reduce
Segmentation fault
NONE:0: /usr/bin/m4: ERROR: EOF in string
address@hidden:~$



I notied that the problems just needs the presence of a single %destructor line to trigger a segfault.  As soon as I comment all my %destructor lines, the problem vanishes and the C code is produced normally without segfaults... but then, if executed, the parser will have memory leaks... that's not ok :(.


Any ideas or patches to fix this problem?

I never really looked at Bison source code (at least yet);  would you guys have any ideas about where I should start to look (ex: particular bison source file) to attempt a trace of this segfault ?

Feel free to write back to me at "jeannot12 AT linuxmail DOT org" for any questions or information requests concerning this problem, I'd be glad to help.

Just in case:  I am using Bison 1.875 and gcc 3.2.2.

Thanks,

--
Jeannot Langlois
B. Sc.  Computer Science / B. Sc.  Informatique
Software Developer / Programmeur-Analyste
System/Network Administrator / Administrateur Système/Réseau
jeannot12 AT linuxmail DOT org