Re: [Help-gsl] test release for GSL 2.4

[Patrick Alken]

In GSL 2.3 and earlier, the vector and matrix modules tested the
fwrite/fread routines by creating temporary files with mkstemp() and
fdopen(). Unfortunately neither of these routines conform to the ANSI
C89 standard and so I converted these tests to write to a fixed filename
"test.dat". However this caused the file race condition which was
reported in the recent test candidates (i.e. the "make check -j8"
error). So finally I switched to use tmpfile() which is C89 and seems to
be the only ANSI-compatible method of using temporary files in C. But
now it seems that some windows systems fail with this method due to
permission restrictions.

I can certainly modify the tests to check for a NULL pointer coming out
of tmpfile, but this would then disable these tests on your windows
systems, which is not ideal either. It appears we must either accept
that the matrix/vector fread/fwrite routines cannot be properly tested
on windows systems, or go back to a non-ANSI method of writing the
temporary files. Neither of these choices seem good to me, but my
preference would be to follow the C89 standard if possible.

I thought about writing a routine inside GSL to perform the same task as
mkstemp() does, but it seems this is not possible in C89 since mkstemp
relies on calling open() with O_EXCL to raise an error if the file
already exists, but open() is also not C89.

I am open to suggestions if anyone knows of a solution to this problem.

Patrick

On 06/21/2017 03:26 PM, Max Gaspa wrote:
> Dear all,
>
> Sisyphus wrote
>
>> Much the same situation here - Windows 7 64 bit, mingw-w64 port of 64-bit 
>> gcc-6.3.0 (x86_64-posix-sjlj-rev1).
>> And, like you (apparently), I didn't test the release candidates :-(
> Yes. And Yes. I didn't check the release candidate because the short
> time between the availability of the RC and the availability of the
> official release.
>
>
> Anyway I think I found the reason of the issue just following the
> program flow with gdb. The issue is NOT related to malloc(0) (I' still
> thinking that is not a good programming practice but I will accept it
> :-) )
>
> I'm discussing the issue for vector just to describe it in a simpler way.
>
> The reason of the segmentation fault is the latest modification made
> by Patrick 7 days ago into test_source.c  ( described by "fix file
> race condition for 'make check -j8'" ).
>
> The lines involved are
>
> - char filename[] = "test.dat";
> + FILE *f = tmpfile();
>
> in few words the change imply using tmpfile(). Unfortunately in
> Windows (XP is fine! 7 fails) that call is creating a temporary file
> in C:\ that is usually not writable for security reason. The call
> fails and the pointer f is NULL. Because there are no checking for
> NULL after the call to tmpfile()  (It seems GSL developer love not
> checking for null pointer!!!! :-) :-) :-)  ) and the next call to
> fprintf will use NULL as its stream you get the segmentation fault.
>
> Now I'm trying to revert the change (just using the release candidate
> version should be fine)  to see if the issue is fixed, but I'm quite
> sure because gdb told me that f  was  NULL but it was used as a valid
> pointer for the stream
>
> For reference:
>
> Microsoft documentation of the C runtime library (used by MinGW) for tmpfile()
>
> *******
> The tmpfile() function creates a temporary file and returns a pointer
> to that stream. The temporary file is created in the root directory.
> To create a temporary file in a directory other than the root, use
> tmpnam or tempnam in conjunction with fopen.
>
> If the file cannot be opened, tmpfile returns a NULL pointer. This
> temporary file is automatically deleted when the file is closed, when
> the program terminates normally, or when _rmtmp is called, assuming
> that the current working directory does not change. The temporary file
> is opened in w+b (binary read/write) mode.
>
> Failure can occur if you attempt more than TMP_MAX (see STDIO.H) calls
> with tmpfile.
>
> *********
>
> I'm also observing the error related to the Bessel function like you.
> I think I know the reason. The GSL developers are now using sin and
> cos function from the runtime library. Before that change the
> numerical error of gsl_sf_sin and gsl_sf_cos function from GLS was
> added to the total error with
>
> result->err  = fabs(f * sin_result.err/x) + fabs((3.0*cos_result.err/x)/x);
>
> in the new code sin and cos were considered as they are perfectly
> precise (sin and cos precision depends on processor and it's known
> their precision can be more, much more, greatter than 1 ulp), so the
> new implementation and the threshold used to pass the test are no
> longer OK for my (and your) processor.
>
> I'd like to change the compilation flags (using SSE2 and or
> -mfloat-store) just to see what will happen...and then using MPFR I'd
> like to understand better the reason of the failure.
>
> Hope this helps
>
> Regards
>
> Max
>