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 > <al...@colorado.edu> 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.