Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can't deallocate memory returned by fftw_export_wisdom_to_string() #429

Closed
d0sboots opened this issue Oct 16, 2020 · 10 comments
Closed

Can't deallocate memory returned by fftw_export_wisdom_to_string() #429

d0sboots opened this issue Oct 16, 2020 · 10 comments

Comments

@d0sboots
Copy link

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
Copy link
Member

saudet commented Oct 16, 2020

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

@saudet
Copy link
Member

saudet commented Oct 16, 2020

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

@d0sboots
Copy link
Author

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
Copy link
Member

saudet commented Oct 16, 2020

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
Copy link
Member

saudet commented Oct 16, 2020

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

@d0sboots
Copy link
Author

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
Copy link
Member

saudet commented Oct 16, 2020

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

saudet added a commit to bytedeco/javacpp-presets that referenced this issue Oct 16, 2020
@d0sboots
Copy link
Author

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
Copy link
Member

saudet commented Oct 18, 2020

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
Copy link
Member

saudet commented Mar 10, 2021

This addition has been released with version 1.5.5! Enjoy

@saudet saudet closed this as completed Mar 10, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants