Simple hello world program crashes when linked to hoard

[hgaedke]

Hi,

I have compiled Hoard according to the instructions under Windows 10 with Compiler "Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24218.1 for x64".

I have then created a new dir containing

• hello.cpp
• make.bat
• libhoard.lib
• libhoard.dll
• uselibhoard.cpp

I am attaching the text files as "hg_test.zip" to this post:
hg_test.zip

I have then called "make" which creates "hello.exe", with this output on the console:
``
Microsoft (R) C/C++ Optimizing Compiler Version 19.00.24218.1 for x64
Copyright (C) Microsoft Corporation. All rights reserved.

hello.cpp
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\xlocale(341): warning C4530: C++ exception handler used, but unwind semantics are not enabled. Specify /EHsc
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\INCLUDE\exception(359): warning C4577: 'noexcept' used with no exception handling mode specified; termination on exception is not guaranteed. Specify /EHsc
uselibhoard.cpp
Generating Code...
Microsoft (R) Incremental Linker Version 14.00.24218.1
Copyright (C) Microsoft Corporation. All rights reserved.

/out:hello.exe
hello.obj
uselibhoard.obj
libhoard.lib
``

(OK - I have specified /EHsc in addition to get rid of those warnings, but this is irrelevant here as the crash still happens then.)

When I now execute "hello.exe", a popup window appears: "Appication Error - The application was unable to start correctly (0xc0000142). Click OK to close the application."

What am I doing wrong?

Best regards,
Hagen

[hgaedke]

Using the debugger I could locate the source of the crash; it's inside the hoard lib:

Any idea what must be done to fix this?

[hgaedke]

I have built Hoard in debug mode to see more.

Apparently accessing the this pointer of Entry caused a write access violation, i.e. Entry is not valid.

Entry has been created via _superblockSource.malloc(...):

=> At least a nullpointer check is missing here... But anyway: why does _superblockSource.malloc not return a valid allocated memory area?

[emeryberger]

1. Thanks for the bug report and full repro source code. Immensely helpful.
2. I'd love to know what you did to get into the debugger in this way. Feel free to send me mail directly.
3. I have AFAICT fixed the issue with cc8bf6c. It appears to be heap corruption caused by mixing the CRT heap and the Hoard heap; in previous versions, this just worked, but something has probably changed with a recent update. I just gave this a preliminary test (with your test case as well as some other code), and it seems to work. Please check it out.

[hgaedke]

Hi Emery,   thanks for fixing the issue so quickly! I have tried the new version; my small test program works now. However I still have problems integrating Hoard into our production code, it crashes during loading the hoard dll when calling the "_onexit" function (it registers a routine to be called at exit time) from inside the "utility.cpp" file in the VC runtime. I'm going to ask some colleagues, maybe someone has an idea.   Using the debugger that way was quite simple: first make sure you compile with /DEBUG:FULL to get a pdb file. Then just start the debugger and choose File / Open / Project/Solution. There, pick the compiled .exe file (the test program). Agree to save the solution somewhere. Then simply use Debug / Start Debugging; this runs the exe file with debugger attached.   Best regards, Hagen   Gesendet: Donnerstag, 24. Januar 2019 um 17:54 Uhr Von: "Emery Berger" <[email protected]> An: emeryberger/Hoard <[email protected]> Cc: hgaedke <[email protected]>, Author <[email protected]> Betreff: Re: [emeryberger/Hoard] Simple hello world program crashes when linked to hoard (#51) Thanks for the bug report and full repro source code. Immensely helpful. I'd love to know what you did to get into the debugger in this way. Feel free to send me mail directly. I have AFAICT fixed the issue with cc8bf6c. It appears to be heap corruption caused by mixing the CRT heap and the Hoard heap; in previous versions, this just worked, but something has probably changed with a recent update. I just gave this a preliminary test (with your test case as well as some other code), and it seems to work. Please check it out. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[hgaedke]

Hi Emery,   it seems that there is still a heap problem. The crash I get when starting my program is a heap corruption occurring via urctbase.dll => ntdll.dll, this sounds as there is still something wrong related to mixture of heaps as you wrote.   Unfortunately I am not able to send you a reproducer this time, as this occurs only when I try to integrate Hoard into our production code, and not with my small example.   Best regards, Hagen     Gesendet: Donnerstag, 24. Januar 2019 um 17:54 Uhr Von: "Emery Berger" <[email protected]> An: emeryberger/Hoard <[email protected]> Cc: hgaedke <[email protected]>, Author <[email protected]> Betreff: Re: [emeryberger/Hoard] Simple hello world program crashes when linked to hoard (#51) Thanks for the bug report and full repro source code. Immensely helpful. I'd love to know what you did to get into the debugger in this way. Feel free to send me mail directly. I have AFAICT fixed the issue with cc8bf6c. It appears to be heap corruption caused by mixing the CRT heap and the Hoard heap; in previous versions, this just worked, but something has probably changed with a recent update. I just gave this a preliminary test (with your test case as well as some other code), and it seems to work. Please check it out. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[emeryberger]

Is this only in _onexit, or elsewhere? Hoard shims _onexit, so this may be part of the issue.

[AbhiGHub]

Hi Emery, I have a VS 2017 solution for a similar issue.
MemAllocTest.zip

Thanks!
Abhi

[blattersturm]

There seem to be multiple issues here. For one, x86jump.h incorrectly assumes that 32-bit jumps will work within 4 GB on both sides of the jump, however since jump offsets are signed 32-bit values, this should be 2 GB max (0x7FFFFFFF, not 0xFFFFFFFF).

Also, it seems some Windows-internal components will have their own internal atexit/_onexit, but will call into ucrtbase's original _register_onexit_function which isn't shimmed anymore and ends up somewhat problematic on newer Windows 10 versions.

In addition to all that, _recalloc_base doesn't seem exported anymore leading to this entire stub approach failing in really bad ways when internal CRT APIs expect it to be usable.

[emeryberger]

Great investigative work! Much appreciated. I can work on this soon but I would also gladly accept a PR :).

[blattersturm]

Great investigative work! Much appreciated. I can work on this soon but I would also gladly accept a PR :).

I tried fixing the rabbit hole of internal UCRT calls directly, but given that some internal _base functions aren't exported anymore it might need a larger rework of how winwrapper works in order for it to work with the new 'rewritten' UCRT. 😕

For the time being our application just overrides operator new/delete but that of course won't override it for C libraries linked in at this time.

[barakw2021]

Hi,

Any news on the issue? I have a software that is running fine on Windows 2016, but crashes with the ucrtbase.dll immediately on Windows 2019.

Currently I'm able to run it with the 2013 horde version, but I'd like to upgrade to the latest version.

Thanks