Error with grammar arguments
Hello,
I have a (large) grammar where I have code similar to that below:
| identifier ':' array_spec_init {
log_debug( "%p", $identifier );
log_debug( "%p", $array_spec_init );
}
When this grammar is run, the following is shown in the output:
Stack now 0 1 3 15 83
Entering state 194
Reducing stack by rule 154 (line 2062):
$1 = token identifier (1.6-25: )
$2 = token ':' (1.27: )
$3 = nterm array_spec_init (1.29-56: )
debug: *0x255b930*
debug: *0x255b930*
Note that the same pointer address is returned for $identifier and
$array_spec_init.
Before asking anyone to look at my grammar, I thought I would ask as to
whether anyone has seen an error such as this before?
Thanks in advance.
Rob
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Error with grammar arguments
Yes - That is correct Chris. I am allocating memory within Flex for tokens.
This issue first manifest itself when I started to add code for the proper
freeing on this memory (where no longer required) within grammar actions.
On Wed, 19 Dec. 2018, 04:40 Chris verBurg Rob,
>
> To ask a sanity question, you do strdup (or otherwise allocate fresh
> memory for) yytext on the Flex side when returning tokens, yes?
>
> -Chris
>
>
> On Tue, Dec 18, 2018 at 9:15 AM Rob Casey wrote:
>
>> Hello,
>>
>> I have a (large) grammar where I have code similar to that below:
>>
>> | identifier ':' array_spec_init {
>> log_debug( "%p", $identifier );
>> log_debug( "%p", $array_spec_init );
>> }
>>
>> When this grammar is run, the following is shown in the output:
>>
>> Stack now 0 1 3 15 83
>> Entering state 194
>> Reducing stack by rule 154 (line 2062):
>>$1 = token identifier (1.6-25: )
>>$2 = token ':' (1.27: )
>>$3 = nterm array_spec_init (1.29-56: )
>> debug: *0x255b930*
>> debug: *0x255b930*
>>
>> Note that the same pointer address is returned for $identifier and
>> $array_spec_init.
>>
>> Before asking anyone to look at my grammar, I thought I would ask as to
>> whether anyone has seen an error such as this before?
>>
>> Thanks in advance.
>>
>> Rob
>> ___
>> help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
>>
>
___
help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Error with grammar arguments
Thanks for the tip Chris, Hans. I have a straight-forward unit test where this issue is manifesting, so I will explore this with respect to lexer token allocation. On Wed, Dec 19, 2018 at 8:21 AM Hans Åberg wrote: > > > On 18 Dec 2018, at 20:06, Rob Casey wrote: > > > > Yes - That is correct Chris. I am allocating memory within Flex for > tokens. > > This issue first manifest itself when I started to add code for the > proper > > freeing on this memory (where no longer required) within grammar actions. > > It looks like a lexer issue, same pointer passed to the Bison parser. You > might write out the strings to see whether it is overwritten or not written > the second time. > > > On Wed, 19 Dec. 2018, 04:40 Chris verBurg wrote: > > > >> Rob, > >> > >> To ask a sanity question, you do strdup (or otherwise allocate fresh > >> memory for) yytext on the Flex side when returning tokens, yes? > >> > >> -Chris > > > ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
Re: Error with grammar arguments
Thanks again for the assistance Chris and Hans. I found a path through my grammar where $$ was not explicitly set within a rule action which would explain identifier and array_spec_init having the same pointer value. On Wed, Dec 19, 2018 at 8:42 AM Rob Casey wrote: > Thanks for the tip Chris, Hans. I have a straight-forward unit test where > this issue is manifesting, so I will explore this with respect to lexer > token allocation. > > > On Wed, Dec 19, 2018 at 8:21 AM Hans Åberg wrote: > >> >> > On 18 Dec 2018, at 20:06, Rob Casey wrote: >> > >> > Yes - That is correct Chris. I am allocating memory within Flex for >> tokens. >> > This issue first manifest itself when I started to add code for the >> proper >> > freeing on this memory (where no longer required) within grammar >> actions. >> >> It looks like a lexer issue, same pointer passed to the Bison parser. You >> might write out the strings to see whether it is overwritten or not written >> the second time. >> >> > On Wed, 19 Dec. 2018, 04:40 Chris verBurg > wrote: >> > >> >> Rob, >> >> >> >> To ask a sanity question, you do strdup (or otherwise allocate fresh >> >> memory for) yytext on the Flex side when returning tokens, yes? >> >> >> >> -Chris >> >> >> ___ help-bison@gnu.org https://lists.gnu.org/mailman/listinfo/help-bison
