Can't deallocate memory returned by fftw_export_wisdom_to_string()

[d0sboots]

Here's a minimal repro. I'm seeing this with javacpp and javacpp-presets 1.5.4, with only the 8 jars javacpp{-platform,-windows-x86,-windows-x86_64,,}.jar and fftw{-platform,-windows-x86,-windows-x86_64,,}.jar on the classpath.

public class Main {
    public static void main(String[] args) {
        Loader.load(org.bytedeco.fftw.global.fftw3.class);
        Pointer data1 = Pointer.malloc(10);
        System.out.printf("data1:0x%08xd\n", data1.address());
        Pointer.free(data1);
        BytePointer data2 = fftw_export_wisdom_to_string();
        System.out.printf("data2:0x%08xd\n", data2.address());
        Pointer.free(data2); // Crashes here
    }
}

This produces:

data1:0x1f126290d
data2:0x00284500d
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x000000007712a407, pid=17116, tid=0x0000000000002b0c
#
# JRE version: Java(TM) SE Runtime Environment (8.0_261-b12) (build 1.8.0_261-b12)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.261-b12 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [ntdll.dll+0x2a407]
#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows
#
# An error report file with more information is saved as:
# C:\Users\D\eclipse-workspace-gl\crash-repro\hs_err_pid17116.log
#
# If you would like to submit a bug report, please visit:
#   http://bugreport.java.com/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

As you can see, the two pointers have very different address ranges, which shows that they're being allocated from different heaps. (Which explains why free()'ing crashes.) fftw_export_wisdom_to_string() is documented as returning memory that needs to be free'd, see here: http://www.fftw.org/fftw3_doc/Wisdom-Export.html. And you can clearly see in the code that they're using plain malloc() for the result: https://github.com/FFTW/fftw3/blob/master/api/export-wisdom-to-string.c

So, how do I get access (from Java) to the free() that corresponds to the malloc() that fftw is linking against?

[saudet]

That would be Pointer.free(). FFTW's documentation may be incorrect here...

[saudet]

Ah, no, Pointer.free() is from MSVC, while FFTW needs GCC, see FFTW/fftw3#104.

[d0sboots]

So if I'm reading it right, the issue comes from using the pre-built FFTW dlls, when the native parts of javacpp are compiled with a different compiler or different compiler version?

[saudet]

No, it's because FFTW doesn't support MSVC, only GCC. It looks like it's possible to hack it to build with MSVC, but whatever, it's most likely happier with GCC anyway. I'll include a free() method as part of the API of the presets for FFTW and that will fix this.

[saudet]

But yes, JavaCPP itself uses MSVC on Windows because that's the standard compiler on that platform.

[d0sboots]

OK, thanks! It's not a blocker for me because I'm only using it right before exit, so I can afford to leak some memory.

Incidentally, I wouldn't have uncovered this except fftw_export_wisdom_to_filename() wasn't working for me at all - it was always returning failure. http://www.fftw.org/install/windows.html#DLLwisdom seems to think this issue shouldn't affect that, but maybe it is? It's not like it returns a detailed errno to figure out what's going on...

[saudet]

fftw_export_wisdom_to_filename() should work, yeah... Any code snippet about what that looks like?

[d0sboots]

Just:

int res = fftwf_export_wisdom_to_filename(WISDOM_FILE.toString());
System.out.printf("Wisdom %s to %s\n", res == 1 ? "successfully written" : "writing failed", WISDOM_FILE);

And it always fails, which I can verify by no file being created. I switched to exporting the string and writing it with Java (with the exact same path constant), which works (but leaks memory). Importing using fftwf_import_wisdom_from_filename(WISDOM_FILE.toString()) works fine. (For reasons, I switch to fftwf routines, which I know aren't compatible with fftw routines, but I switched globally - the problem was the same with fftw.)

Edit: Or, it used to always fail. It's working now. I think the issue is that it was unable to create the file - maybe a permissions issue of some type? But it seem to be fine with overwriting the file once it exists.

[saudet]

Ah, ok, yes probably a permission issue. Thanks for reporting!
In any case, I've added free() to commit bytedeco/javacpp-presets@7cc3b75.
Please give it a try with the snapshots: http://bytedeco.org/builds/

[saudet]

This addition has been released with version 1.5.5! Enjoy