Ticket #205 (closed defect: fixed)

Opened 2 weeks ago

Last modified 12 days ago

Order of destruction of global objects in IDL parser library causes access violation at termination

Reported by: jasper Owned by: jasper
Priority: major Milestone: Phase III WP1
Component: IDL parser Version: 1.2.0.14
Keywords: Cc:

Description

Lists of objects to clean up are kept in case the parser fails. These lists may go out of scope at program exit before the parser's type library is deleted, causing the destructors to access no longer existing variables.

Change History

comment:1 Changed 12 days ago by jasper

Commit [246f9d36cc63eddbb1176e63867ecceac98da472] removes the globals for IDL parser cleanup that cause this problem, and added a unit test for invalid IDL parsing. It is at this point validated that parsing of a correct IDL does not cause a memory leak.

The added test however demonstrates that IDL parsing of an incorrect IDL does introduce a memory leak (valgrind was used to test the new ParserTest_Invalid_IDL test).

The memory leak is described here:

https://github.com/AaronNGray/byacc/blob/master/README.BTYACC

The parser type cannot easily be modified to clean itself up when using BYACC, as the parser stack is allocated using malloc() and released with free() neither of which would invoke the constructor or destructor associated with the parser token. In addition, a struct as a parser token would increase memory use by the parser significantly as compared to the current %union construct, and the parser.y file would become more complex as the <> fields and %type constructs are handled only for the %union case.

Bison and BTYACC introduce a %destructor construct that would clean up unused parser tokens. However Bison skeleton code is based on the GNU license family which should be avoided in the context of COBIA, and BTYACC introduces unnecessary back-tracking which increases the cost of parsing.

BYACC as installed on most linux systems (the default compilation) alas does not support the %destructor construct.

A separate solution is required to address the memory leak.

comment:2 Changed 12 days ago by jasper

  • Status changed from new to closed
  • Resolution set to fixed

A separate object tracker is implemented that keeps track of unused objects. All object created by the parser implement a ParserObject? interface with a virtual destructor. Objects are added to the tracker as they are created and removed from the tracker as they are consumed. Created unconsumed objects are deallocated by the tracker. Fix implemented in commit [0fc4f3638375bf02dea1aec3365feb71c9e21479]

Note: See TracTickets for help on using tickets.