PulseTaintOperations Causing Analysis Crash

[matjin]

Hello -- it seems that modifications made during April 2022 to PulseTaintOperations seem to be causing the analysis to crash in certain scenarios. Below is the stack trace. I did check out commit 2e1119932b895ad126faa4f56799d59cc3b34697 from March 31 and reran my example to validate that the crash does not occur on that version. Would it be possible to add some kind of exception handling to PulseTaintOperations to prevent this issue from resulting in analysis crash?

Internal Error: ok_exn of something not Ok Error backtrace: Raised at StdlibMap.Make.min_binding in file "map.ml", line 231, characters 17-32 Called from AbsintScheduler.ReversePostorder.pop in file "src/absint/Scheduler.ml", line 87, characters 31-55 Re-raised at IBaseDie.raise_error.do_raise in file "src/base/Die.ml", line 26, characters 8-56 Called from Pulselib__PulseTaintOperations.taint_initial.(fun) in file "src/pulse/PulseTaintOperations.ml", line 536, characters 10-116 Called from BaseList.fold_map.(fun) in file "src/list.ml", line 432, characters 23-31 Called from BaseList.count_map in file "src/list.ml", line 394, characters 13-17 Called from BaseList.map in file "src/list.ml" (inlined), line 418, characters 15-31 Called from BaseList.fold_map in file "src/list.ml", line 431, characters 4-88 Called from PulselibPulseTaintOperations.taint_initial in file "src/pulse/PulseTaintOperations.ml", line 533, characters 4-428 Called from PulselibPulse.initial in file "src/pulse/Pulse.ml", line 796, characters 4-169 Called from PulselibPulse.analyze in file "src/pulse/Pulse.ml", line 843, characters 6-163 Called from BackendCallbackOfChecker.interprocedural_with_field in file "src/backend/CallbackOfChecker.ml", line 55, characters 15-36 Called from BackendCallbacks.iterate_procedure_callbacks.(fun) in file "src/backend/callbacks.ml", line 58, characters 22-49 Called from StdlibList.fold_left in file "list.ml", line 121, characters 24-34 Called from BackendOndemand.analyze in file "src/backend/ondemand.ml", line 155, characters 16-76 Re-raised at IStdlibIExn.reraise_if in file "src/istd/IExn.ml", line 18, characters 15-63 Called from BackendOndemand.run_proc_analysis in file "src/backend/ondemand.ml", line 225, characters 4-752 Called from BackendOndemand.analyze_proc_name_no_caller in file "src/backend/ondemand.ml" (inlined), line 342, characters 2-58 Called from BackendOndemand.analyze_procedures.analyze_proc_name_call in file "src/backend/ondemand.ml", line 348, characters 12-53 Called from StdlibList.iter in file "list.ml", line 110, characters 12-15 Called from BaseList0.iter in file "src/list0.ml" (inlined), line 25, characters 16-35 Called from BackendOndemand.analyze_procedures in file "src/backend/ondemand.ml", line 350, characters 2-54 Called from Backend__InferAnalyzeJson.analyze_json in file "src/backend/InferAnalyzeJson.ml", line 722, characters 2-43 Called from IntegrationDriver.execute_analyze_json in file "src/integration/Driver.ml", line 200, characters 6-54 Called from IBaseUtils.timeit in file "src/base/Utils.ml", line 424, characters 16-20 Called from IBaseScubaLogging.execute_with_time_logging in file "src/base/ScubaLogging.ml", line 83, characters 29-44 Called from DuneexeInfer.run in file "src/infer.ml", line 21, characters 2-47 Called from IBaseUtils.timeit in file "src/base/Utils.ml", line 424, characters 16-20 Called from IBaseScubaLogging.execute_with_time_logging in file "src/base/ScubaLogging.ml", line 83, characters 29-44 Called from DuneexeInfer.run in file "src/infer.ml", line 25, characters 22-94

[jvillard]

Fair enough, we should make sure this doesn't crash! I'm curious why it does though: what this does is dereference the address of formal parameters to get to their values in order to compute the initial state of the analysis of the current function. This should be uncontroversial and not result in an error to report to the user. I'll see how I can silence this but would love to debug it further if you have more information.

[matjin]

OK! I will follow up with the debug output :)

[jvillard]

Should be fixed by 02a784948f4aa629234362c258bc2bfa01f6f3ad