The `free()` function crashes on Windows

[ObserverOfTime]

free() is used in these 3 places and it only crashes on Windows.
I don't know how to debug this, so I've disabled the calls for the time being.
This may lead to minor memory leaks but at least it won't crash.

java-tree-sitter/src/main/java/io/github/treesitter/jtreesitter/Node.java

Line 443 in 9c5eb24

if (IS_UNIX) free(string);

java-tree-sitter/src/main/java/io/github/treesitter/jtreesitter/Tree.java

Line 98 in 9c5eb24

if (IS_UNIX) free(ranges);

java-tree-sitter/src/main/java/io/github/treesitter/jtreesitter/Tree.java

Line 125 in 9c5eb24

if (IS_UNIX) free(ranges);

It seems when using ts_set_allocator to specify custom allocation functions which just use the standard malloc, free, ... then the JVM does not crash, see https://github.com/maloewe-ona/java-tree-sitter/tree/windows-custom-alloc (unless I made a mistake there)

This is not really a useful workaround, but maybe it is helpful for finding the cause or it gives a hint what could be the reason? It seems somehow the default allocation functions used by tree-sitter internally are not compatible with the free function obtained through FFM on Windows. But each on their own works correctly: The default tree-sitter allocation functions work fine when tree-sitter internally allocates and frees memory, and configuring tree-sitter to only use the allocation functions through FFM (as done with the ts_set_allocator approach above) also works fine. Only the combination of memory allocated internally by tree-sitter but freed through FFM with free seems to be an issue.

I also tried to use ts_current_free instead of free but that crashes the JVM as well on Windows for me.

When I experienced this crash on Windows, I was using using MinGW gcc on Linux to cross compile for Windows. So maybe the crash is 'expected' in that case since it is linking to different allocation functions?

On a different Windows machine, I have tried to reduce this to a minimal example which performs malloc in native code and free through FFM and vice versa. When using gcc or clang with GNU as target it crashed, but with clang and MSVC as target it seemed to work.
I also tried to test java-tree-sitter there, using the cmake builds for tree-sitter and tree-sitter-java. But even though this was apparently using the MSVC build tools, it crashed nonetheless for the free calls. (Maybe I made some mistake during the build though?)

So the ts_set_allocator approach in #75 is probably a good solution, unless someone has other ideas how this could be solved.

I am not that familiar with native compilation, so sorry in case the behavior described above is obvious.