large binaries cause 100% cpu usage and steadily increasing memory usage

[m4b]

I've tested on largish binaries, say 20MB, and panopticon goes into CPU loop with 100% cpu usage and a memory usage that continually increases until OOM.

I think it might be helpful to add in addition to #225, a text-only output option as well, to have panopticon dump the call-graph and program analysis + disassembly for a given target to see if this is libpanopticon related or qt-related.

I don't think there's a technical reason why analysis should have problems for a 20MB binary? (unless there is some analysis algorithm with non-linear complexity?)

[flanfly]

Hey @m4b, thanks for the bug report. I know that the frontend tends to freeze during disassembly but I never had any OOM errors. Some of the algorithms inside the disassembler do have quadratic or even cubic time complexity, but memory consumption should be rather low so this is definitely a solvable problem.

When starting Panopticon on the command line with the RUST_LOG environment variable set to panopticon=debug you should see some debugging output. Maybe there are hints which stage consumes all the CPU time and memory. I also wonder if this is related to the problem @maxbrito has (#221).

[m4b]

I definitely think its related to #221, as the failing ELF binary they reported was approximately 20MB.

I will try to repro this with debugging on soon

[m4b]

I've been doing some benching on a "headless" panopticon backend which performs the analysis but just prints and it performs a complete disassembly of 2k functions in libc, and then analyzes found functions until it cannot find any more (or disassembly fails), which ends up with a approximately 1-2k more and it does this in about 10-15 seconds on a particular machine with about 7% memory usage.

I then tested this headless version with a hacked QT version, and regular version and it looks like there's some kind of runaway memory usage on the QT side, as memory usage blows up to 30-50% for same analysis.

Need to investigate more but I don't think it's related to the panopticon back end side of things

[flanfly]

Makes sense. Panopticon emits a signal every time it finds a new function. The frontend then queries alot of information every time this happens. Using a less stupid way may solve this. Thanks for the debugging @m4b!

[flanfly]

The new UI fixes most of the memory & performance issues. Thanks again!