-
Bug
-
Resolution: Incomplete
-
P4
-
None
-
8
-
generic
-
generic
ADDITIONAL SYSTEM INFORMATION :
Java 8 (any version)
MacOS, CentOS7
(looks platform independent)
A DESCRIPTION OF THE PROBLEM :
The application is a larger parser/lexer, to parse tens of MB; this is stored in quite big data structures that are processed in the final stages of parsing/lexing. Runtime is up to minutes on an i9 macbook; same issue on CentOS7/8.
Some parts of the code are not executed unless some methods produce (unnecessary for parsing) GUI output or output via e.g. System.out.print(ln). The code itself is OK: I can disable/enable GUI or System.* output and that enables/disables skipping executing code. My guess would be that the interpreter erroneously guesses that the (skipped) code is not useful and therefore can be skipped.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
It ONLY happens for large (correctly compiled) code, seemingly randomly in just A FEW methods (deeply nested) that produce no direct output on GUI or stdout, nor on a socket, but produce/change data in an internal data structure (to be retrieved later). Hard to debug as the code is correct, it only is not executed; it gets executed if debug output is generated.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
as described earlier:
producing some output leads to executing the code
ACTUAL -
see above
---------- BEGIN SOURCE ----------
I cannot dump a sensible small testcase, see above.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
let some methods generate otherwise useless GUI/stdout output
latter is the easiest as it can be caught on Linux/MacOS in “null”
FREQUENCY : always
Java 8 (any version)
MacOS, CentOS7
(looks platform independent)
A DESCRIPTION OF THE PROBLEM :
The application is a larger parser/lexer, to parse tens of MB; this is stored in quite big data structures that are processed in the final stages of parsing/lexing. Runtime is up to minutes on an i9 macbook; same issue on CentOS7/8.
Some parts of the code are not executed unless some methods produce (unnecessary for parsing) GUI output or output via e.g. System.out.print(ln). The code itself is OK: I can disable/enable GUI or System.* output and that enables/disables skipping executing code. My guess would be that the interpreter erroneously guesses that the (skipped) code is not useful and therefore can be skipped.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
It ONLY happens for large (correctly compiled) code, seemingly randomly in just A FEW methods (deeply nested) that produce no direct output on GUI or stdout, nor on a socket, but produce/change data in an internal data structure (to be retrieved later). Hard to debug as the code is correct, it only is not executed; it gets executed if debug output is generated.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
as described earlier:
producing some output leads to executing the code
ACTUAL -
see above
---------- BEGIN SOURCE ----------
I cannot dump a sensible small testcase, see above.
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
let some methods generate otherwise useless GUI/stdout output
latter is the easiest as it can be caught on Linux/MacOS in “null”
FREQUENCY : always