Re: jni with Guard Malloc
Re: jni with Guard Malloc
- Subject: Re: jni with Guard Malloc
- From: Dave Payne <email@hidden>
- Date: Fri, 10 Sep 2004 23:39:05 -0700
On Sep 10, 2004, at 10:02 PM, email@hidden wrote:
From: Frank Rimlinger <email@hidden>
When attempting to debug my C++ program with Guard Malloc, I keep
hitting this error
/usr/lib/libSystem.B.dylib(copysign.o) definition of _copysign
/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/Libraries/
libjava.jnilib(single module) definition of _copysign
Program received signal: "SIGTRAP".
This error does not occur when Guard Malloc is not on.
...
I suppose there is something called _copysign that is multiply defined,
but I only include the stock frameworks JavaVM.framework and
libstdc++.a. And why should Guard Malloc care one way or the other as
this is not a memory thing. Is there a way around this problem so that
I can debug a C++ program that makes jni calls with Guard Malloc?
Hi Frank, Guard Malloc requires the use of "flat namespace" for
looking up symbols, because of how it overrides the malloc() family of
calls from libSystem. Any application that requires two-level
namespace won't work with Guard Malloc due to this current limitation.
When running with Guard Malloc, the DYLD_FORCE_FLAT_NAMESPACE
environment variable must be set before launching your app; Xcode sets
that automatically if you use Debug --> Enable Guard Malloc. See 'man
dyld' for more info on this environment variable.
All applications on the system get libSystem.dylib pulled in
automatically. Unfortunately, it looks like the JavaVM's
libjava.jnilib exports a symbol of the same name (copysign) as
libSystem, thus requiring Java apps to need two-level namespace. (If
an app needs to include two different modules with symbols of the same
name, it needs two-level namespace.) I don't know what that copysign
symbol does in libjava.jnilib.
I would suggest filing a bug against the Java component giving your
observations.
Meanwhile, if most of your app is a C++ app, would it be possible to
work around this problem by stubbing out your jni call with a C-based
implementation that just returns canned data, and not linking with the
JavaVM.framework? Just a thought...
- Dave
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.