HI
@Hans. thanks for the info.
since my process is a deamon, I need to clean up memory leak.
What does error recovery really mean? My current grammar rules does not
include error, so does it mean that I do not have error recovery?
My confusion is: it seems the %destructor is called even for the normal
parse!!
see below:
I comment out the delete $$ in the %destructor
%destructor { std::cout << " **** I am PROG " << $$ ;
//delete $$;
std::cout << " delete done" << std::endl;
} PROG
...
here is my simple test with the following input:
a=="b"
the output is ( enabled trace) following, please pay attention to those
**** lines:
./TestFilter -p -s ./MyTest.sample2
Starting parse
Entering state 0
Reading a token: --(end of buffer or a NUL)
--accepting rule at line 101("a")
Next token is token _SYMB_JSON_KEY (1.1: a)
Shifting token _SYMB_JSON_KEY (1.1: a)
Entering state 3
Reading a token: --accepting rule at line 71("==")
Next token is token _SYMB_EQ (1.2-3: )
Reducing stack by rule 21 (line 284):
$1 = token _SYMB_JSON_KEY (1.1: a)
-> $$ = nterm JSON_FIELD (1.1: 0x24291f0)
Stack now 0
Entering state 11
Next token is token _SYMB_EQ (1.2-3: )
Shifting token _SYMB_EQ (1.2-3: )
Entering state 22
Reading a token: --accepting rule at line 106(""")
--accepting rule at line 115("b")
--accepting rule at line 108(""")
Next token is token _STRING_ (1.4-6: b)
Shifting token _STRING_ (1.4-6: b)
Entering state 36
Reducing stack by rule 23 (line 287):
$1 = token _STRING_ (1.4-6: b)
-> $$ = nterm QUERY_CONDITION (1.4-6: 0x2429270)
Stack now 22 11 0
Entering state 39
Reducing stack by rule 11 (line 265):
$1 = nterm JSON_FIELD (1.1: 0x24291f0)
$2 = token _SYMB_EQ (1.2-3: )
$3 = nterm QUERY_CONDITION (1.4-6: 0x2429270)
-> $$ = nterm Exp3 (1.1-6: 0x2429290)
**** I am QUERY_CONDITION 0x2429270 delete done
**** I am JSON_FIELD 0x24291f0 delete done
Stack now 0
Entering state 10
Reducing stack by rule 10 (line 263):
$1 = nterm Exp3 (1.1-6: 0x2429290)
-> $$ = nterm Exp2 (1.1-6: 0x2429290)
**** I am Exp3 0x24291f0 delete done
Stack now 0
Entering state 9
Reducing stack by rule 8 (line 260):
$1 = nterm Exp2 (1.1-6: 0x2429290)
-> $$ = nterm Exp1 (1.1-6: 0x2429290)
**** I am Exp2 0x24291f0 delete done
Stack now 0
Entering state 8
Reading a token: --accepting rule at line 124(" ")
--accepting rule at line 123("
")
--accepting rule at line 123("
")
--(end of buffer or a NUL)
--accepting rule at line 123("
")
--(end of buffer or a NUL)
--EOF (start condition 0)
Next token is token "end of file" (4.1: )
Reducing stack by rule 6 (line 257):
$1 = nterm Exp1 (1.1-6: 0x2429290)
-> $$ = nterm Exp (1.1-6: 0x2429290)
**** I am Exp1 0x24291f0 delete done
Stack now 0
Entering state 7
Next token is token "end of file" (4.1: )
Reducing stack by rule 2 (line 248):
$1 = nterm Exp (1.1-6: 0x2429290)
-> $$ = nterm ListExp (1.1-6: 0x24292b0)
**** I am Exp 0x2429290 delete done
Stack now 0
Entering state 6
Reducing stack by rule 1 (line 241):
$1 = nterm ListExp (1.1-6: 0x24292b0)
-> $$ = nterm PROG (1.1-6: 0x2429300)
**** I am ListExp 0x24292b0 delete done
Stack now 0
Entering state 5
Next token is token "end of file" (4.1: )
Shifting token "end of file" (4.1: )
Entering state 18
Cleanup: popping token "end of file" (4.1: )
Cleanup: popping nterm PROG (1.1-6: 0x2429300)
**** I am PROG 0x2429300 delete done
OK
Parse Succesful!
------------------------------------
out of the parser....
[Abstract Syntax]
(Json_Filter [(Eeq [(Ejson_field "a")] [(Equery_cond_s "b")])])
[Linearized Tree]
a == "b"
As you can see, even with successful parsing, it try to run that
%destructor, why?
I saw the destructor was generated at: filter_parser.hh
filter_parser::basic_symbol<Base>::clear () {
...
basic_symbol<Base>& yysym = *this;
(void) yysym;
switch (yytype)
{
case 25: // PROG
#line 159 "filter_parser.yy" // lalr1.cc:377
{ std::cout << " **** I am PROG " << yysym.value.template as< PROG*
> () ;
//delete $$;
std::cout << " delete done" << std::endl;
}
#line 1138 "filter_parser.hh" // lalr1.cc:377
}
in the bison generated filter_parser.cpp:
filter_parser::parse () {
....
YY_SYMBOL_PRINT ("-> $$ =", yylhs);
yypop_ (yylen);
yylen = 0;
YY_STACK_PRINT ();
}
It seems yypop_ (yylen) will call basic_symbol<Base>::clear () thus call
%destructor code no matter if it is the error recovery mode or not?
thanks
min
On Thu, Aug 18, 2016 at 4:59 AM, Hans Åberg <haber...@telia.com> wrote:
>
> > On 18 Aug 2016, at 01:20, Min Wang <mingew...@gmail.com> wrote:
>
> > so if I have something like that ( pointer) in as token type:
> >
> > %type <PROG*> PROG
> >
> > %type <ListExp*> ListExp
> >
> > My thinking about using PROG* instead of PROG is because I do not want to
> > copy constructor a big PROG, is it correct?
> >
> > In this case of pointer, do I need to have a %destructor?
> >
> > %destructor { delete $$; } PROG
> > %destructor { delete $$; } ListExp
>
> Yes, if your pointers have explicit allocators in the actions, then if you
> want to avoid memory leaks during error recovery, the corresponding
> deallocator should be called as you indicate.
>
> > (2) when %destructor is called?
> >
> > Assuming I need those %destructor, it seems that %destructor was called
> > even for a every successful parse. I thought it should only called
> during
> > During error recovery.
>
> It is called only during error recovery. For a normal parse, without
> errors, the corresponding deallocator should be in the actions. So you need
> to keep track in the grammar of where an object becomes obsolete.
>
> So if your program is not doing much of error recovery, some memory leaks
> during that process might be acceptable.
>
>
>
--
http://www.comrite.com
Yellow pages, Ads and Search
http://www.meidongnet.com
News, Ads, Free Online dating, Games for Chinese Community in NY, NJ, PA
_______________________________________________
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
