primus-checks analysis stalls during the initialization
JoWhitehead5751 opened this issue · 7 comments
I did an opam upgrade from 2.1.0-alpha+cfeacbf to 2.2.0-alpha+fdadc1d, and re-built the bap-tool kit (by executing make, make install). For some reason, all of bap's knowledge of the bap toolkit's plugins had vanished after the upgrade. Thus, I rebuilt the tool kit. Executing,
bap ./exe --recipe=primus-checks
causes bap to produce an incident report containing one line (exception Halt). So I checked the log file and a line in the log files states:
495 powerpc.info> Providing PowerPC semantics in BIL
496 cache.warning> Failed to read config file: ("Unix.Unix_error(Unix.ENOENT, "open", "/home/jonathan/.cache/bap/config.3")")
497 cache.info> caching to /home/jonathan/.cache/bap
498 disassemble.info> Setting GC parameters
499 disassemble.info> looking for knowledge with digest b7a3b4a65a62aba54633440350d3d518
500 bap.warning> region 0+0 can't be mapped into memory, (Failure "0xffffffffffffffff doesn't fit the int type")
501 bap.warning> region is not mapped to memory
While this cache warning looks like a red herring (and it is definitely an issue that we shall investigate) it shouldn't really affect the observed behavior.
So, let's troubleshoot it, can you provide output for the following commands in this exact order:
bap list plugins | wc -lbap cache --infobap ./exe -d(this should be a lot)
Once you will do this, let's cleanup the caches and run the analysis again,
bap cache --clean
bap ./exe --recipe=primus-checks
if it is still doesn't work, then let's try disabling the caching at all,
bap ./exe --recipe=primus-checks --no-cache
If it still doesn't work (then we basically eliminated the cache subsystem from the list of suspects), then we will need the trace.txt that will be created by the following command,
bap ./exe --run --run-entry-points=all-subroutines --primus-print-obs=all --primus-print-output=trace.txt --primus-promiscuous-mode --primus-greedy-scheduler
While this cache warning looks like a red herring (and it is definitely an issue that we shall investigate) it shouldn't really affect the observed behavior.
So, let's troubleshoot it, can you provide output for the following commands in this exact order:
bap list plugins | wc -lbap cache --infobap ./exe -d(this should be a lot)Once you will do this, let's cleanup the caches and run the analysis again,
bap cache --clean bap ./exe --recipe=primus-checksif it is still doesn't work, then let's try disabling the caching at all,
bap ./exe --recipe=primus-checks --no-cacheIf it still doesn't work (then we basically eliminated the cache subsystem from the list of suspects), then we will need the
trace.txtthat will be created by the following command,bap ./exe --run --run-entry-points=all-subroutines --primus-print-obs=all --primus-print-output=trace.txt --primus-promiscuous-mode --primus-greedy-scheduler
bap list plugins | wc -l
66
bap cache --info
Capacity: 4096 MB
Current size: 4854 MB
GC threshold: 5120 MB
Overhead: 25 %
GC enabled: true
bap ./CWE122_Heap_Based_Buffer_Overflow__c_CWE806_char_memmove_33_bad.out -d
I ruled out the cache subsystem as being a suspect by following your guide. Attached is the trace.txt:
trace.zip
Hmm, everything looks fine, except that there are no incidents nor incident-locations, can you please also provide the log file of the last run?
Hmm, everything looks fine, except that there are no incidents nor incident-locations, can you please also provide the log file of the last run?
Here it is:
The ENOENT warning is gone.
The primus-checks analysis (namely check-value and sensitive-sinks) analyses are broken because eval-cond signal is now triggered by any branching, including branching inside Primus Lisp. Therefore we're getting an infinite loop. As a temporary mitigation, #1123 we are switching to another observation (jumping) but the long term solution should enable eval-cond back.
it should now work, so I am closing this issue in favor of #1124, which will provide a long-term solution.
now, I really am closing it :)