Access violation in sf::String destructor (empty string) on Debian Squeeze

[pdinklag]

Testing JSFML on a university machine, I ran into an access violation when setting an empty string on a Text. I added some debug info output and it turned out this way:
http://pastebin.com/fJHQHFdt

The native method that sets the string on the sf::Text object suceeds, however, after doing so it crashes. Apparently, the destructor of the locally allocated sf::String runs into a free() call for something that was never allocated.

The operating system on the machine in question is Debian Squeeze. More exactly:

Code: [Select]

$ cat /etc/lsb-release
DISTRIB_ID=Debian
DISTRIB_RELEASE=6.0
DISTRIB_CODENAME=squeeze
DISTRIB_DESCRIPTION="Debian 6.0.6"
$ uname -a
Linux fiws185 2.6.39-bpo.2-686-pae #1 SMP Fri Feb 3 17:37:38 CET 2012 i686 GNU/Linux
I failed to reproduce this in a VM with Debian Squeeze (slightly older and modded Kernel version) and I have never observed this on Windows (obviously, as it seems to be something in glibc that fails).

The code in question is this: https://github.com/pdinklag/JSFML/blob/master/src/cpp/JNI/org_jsfml_graphics_Text.cpp#L75

In Java, a minimal code sample to reproduce the problem would be:

new Text().setString("");

I assume that a C program as simple as that would result in the same error, but I did not have the time yet to set up an SFML working environment on that system yet (compiling SFML on it won't be possible due to the lack of rights to install dev packages).

Can anybody give me a hint on what may be going wrong or can anybody maybe even confirm this?

[Laurent]

I assume that a C program as simple as that would result in the same error

Are you really sure that it can't be a bug in the Java binding? Problems can popup easily when dynamic C++ allocations occur in a garbage collected environment.

[pdinklag]

Nope, that's highly unlikely here.

I pass an empty Java String to the setString method, which does security checks (e.g. makes sure the string is not null) and delegates the call to that native method I pointed to. To make sure there are no problems converting an empty string, I caught that case and construct an sf::String with an empty ANSI C string (that line #75).

In that case only I get said "invalid pointer" in libc's free() method. It works perfectly well with any non-empty string.

There are no pointers or references that have to be held anywhere (like in the Font class, where I need to keep the font data in memory as long as the font is in use), since iirc, the sf::String::setString method creates a copy of the string passed to it for its own (in Uint32 / unicode). So garbage collection can most probably be ruled out here.

If I didn't link the binaries on a Debian i686 myself, I'd say maybe it's an incompatibility of sorts, but I built the JSFML binaries in a Debian Squeeze VM and the issue doesn't occur there. Which makes this whole problem a real pain to analyze...

[Laurent]

And unfortunately, I can tell you that it's very unlikely to be a bug in SFML (I use std::basic_string, I don't deal with memory directly), so I can't help much. It's either an environment issue, or a bug in libc.

Are you sure it's the same libc that you compiled SFML with? Usually this kind of problem happens on OS X, but it may happen on Linux as well.

[pdinklag]

Just fyi, I "fixed" this by using std::string("") instead of sf::String("").

I still have no idea what caused it, and I agree that it's unlikely to be a bug in sf::String after having looked at the code. It might be an issue with basic_string in a particular glibc version, but I have not compared the versions yet.

If nobody else has this issue, I guess it's all fine.

[Laurent]

This confirms my first thought: you're probably mixing two different libc.

When you use a sf::String, it's SFML (and the libc it was compiled with) that allocates the internal std::string. But since the destructor is inlined, the string is destroyed in your code, with your own libc. When you directly construct the std::string, both construction and destruction happen in the same context, with the same libc.

Have you tried to recompile SFML?

[pdinklag]

Good thing that there's a hint now!

Though, I do compile both SFML and JSFML on the same system. I would not know why the libc version should change between the two build processes.

The only thing I could imagine is that the Java Virtual Machine itself was built with a different libc. In that case, I am probably mightless, unless I downgrade to that version (if I can even find out which it has been compiled with).

EDIT:
Then again, if the destructor is inlined, the JVM's libc version should not really matter, since the function executed is still in my module.