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 <[email protected]> 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 >
