|
From: | Jeannot_Langlois |
Subject: | Re: [Bug report / Bison 1.875] %destructor directive causing segfault during compilation |
Date: | Wed, 18 Feb 2004 19:24:29 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 |
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,
[Prev in Thread] | Current Thread | [Next in Thread] |