Floating point macros cause SIGSEGV on Windows Server 2012 R2 using MiNGW

[brarcher]

When attempting to setup Check to build and test in AppVeyor for MinGW and Cygwin it was found that at least MinGW fails to run check_check_export. When run it will raise a SIGSEGV. Attaching a debugger, the failure was found here:

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

Namely, the vsnprintf(buf, BUFSIZ, msg, ap) call was leading to the failure, where the msg was Assertion ‘%s’ failed: %s == %.*lg, %s == %.*lg.

Removing the double and ldouble tests (floating tests) allows check_check_export to pass.

Note that the same tests pass on a Windows 7 64 bit machine but fail on AppVeyor.
Notes about MinGW and the AppVeyor Windows VM:

• MinGW compiles for 32 bit, not 64 bit.
• The Windows VM runs Windows Server 2012 R2, 64 bit.

[brarcher]

@9fcc:
While attempting to get unit tests running on AppVeyor (see #99) I hit this issue. I can help debug the issue further, if it is helpful. Additionally, AppVeyor allows one to RDP into a running VM and poke around, which is how I figured out what I did:

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

[andr-dots]

Once I had the same issue on Linux. What optimization level was used while compiling? It must be 0 to determine the real issue. Compiler can optimize strlen passed directly to the function in such a way that in would be a crash. But if temporary variable is used than optimization goes ok.
But in this case standard function used it internally, all arguments passed to the function are macro constants. So strlen just could not get segfault by itself.

ap argument need to be checked too. Right now I haven't much time.

Moreover Check has a lot of erroneous code by itself, it could be the issue to. It violates on of the CERT rules ('\0' must be added to a buffer after snprintf call). It can cause segmentation faults too.

[brarcher]

I've tried to simplify this case to determine the minimum which will cause the failure. Running a simple program using the following did cause the problem:

 void do_the_print(const char *expr, ...)
 {
     const char *msg;
     va_list ap;
     char buf[BUFSIZ];
     printf("BUFSIZ: %d\n", BUFSIZ);
 
     va_start(ap, expr);
 
     vsnprintf(buf, BUFSIZ, expr, ap);
     printf("%s\n", buf);
 
     va_end(ap);
 }
  
  #define MY_FLOATING_DIG 6
  
 #define example_macro(X, OP, Y, TP, TM) do { \
    TP _ck_x = (X); \
    TP _ck_y = (Y); \
    do_the_print("Assertion '%s' failed: %s == %.*"TM"g, %s == %.*"TM"g", \
   #X" "#OP" "#Y, \
   #X, (int)MY_FLOATING_DIG, _ck_x, \
   #Y, (int)MY_FLOATING_DIG, _ck_y); \
 } while (0)
          
int main()
{
   example_macro((double)1/(double)3, ==, 1.5, double, "l");
   return 0;
}

That results in the SIGSEGV on Windows 2012. However, on OSX the following is printed:

BUFSIZ: 1024
Assertion '(double)1/(double)3 == 1.5' failed: (double)1/(double)3 == 0.333333, 1.5 == 1.5

[brarcher]

I'll look into optimization levels and the other points that you mentioned.

[andr-dots]

I did not check if %.* format is in POSIX or C99 standard. So can you replace it by %g for the test? And remove (int)MY_FLOATING_DIG,.

[brarcher]

Removing the * and specifying the precision inline (%.6lg) does prevent the SIGSEGV, however the printout is not as expected.

OSX:

Assertion '(double)1/(double)3 == 1.5' failed: (double)1/(double)3 == 0.333333, 1.5 == 1.5

MinGW:

Assertion '(double)1/(double)3 == 1.5' failed: (double)1/(double)3 == -0, (null) == 0

Removing the precision specifier altogether and only using %lg printed the same on MinGW.

According to the printf man page on OSX from BSD, the 'l' specifier is unnecessary for double:

         Modifier    a, A, e, E, f, F, g, G
         l (ell)     double (ignored, same behavior as without it)
         L           long double

Attempting to remove that and use %.6g I get the following:

OSX:

Assertion '(double)1/(double)3 == 1.5' failed: (double)1/(double)3 == 0.333333, 1.5 == 1.5

MinGW:

Assertion '(double)1/(double)3 == 1.5' failed: (double)1/(double)3 == 0.333333, 1.5 == 1.5

So, it would seem that there are two things that need to be updated in the floating macros to get broader support:

1. Remove the .* from the printf specifier and hardcode the percision inline.
2. Remove the "l" specifier for double, as it is ignored on some platforms and causes problems on others.

[andr-dots]

I still want to check something for understanding. It's a very strange segfault. Can you replace (int)MY_FLOATING_DIG with a temporary variable in the minimal test?

[andr-dots]

And I did not found the C standard used to compile Check with configure.ac nor with CMakeLists.txt. How is it determined? "lf" modifier is allowed by C99 standard and it is the same as "f". As this table shows printf realization goes to libc:
https://gcc.gnu.org/c99status.html
I wander what library is user with MinGW because it just does not support C99 or has a bug. Or C89 standard was enabled by default. And using C89 for me is ridiculous.

[brarcher]

Can you replace (int)MY_FLOATING_DIG with a temporary variable in the minimal test?

I attempted this, so the macro became:

#define example_macro(X, OP, Y, TP, TM) do { \
  TP _ck_x = (X); \
  TP _ck_y = (Y); \
  int MY_FLOATING_DIG = 6; \
  do_the_print("Assertion '%s' failed: %s == %.*"TM"g, %s == %.*"TM"g", \
  #X" "#OP" "#Y, \
  #X, (int)MY_FLOATING_DIG, _ck_x, \
  #Y, (int)MY_FLOATING_DIG, _ck_y); \
} while (0)

example_macro((double)1/(double)3, ==, 1.5, double, "");

This was successful, printing the following in MinGW:

Assertion '(double)1/(double)3 == 1.5' failed: (double)1/(double)3 == 0.333333, 1.5 == 1.5

However, adding back the "l" for the modifier, specially:

example_macro((double)1/(double)3, ==, 1.5, double, "l");

still caused a SIGSEGV on MinGW.

[brarcher]

And I did not found the C standard used to compile Check with configure.ac nor with CMakeLists.txt. How is it determined?

I do not think that Check explicitly compiles with any particular C standard specified, but instead the features in Check try to stay in C99.

"lf" modifier is allowed by C99 standard and it is the same as "f".
I wander what library is user with MinGW because it just does not support C99 or has a bug.

I agree, according to the following from that link:

%lf conversion specifier allowed in printf	Library feature, no compiler support required (format checking support present).

According to the following link, the issue arises between mixing gcc and the MSVC runtime, which is what MinGW does:

http://stackoverflow.com/questions/7134547/gcc-printf-and-long-double-leads-to-wrong-output-c-type-conversion-messes-u

Specifically, the following describes what is doing on between double and long double:

The other part of this problem you're running into is that long double in GCC is a 
different type  than long double in MSVC. GCC uses a 96-bit or 128-bit type for 
long double on x86 or x64 targets 
(see http://gcc.gnu.org/onlinedocs/gcc/i386-and-x86_002d64-Options.html). 
However, MSVC uses a 64-bit type - basically long double is exactly the same 
as double for msvcrt.dll 
(http://msdn.microsoft.com/en-us/library/9cx8xs15.aspx)

Would have never guess that.

[brarcher]

This issue was resolved in #102.