Crash in TestUnitTest++.exe about unittest-cpp

[pjohnmeyer]

Interesting.

Out of curiosity, which MemoryOutStream build configuration are you using -- and can you try the other and see if the problem goes away? I don't have any strong hints but that might give us a clue (strcat is called directly in only one variant).

[wintertime]

I did not know there was a configuration setting for MemoryOutStream; where is it? Its probably been the default.

But I still had the files and when I ran it again today I noticed something else. The windows crash report listed a bunch of info (but did not let me copy it to the clipboard) and from that I found out that 0x0022???? is the stack and not a dll or part of the program. That means somehow a call must have been made to possibly garbage on the stack and then there may accidentally have been some bytes representing a call instruction to strcat which may have crashed from wrong callframe/input data?
I zip-ed the builds folder in case you can find more info from the cmake files or like to try running the exe inside a debugger yourself: https://www.dropbox.com/s/no8nm6msze8xi1g/crashing-unittest-cpp-build.zip?dl=0

[pjohnmeyer]

Config.h allows you to customize (either by modifying the file, or by passing defines to CMake) the behavior of MemoryOutStream. It should probably be explicitly made an option in the CMakeLists.txt instead of being hidden in Config.h, come to think of it.

Let me know if you make any progress on debugging this. I'd be happy to help remotely (via Google Hangouts or the like) sometime if that's an option.

[pjohnmeyer]

@wintertime any updates? Again, happy to help with the debugging remotely if possible.

[wintertime]

@pjohnmeyer Sorry to disappoint you, but I neither thought of nor used it meanwhile. My hope was you could do something with the data?

[pjohnmeyer]

Unfortunately, no, the data didn't help me much, aside from making it look like the optimizer might be causing a problem. I have not tried to replicate your build environment though; I was hoping to lean on you for that but if I need to get things set up myself then perhaps I will.

[slephant]

Correct me if I'm wrong, but it looks like the problem isn't in the UNITTEST_TIME_CONSTRAINT macro. It is declaring a TimeConstraint that stores a dangling reference (details) to a temporary constructed in the macro.

Judging by this, and elsewhere, in TestTimeConstraint.cpp, TimeConstraint looks like it wants to m_details to be a const TestDetails, not a reference, forwarding the line number from its parameter when it constructs the member.

Edit: a typo of inconsistency.

[ohz10]

@slephant TimeConstraint takes the UnitTest::TestDetails as a const&, it's fine that's a temporary; it would be a problem if it was a non-const&.

[pjohnmeyer]

Closing this due to inability to reproduce.