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

[Mohammad Akhlaghi]

Hi Patrick,

How about using two separate files (file names) for vector and matrix tests? 

For example "test-vector.dat" and "test-matrix.dat".

Cheers,
Mohammad

On June 22, 2017 8:12:06 AM GMT+01:00, Patrick Alken <address@hidden> wrote:
>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
>>

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.