Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Frequent crashes during attempted analysis #6181

Open
bblough opened this issue Nov 23, 2024 · 1 comment
Open

Frequent crashes during attempted analysis #6181

bblough opened this issue Nov 23, 2024 · 1 comment

Comments

@bblough
Copy link

bblough commented Nov 23, 2024

Version and Platform (required):

  • Binary Ninja Version: 4.2.6455 free, 2c8da1e
  • OS: debian
  • OS Version: 12
  • CPU Architecture: x86_64

Bug Description:
I'm getting a lot of crashes whilst trying to evaluate Binary Ninja. I'd say over half of the binaries I have tried to analyze cause a crash. The crashes are typically due to segmentation faults, and while the stack traces vary, they often show invalid frame addresses or other memory corruption. In some cases, rather than segfaults, I have seen libc abort due to invalid mallocs or frees.

There have been a couple of times where a binary that crashed would analyze successfully the next time I tried, but those seem to be exceptions. It seems like most of the binaries that cause the crash will do so somewhat consistently.

Steps To Reproduce:

  1. Run Binary Ninja.
  2. Open binary for analysis.
  3. Wait for automated analysis to complete.
  4. Observe crash prior to analysis completing.

Expected Behavior:
Analysis completes without the program crashing.

Screenshots:
An example backtrace:

Core was generated by `binaryninja'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007fdcd9fcb650 in ?? ()
[Current thread is 1 (Thread 0x7fdec08976c0 (LWP 11598))]
(gdb) bt
#0  0x00007fdcd9fcb650 in ?? ()
#1  0x00007fdcd9fcb650 in ?? ()
#2  0x0000000000000001 in ?? ()
#3  0x0000000003dde12d in ?? ()
#4  0x0000000000000205 in ?? ()
#5  0x00007fdd59191980 in ?? ()
#6  0x00007fde00010000 in ?? ()
#7  0x000000000000001c in ?? ()
#8  0x0000000000000000 in ?? ()

Additional Information:

The binaries are of varying sizes, but typically 5MB-50MB, and are either PE or ELF for x86 or x86_64.

The system has a 13th gen Intel, so I thought this might be related to #5449 . However, the microcode is 0x129, and thus newer than the recommended 0x125. As a data point, I downloaded the ntoskernel binary in that thread and Binary Ninja was able to analyze it without crashing. I also tried reducing the max worker threads as low as 4, but it didn't stop the crashes with the other binaries, it just took longer for the crashes to happen.

The system has 64GB RAM, and so far I haven't seen it go above 50% utilization, so I don't think it's an OOM situation.

I have installed the fonts-noto-color-emoji package as mentioned in the user guide.

@xusheng6
Copy link
Member

Thanks for the bug report, could you please provide us with a few samples for us to reproduce it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants