Recent changes to bugs

Missing copyright statements

2011-02-08T11:22:23Z

Hey

At least the Java part lacks copyright statements (this may also extend to the C/CPP code, but I did not check). At least the Java src zip file contains an license, but I cannot find one for the src cpp zip file (I only checked the source zips of version 2.0.20).

The consequences of this is:

The Java zip file violates its own license (EPL 1.0 section 3):
"""
Each Contributor must identify itself as the originator of its Contribution,
if any, in a manner that reasonably allows subsequent Recipients to identify
the originator of the Contribution.
"""

The CPP zip is probably not redistributable, since lack of license implies "All
rights reserved". Assuming the CPP zip is under EPL 1.0 (or intended to be
under said license), then it (also) violates section 3.:

"""
When the Program is made available in source code form:

a) it must be made available under this Agreement; and

b) a copy of this Agreement must be included with each copy of the Program.
"""

Though again, that is only if the CPP part is under EPL 1.0.

Thank you in advance,
~Niels

PS: I originally filed this as https://sourceforge.net/tracker/index.php?func=detail&aid=3175629&group_id=155963&atid=797881, but I am refiling it here because that was the wrong tracker and I could not move it.

LexParser.parseActions (2.0.20) bug

2010-12-21T21:23:09Z

line 648 - current_kind = tokStream.getKind(curtok)
should be moved up and inserted after
line 646 - curtok = tokStream.getNext(curtok);

otherwise in incremented parse mode current_kind is not always updated

Memory leak in generated parsers

2009-06-28T18:52:38Z

Reusing a parser instance (DeterministicParser or BacktrackingParser) results in a memory leak caused by the method lpg.runtime.Stacks.reallocateStacks(). This method is called before parsing a new file and it will copy the current stacks into new arrays of length "stack_length = old_stack_length + STACK_INCREMENT;". Because of this the stacks will continue to grow when reusing a parser.

A potential fix for this bug is adding the following lines to the reset method in the DeterministicParser/BacktrackingParser:
locationStack = null;
parseStack= null;
stateStack= null;

Memory Leak in spell.h

2008-02-04T14:22:59Z

At line 46 the method returns without deleting the allocated memory for strings s1 and s2 at line 14 and 15.

http://lpg.cvs.sourceforge.net/lpg/lpg.generator.cpp/src/spell.h?revision=1.1&view=markup

BacktrackingParser constructor is very slow

2007-06-07T15:33:40Z

The BacktrackingParser constructor method allocates a huge int array (1 << 20) for recording actions. Unfortunately allocating this array is dirt slow (it may even be causing the garbage collector to fire).

When using LPG to parse a large project in CDT I have noticed huge performance gains by pooling and reusing BacktrackingParser objects rater than instantiating one for every file. However, now I have to write and maintain an object pool for parsers, this shouldn't be necessary.

I tracked down this bottleneck using TPTP.

Mike Kucera
Software Developer
IBM CDT Team

BacktrackingParser: Parsing an empty stream leads Exception

2006-07-20T10:30:49Z

java.lang.ArrayIndexOutOfBoundsException: 0
at lpg.lpgjavaruntime.IntTuple.add(IntTuple.java:75)
at
lpg.lpgjavaruntime.BacktrackingParser.parse(BacktrackingParser.java:129)

adding one to the size of the newly created array would
smoothly fix this issue

System.arraycopy(array, 0, array = new int[i * 2 + 1],
0, i);
----