You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
Run Binary Ninja.
Open binary for analysis.
Wait for automated analysis to complete.
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.
The text was updated successfully, but these errors were encountered:
Version and Platform (required):
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:
Expected Behavior:
Analysis completes without the program crashing.
Screenshots:
An example backtrace:
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.The text was updated successfully, but these errors were encountered: