[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 |
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 <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
>> 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.
- Re: [Help-gsl] test release for GSL 2.4, (continued)
- Re: [Help-gsl] test release for GSL 2.4, Patrick Alken, 2017/06/22
- Re: [Help-gsl] test release for GSL 2.4, David Komanek, 2017/06/22
- Re: [Help-gsl] test release for GSL 2.4, Patrick Alken, 2017/06/22
- Re: [Help-gsl] test release for GSL 2.4, Mohammad Akhlaghi, 2017/06/22
- Re: [Help-gsl] test release for GSL 2.4, Patrick Alken, 2017/06/22
- Re: [Help-gsl] test release for GSL 2.4, Mohammad Akhlaghi, 2017/06/22
- Re: [Help-gsl] test release for GSL 2.4,
David Komanek <=
Re: [Help-gsl] test release for GSL 2.4, Piotr Tryniecki, 2017/06/14
Re: [Help-gsl] test release for GSL 2.4, Piotr Tryniecki, 2017/06/15
Re: [Help-gsl] test release for GSL 2.4, Brian Gladman, 2017/06/22