[Top][All Lists]

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

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

Subject: Re: [Help-gsl] test release for GSL 2.4
Date: Wed, 21 Jun 2017 10:40:10 -0400

Greeetings All,

Let Appveyor attest to the "HEAP CORRUPTION DETECTED".
TestMatrix.exe && TestVector.exe Failed. [See Attached Screenshot]


On Wed, Jun 21, 2017 at 9:26 AM, Max Gaspa <address@hidden> 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

Attachment: GSL_2.4_MSVC_Fail.png
Description: PNG image

reply via email to

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