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

[Patrick Alken]

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.