[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: David Komanek
Subject: Re: [Help-gsl] test release for GSL 2.4
Date: Thu, 22 Jun 2017 11:26:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.0


each process and thread has its unique id, is it possible to construct
the filename using these numbers ? Or, is UUID ANSI-compliant ?



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 <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
>>>     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. 

reply via email to

[Prev in Thread] Current Thread [Next in Thread]