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

[Max Gaspa]

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