Hi, each process and thread has its unique id, is it possible to construct the filename using these numbers ? Or, is UUID ANSI-compliant ?
Regards, David On 06/22/2017 10:28 AM, Mohammad Akhlaghi wrote: > 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 <[email protected]> > 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 >>> <[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.
