I'm trying to implement some error recovery in Bison. My lexer allocates memory with new and passes it back to Bison via a semantic value. During error recovery, Bison discards tokens until it can resynchronize (essentially leaking the memory allocated by the lexer).
The Bison 1.875 docs (section 3.7.5) mention the %destructor directive which is suppossed to tell Bison to generate code to handle these discarded tokens. When running the latest GnuWin32 version of Bison on a file with a %destructor directive, I get a hard crash with the message: "NONE:0 m4: ERROR: EOF in string" and then M$ asks me if I want to send an error report. Can anyone suggest anything here?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am getting the same crash ("NONE:0 m4: ERROR: EOF in string"). Is there a patch for this problem? Could I try a new version of Bison, and how can I keep the Gnuwin32 changes for Windows? Or is there aomething else wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
No knowledge about Bison, but to regularely get updates from gnuwin32, I use some batch files I have written for that purpose. You can download them at
Since you guys are no help, I thought I'd try to answer my own question ...
This source of memory leaks is a well known problem when using Flex/Bison. There are several posting about this issue on the Flex/Bison mailing list, but no really good solutions. It seems that the %destructor is currently a hack that is not really ready for production code. Based on these issues, it's much easier to write your own memory allocation functions, and track all of the memory allocated to flex/bison. Periodically, or once you have finished a parse, you can explicitly free and memory that was leaked. (Still kind of a hack, but it least it will work!) Enjoy ...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
D:/GnuWin32/bin/../share/bison/yacc.c:683: m4: ERROR: Copying inserted file
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm trying to implement some error recovery in Bison. My lexer allocates memory with new and passes it back to Bison via a semantic value. During error recovery, Bison discards tokens until it can resynchronize (essentially leaking the memory allocated by the lexer).
The Bison 1.875 docs (section 3.7.5) mention the %destructor directive which is suppossed to tell Bison to generate code to handle these discarded tokens. When running the latest GnuWin32 version of Bison on a file with a %destructor directive, I get a hard crash with the message: "NONE:0 m4: ERROR: EOF in string" and then M$ asks me if I want to send an error report. Can anyone suggest anything here?
I am getting the same crash ("NONE:0 m4: ERROR: EOF in string"). Is there a patch for this problem? Could I try a new version of Bison, and how can I keep the Gnuwin32 changes for Windows? Or is there aomething else wrong?
No knowledge about Bison, but to regularely get updates from gnuwin32, I use some batch files I have written for that purpose. You can download them at
http://members.tcnet.ch/michaelis/gnuwin32/GetGnuWin32.zip
Best regards
Mathias
Since you guys are no help, I thought I'd try to answer my own question ...
This source of memory leaks is a well known problem when using Flex/Bison. There are several posting about this issue on the Flex/Bison mailing list, but no really good solutions. It seems that the %destructor is currently a hack that is not really ready for production code. Based on these issues, it's much easier to write your own memory allocation functions, and track all of the memory allocated to flex/bison. Periodically, or once you have finished a parse, you can explicitly free and memory that was leaked. (Still kind of a hack, but it least it will work!) Enjoy ...
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
D:/GnuWin32/bin/../share/bison/yacc.c:683: m4: ERROR: Copying inserted file