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

[ƦOB COASTN]

Greeetings All,

Let Appveyor attest to the "HEAP CORRUPTION DETECTED".
https://ci.appveyor.com/project/mancoast/gsl-msvc/build/1.0.1.0.0.7.8-master
TestMatrix.exe && TestVector.exe Failed. [See Attached Screenshot]

Thanks,
coast

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
>

GSL_2.4_MSVC_Fail.png
Description: PNG image