[DISCOVERY JS-CPG] Not blocking exception while loading CPG

[compaluca]

• While running the checkdiscoveryrules on pattern JS 1, an error is produced
• The reason is that while loading the generated CPG (stored in ./out/test.bin) an exception is raised by Joern.
• However, this exception does not seem to be blocking for Joern, at least in this case.
• By running the joern query the pattern obstacle can be found.
• Our framework, on the other hand, is raising an error everything Joern raises an exception
  • @pr0me should we change this and being more relaxed wrt these exceptions?
  • below you have the example run in Joern console vs the example run with framework commands
  • the framework would stop everytime the Joern output comprises the string Error in CPG generation (see OUT2)

OUT1: Example in Joern console

joern> importCpg("./out/test.bin")
Creating project `test.bin` for CPG at `./out/test.bin`
Creating working copy of CPG to be safe
Loading base CPG from: /tp-framework/workspace/test.bin/cpg.bin.tmp
Adding default overlays to base CPG
The graph has been modified. You may want to use the `save` command to persist changes to disk.  All changes will also be saved collectively on exit
The graph has been modified. You may want to use the `save` command to persist changes to disk.  All changes will also be saved collectively on exit

java.lang.NoSuchMethodError: 'scala.Option io.joern.jssrc2cpg.JsSrc2Cpg$.postProcessingPasses$default$2()'
  io.joern.console.cpgcreation.JsSrcCpgGenerator.applyPostProcessingPasses(JsSrcCpgGenerator.scala:24)
  io.joern.console.Console.applyPostProcessingPasses(Console.scala:394)
  io.joern.console.Console.$anonfun$importCpg$6(Console.scala:365)
  scala.Option.foreach(Option.scala:437)
  io.joern.console.Console.importCpg(Console.scala:363)
  ammonite.$sess.cmd0$.<clinit>(cmd0.sc:1)

joern> cpg.call("<operator>.fieldAccess").where(n => n.code(".*splice.*")).location.toJson
res1: String = "[{\"node\":{\"name\":\"<operator>.fieldAccess\",\"signature\":\"\",\"code\":\"array.splice\",\"typeFullName\":\"ANY\",\"columnNumber\":8,\"order\":0,\"methodFullName\":\"<operator>.fieldAccess\",\"_label\":\"CALL\",\"argumentIndex\":-1,\"dynamicTypeHintFullName\":[],\"dispatchType\":\"STATIC_DISPATCH\",\"lineNumber\":30,\"id\":132},\"symbol\":\"array.splice\",\"packageName\":\"\",\"nodeLabel\":\"CALL\",\"methodShortName\":\"handleServer\",\"methodFullName\":\"pattern_src_code.js::program:handleServer\",\"lineNumber\":30,\"filename\":\"pattern_src_code.js\",\"classShortName\":\"\",\"className\":\"\"}]"
joern> 

OUT2: Example as framework command output

# joern --script tp_framework/core/cpgTest.sc --params name="./out/test.bin"
joern --script tp_framework/core/cpgTest.sc --params name="./out/test.bin"
executing /tp-framework/tp_framework/core/cpgTest.sc with params=Map(name -> ./out/test.bin)
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in [jar:file:/opt/joern/joern-cli/lib/joernext-querydb-io.joern.ghidra-10.2.3_PUBLIC_20230208.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in [jar:file:/opt/joern/joern-cli/lib/org.apache.logging.log4j.log4j-slf4j-impl-2.19.0.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.helpers.NOPLoggerFactory]
Compiling (synthetic)/ammonite/predef/CodePredef.sc
Compiling /tp-framework/tp_framework/core/cpgTest.sc
Creating project `test.bin1` for CPG at `./out/test.bin`
Creating working copy of CPG to be safe
Loading base CPG from: /tp-framework/workspace/test.bin1/cpg.bin.tmp
Adding default overlays to base CPG
The graph has been modified. You may want to use the `save` command to persist changes to disk.  All changes will also be saved collectively on exit
The graph has been modified. You may want to use the `save` command to persist changes to disk.  All changes will also be saved collectively on exit
Error in CPG generation
script finished successfully
()

[pr0me]

I think raising an error in the framework is still the right approach.
It's possible that we would be fine in some cases, like here, where the error occurs in the post-processing passes.

But if it appears in earlier passes, information on which our queries depend might get lost and it's hard to check that.

[compaluca]

Spotting when the exception was precisely raised can be challenging, especially if we just used the joern cli. Two questions:

• can the exception be visible from the cli?
• if yes, would you have a set of exceptions that you would consider not so problematic?