Open Raphtaliyah opened 2 days ago
Thanks for reporting. This definitely sounds like a bug to me. Did this happen to be for the same executable that you already shared with me?
Yes, it's the same!
Without disassembly improvements:
2024-11-13 | 14:04:54 | INFO | (AutoAnalysisManager) ----------------------------------------------------- |
---|---|---|---|
ASCII Strings 2.798 secs | |||
Apply Data Archives 0.325 secs | |||
Call Convention ID 0.199 secs | |||
Call-Fixup Installer 0.633 secs | |||
Create Address Tables 1.459 secs | |||
Create Address Tables - One Time 10.360 secs | |||
Create Function 3.597 secs | |||
Data Reference 2.287 secs | |||
Decompiler Switch Analysis 62.805 secs | |||
Decompiler Switch Analysis - One Time 788.057 secs | |||
Demangler Microsoft 0.342 secs | |||
Disassemble 7.303 secs | |||
Disassemble Entry Points 2.235 secs | |||
Disassemble Entry Points - One Time 0.002 secs | |||
Embedded Media 0.287 secs | |||
External Entry References 0.002 secs | |||
Function ID 5.857 secs | |||
Function Start Pre Search 0.061 secs | |||
Function Start Search 2.144 secs | |||
Function Start Search After Code 2.150 secs | |||
Function Start Search After Data 1.366 secs | |||
Function Start Search delayed - One Time 0.049 secs | |||
Kaiju Function Hashing 28.663 secs | |||
Non-Returning Functions - Discovered 8.774 secs | |||
Non-Returning Functions - Known 0.005 secs | |||
PDB Universal 0.008 secs | |||
Reference 2.359 secs | |||
Scalar Operand References 6.959 secs | |||
Shared Return Calls 1.789 secs | |||
Stack 23.121 secs | |||
Subroutine References 2.132 secs | |||
Subroutine References - One Time 0.088 secs | |||
Windows x86 PE Exception Handling 5.720 secs | |||
Windows x86 PE RTTI Analyzer 17.349 secs | |||
Windows x86 Thread Environment Block (TEB) Analyzer 0.012 secs | |||
WindowsResourceReference 0.961 secs | |||
X86 Function Callee Purge 26.814 secs | |||
x86 Constant Reference Analyzer 22.840 secs | |||
----------------------------------------------------- | |||
Total Time 1041 secs |
Describe the bug Ghidra (11.2.*) spends a suspiciously long time at the 'Analyzing gaps' step when analysing a 9 MB 32 bit windows executable (the same executable from cmu-sei/pharos#274). At first I didn't want to report this as a bug because "surely it just takes this long" until I saw a similar issue (#65) where someone was analysing a larger executable for 9 hours and after a fix it end up being 640 seconds so I assume something has to be wrong here as well and it shouldn't take this long.
Looking at the logs (of which I have 2 GBs of (spread across 29 files) just from this!) it's mostly
Skipping address
, searching for any of the addresses shows around 67 matches/file. Looking for anything notSkipping address
isCreated alignment at:
, the addresses are unique but in between them there is this repeating:Always the same address.
There is nothing else in the log files (other than when I stopped it),
Kaiju Disassembly Improvements
ran for 14 hours and did 26880 iterations.To Reproduce Steps to reproduce the behavior:
Expected behavior Less waiting? (Unless this isn't a bug and is expected behaviour...)
Desktop (please complete the following information):