blink: blink.exe crash when editing program built with the /bigobj flag
I just found out about this project and it looks really interesting. 😃
I’m trying to see if I can edit code from a little game engine project I have and see the result right away with blink.
The target program is built in Debug mode.
I attach blink.exe to the program by giving it the PID.
When I modify a file, I have a debug assertion triggered inside vector’s operator().
This occurs in blink::application::build_compile_command_line() when creating
std::vector<char> debug_data(section->SizeOfRawData);
section here is an iterator returned by the std::find_if function that seems to look for a section of the name .debug$S but doesn’t find it.
The value of the iterator is never checked before de-referencing it.
I’m currently trying to understand why my program doesn’t have a “debug” section here, but I really feel like the following code should only be executed after testing section != sections.end() to check if it was found… 🤔
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Comments: 16 (16 by maintainers)
Commits related to this issue
- Fix crash when object file does not contain ".debug$S" sections See #23 — committed to crosire/blink by crosire 5 years ago
- Update README after changes made in #23 and #25 — committed to Ybalrid/blink by Ybalrid 5 years ago
- Update README after changes made in #23 and #25 (#26) — committed to crosire/blink by Ybalrid 5 years ago
I fixed it for bigobj. (see #25)
There’s 2 things that changes when object files are “big” objects files :
1 - the COFF header is an extended version 2 - Each symbols uses an extended version that occupies more than the 18 bytes of the regular one.
What I did is that I refactored the “link” function past the problematic point to some templated things around the type of the symbol records.
All of the reallocation logic is the same.
okay so, the file is indeed read properly (this would be strange)
Maybe that object file is not of the right format?
Now that I think about it, the project is linking to some pretty big header only libraries (ChaiScript, GLM) in some of it’s compilation units, and I had to add the
/bigobjto my build options. Reading MSDN, this increase the possible number of sections in the file to a 32bit value. So, what’s probably happening here is that blink is not reading the header properly because… Well, it’s not a normal COFF header anyway…! 😮update when a symbol has been built with /bigobj, the header is an extended one. the Win32 API has a structure called
ANON_OBJECT_HEADER_BIGOBJthat has the correct layout. I need to confirm this, but it’s possible to test the difference by checking in the header (read normally) if the machine type is0x0000and the number of sections is0xFFFF.Gonna do some more testing, but I feel like I’m onto something
update 2 I have a patch where now it finds and read correctly the
.debug$Ssection from the file, I’m going to pull request it soon.Now I’m facing another issue where it is not finding the compiler command line inside the section.
using dumpbin, it seems that the strings “cdw” or “cl.” or “-Zi” aren’t present in this section of the object file.
Doing a full dump, nowhere in that file you can find these strings either.
Correct me if I’m wrong, but shoudln’t I be able to find the compilation command of an object file if it has been build with
/Zi?