SegFault when using ck_assert_int_* with MinGW on AppVeyor about check HOT 3 CLOSED

Thank you for providing the check unit test framework. I'm using it since a while in the CivetWeb web server project.

Glad to hear it! (:

fails with a SegFault with MinGW (Windows/AppVeyor).

Recently I added support for running Check and its own unit tests on AppVeyor for both MinGW and MinGW-64. I did fix a SIGSEGV, though it was with the floating ck macros.

Another user mentioned a crash in ck_assert_int_false (#75) when using g++ to cross-compile for MinGW. Maybe this is the same thing you are running into.

Since the AppVeyor environment is a remote service, I cannot directly debug it.

Oh, this is going to help you next time! Turns out that one can configure an AppVeyor build to pause when it is done and allow one to RDP into it to poke around and debug. Documentation here:

https://www.appveyor.com/docs/how-to/rdp-to-build-worker/

Unfortunately, there is also no "printf"-ish function, that will write to the build output (or, is there any?).

I am not sure I follow. Do you mean does Check have some sort of logging? If so, Check does not. However, one could simply call printf from a test and capture the output.

This made me conclude, there is some problem with the way MinGW expands the Check macros.
Do you know about any issues with check and MinGW that might explain this?

The SIGSEGV I tracked down earlier for MinGW was related to a snprintf call and the format specifier "lg", which would indicate a long double. However, gcc and MSVC interpret long double as different sizes, so using this specifier causes the var arg list to be misread, causing a SIGSEGV.

The only thing the macro would be doing differently is providing a canned printf-style message when the two integers are different.

If you are able to help track this down further, you could use the AppVeyor's RDP debugging support, install gdb from Cygwin (the setup.exe is probably in C:\cygwin), then attempt to run the unit test program under gdb. To make it easier you may want to run the unit tests with fork disabled (set environment variable CK_FORK=no) so that the SIGSEGV stops execution of the main thread. From gdb you will see the stack trace of the crash and hopefully some arguments. From that it can be confirmed if the crash is in vsnprintf. For example, in the SIGSEGV I fixed the back trace was:

#0 strlen
#1 vsnprintf
#2 _ck_assert_failed  check_check_sub.c:959
#3 test_ck_assert_double_eq

One interesting thing here is that Check has unit tests which check the int comparison macros (along with all the other macros) and those tests are running and passing on MinGW now. This would indicate that either Check's own unit tests are insufficient and are missing a bug, or the bug may be fixed in 0.11.0. If could try using 0.11.0 and if you find that it does crash, when the issue is ultimately resolved one or more unit tests should be added to Check to prevent a regression.

from check.

Thank you for your detailed answer. It seems switching from 0.10.0 to 0.11.0 solved the problem.
I will repeat a couple of tests that may take some hours, and tell you tomorrow if everything worked.

from check.

After some more tests, it seems all the MinGW problems are gone after updating to 0.11.0.
Thank's for your help.

from check.