Openj9: Crash in Compiler Options Processing

[dsouzai]

Running
java -Xjit:aot,verbose={compilePerformance},vlog=vlog -version
Results in a crash. This is due to a bug in the OMR compiler options processing code (it crashes here https://github.com/eclipse/omr/blob/ab3462429e1ef193d6b315c764486ff75da79c64/compiler/ras/OptionsDebug.cpp#L379 because of the NULL here https://github.com/eclipse/omr/blob/ab3462429e1ef193d6b315c764486ff75da79c64/compiler/control/OMROptions.cpp#L117).

While that bug should be fixed, I'm opening an issue here because of a more insidious bug:
Running
java -Xjit:aotMethodCompilesThreshold=2,verbose={compilePerformance},vlog=vlog -version
Results in the same crash. As far as I can tell, because the aotMethodCompilesThreshold= option is defined in J9Options.cpp and the aot is defined in OMROptions.cpp, somehow the options processing code matches aotMethodCompilesThreshold with aot. I don't know if this only results in the incorrect option getting printed in the vlog, or whether the aotMethodCompilesThreshold option never gets applied.

fyi @nbhuiyan

[gacholio]

This might be another case of incorrect strncmp usage, i.e.

strncmp(option, "aot", strlen("aot")) instead of
strncmp(option, "aot", strlen(option))

@charliegracie

[charliegracie]

For option processing we need to remove ALL instances of strncmp as it easily allows for substring matches... ALL option processing (and similar) code needs to be using strcmp. The "safety" of using strncmp is completely removed if you run strlen on one of the strings to provide the length parameter... Also to properly use strcmp for this type of processing you need to check that the lengths are equal before making the call to strcmp... Since you will be doing an unoptimized version of strcmp why not just use strcmp?