Despite unchecking this option in analysis option when opening new file to analyze, IDA still applies __noreturn to some functions. This happens on both disassembly level (when function is marked Does not return) and decompiler level (__noreturn).
I also noticed that when IDA Pro applies FLIRT signatures, and misidentifies operator new for exit (due to them having equivalent code if the binary is linked static to SmartHeap, for example), it breaks the entire program. Since exit is automatically annotated __noreturn and operator new is one of the most frequently called functions in C++, this causes a massive cascade decompilation and disassembly analysis failures.
Hi! Same as before, we’d need a sample and minimal reproducible steps to dig into this, so filing a Bug Report would be the best way to get it thoroughly investigated. Thanks again!
Steps to reproduce:
- Open the file in IDA
- Uncheck “Perform no-return analysis” and wait for analysis to complete
- Jump to function
0x8D98A0(IDA FLIRT thinks it’s Microsoft C Runtimeexit(), it’s actuallyoperator newof the SmartHeap library)
As you can see, it’s marked __noreturn despite being “Perform no-return analysis” being disabled.
Also, I would like to stress that in this binary, IDA struggles to identify many function boundaries and doesn’t disassemble them fully, for example the function at 0x732410 is completely broken, or pieces like 0x718CCC, 0x808384
exe.7z (1.6 MB)
Thank you for the sample! It seems the names listed in noret.cfg are marked as no-returning regardless of the setting. We’ll have a look at fixing this; in the meantime you can rename the cfg file or comment out exit entry.