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

[Mohammad Akhlaghi]

Hi Patrick,

Thanks for the correction. 

So the two tests are identical except for the versions of the functions. Can't 
they also differ in the filename they use? 

For example one could read/write to "test-non-inline.dat" and the other to 
"test-inline.dat".

Cheers,
Mohammad

On June 22, 2017 9:00:22 AM GMT+01:00, Patrick Alken <address@hidden> wrote:
>Its not a race condition between the files written by matrix/vector.
>The
>vector module itself has two test programs, which are identical except
>one tests the non-inline versions of the functions and the other tests
>the inline versions. So if these two tests are run in parallel, via
>make
>check -j8, they will write the same test file name at the same time if
>we use a static filename.
>
>Patrick
>
>On 06/22/2017 09:56 AM, Mohammad Akhlaghi wrote:
>> 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. 

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