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 <[email protected]> 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.
