Debugging
When Proparse gives us a line and a token, it is pretty easy to figure out what construct is bothering it. We can then set that code aside or edit it to eliminate the problem and put the problematic token in your queue for eventual enhancement.
The problem we are having is that we are running into a significant number of cases in the UK code base where we get a ProRefactorException
or a java.lang.NullPointerException and no line number and no token. I
am keeping my own track of line number in the TreeWalker and all of these report at line 0, so I'm thinking that these errors are occurring during the initial parse prior to the point where I am walking the tree.
Sometimes I get a call stack, but that isn't really telling me much.
I.e., the prior observation that
org.prorefactor.treeparser.Variable.assignAttributesLike(Variable.java:44)
might indicate an issue with LIKE and the program in question having LIKE in an input parameter definition for an internal procedure seems to be a false clue since a test run I did with that construct parsed just fine.
Is there anything you can think that we can do that would help narrow down the error so that we could fix it or at least put it on an enhancement list?
It is particularly problematic since, thus far, they are not even able to get all the way through the code based before the whole thing hangs.
And, of course, then we *really* don't know where we are.
- Login to post comments
Re: Debugging
That probably indicates some preprocessor generated code is causing the parser to choke. I don't think there's any easy way to track it down other than to work with the Proparse code in the IDE. It's easiest to see what's going on from the debugger. Antlr also has a 'traceparser' flag, which has to be enabled at Proparse build time. It generates reams of output when the parser is run but it can sometimes be helpful.
There's a setJustLex(true) method on DoParse, which changes it so it just dumps a listing of all the lexical tokens to stdout (it doesn't attempt to parse anything). I doubt it would help, but it's possible you could spot something obviously wrong in the lexical token list.
James has been trying to run
James has been trying to run in the PDSOE debugger in case that will provide more hints, but so far all it seems to have done is to slow everything down. If we could just get a line number with the message, we could probably identify the problem.
Do you think it would help to replace a file with the PREPROCESSed version?
Having not been successful yet at building, the traceparser flag isn't going to help much.
I am thinking of trying to run the program through tokenlister to see if it blows up there too.
Sample CallStack at
Sample CallStack
at org.prorefactor.treeparser.Variable.assignAttributesLike(Variable.java:44)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TP01Support.defLike(TP01Support.java:325)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.defineparam_var(TreeParser01.java:17995)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.defineparameterstate(TreeParser01.java:17722)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.statement(TreeParser01.java:33361)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.blockorstate(TreeParser01.java:256)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.code_block(TreeParser01.java:11036)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.procedurestate(TreeParser01.java:26528)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.statement(TreeParser01.java:32952)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.blockorstate(TreeParser01.java:256)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser01.TreeParser01.program(TreeParser01.java:102)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser.TreeParserWrapper.run2(TreeParserWrapper.java:36)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser.ParseUnit.treeParser(ParseUnit.java:213)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at org.prorefactor.treeparser.ParseUnit.treeParser01(ParseUnit.java:228)
[15/05/14@17:22:59.949+0100] P-005276 T-002328 1 4GL APPL at cli.Progress.ClrBridge.ClrApi.Inv
That first reference is here:
public void assignAttributesLike(Primative likePrim) {
dataType = likePrim.getDataType();
className = likePrim.getClassName();
extent = likePrim.getExtent();
}
on the dataType = line, so it *might* have something to do with a datatype.
Re: Sample CallStack at
That's telling. It's a DEFINE PARAMETER LIKE statement inside a PROCEDURE block.
But, I made a sample
But, I made a sample program
define variable c as character no-undo.
procedure something:
define input parameter ipc like DiskFile.chID.
end.
{ test.i }
and tokenlister handled it just fine, so, despite my suspicions based on LIKE in a method parameter, that seemed not to be a problem in any absolute sense. And, yes, I was testing more than one thing in this run.