Re: Just leaking
Posted by Sven Gothel on
URL: https://forum.jogamp.org/Just-leaking-tp4025132p4025133.html
On 06/03/2012 01:43 PM, apoy2k [via jogamp] wrote:
> I'm using the latest jogamp along with the forked version of Java3D from
> hharrison <https://github.com/hharrison/java3d-core> and keep getting these
> errors whenever my program loads up.
>
> The program works fine and everything, I just wonder where the errors are
> coming from and that eventually it will have an impact on my applications.
>
> 3D [dev] 1.6.0-pre1-daily-experimental daily
>
> 2012-05-31 11:04:21.345 java[16845:11d03] *** __NSAutoreleaseNoPool(): Object 0x100112c60 of class NSCFNumber autoreleased with no pool in place - just leaking
> 2012-05-31 11:04:21.346 java[16845:11d03] *** __NSAutoreleaseNoPool(): Object 0x10013ef60 of class NSConcreteValue autoreleased with no pool in place - just leaking
> 2012-05-31 11:04:21.347 java[16845:11d03] *** __NSAutoreleaseNoPool(): Object 0x108500b40 of class NSCFNumber autoreleased with no pool in place - just leaking
> ...
>
>
> The developer said
> <https://github.com/hharrison/java3d-core/issues/3#issuecomment-6082957> it
> will probably come from the OpenGL calls of jogamp, so here I am, asking you
> for any leads :-)While I removed some leaks and SIGVs,
I used the following runtime settings to 'get an idea' of the cause:
"export NSZombieEnabled=YES"
and compile all native libraries w/ debug enabled:
"ant -Dc.compiler.debug=true"
+++
If you can create a precise recipe to reproduce this 'leak'
(incl. GPU; OSX-, Java-, Java3D-, JOGL- and native GL-driver version, ...)
_and_ a small and simple test case, we may be able to reproduce it
and investigate/fix it.
The native OSX autorelease messages above don't give us a clue as they are,
but maybe the NSZombieEnabled flag helps.
+++
For now it seems that NEWT itself is clean and we do lock
the native surface on in JOGL before we lock the GLContext
and allow GL commands to be issued. Then we release 'em in the
reversed order. This usually makes all GL operations safe.
It is true that our JNI code does not wrap the native function call
in an autorelease pool. So if the native GL call (of the driver)
expect us to provide such a pool within the call stack .. such
a message could appear.
+++
Hope it helps.
~Sven
URL: https://forum.jogamp.org/Just-leaking-tp4025132p4025133.html
On 06/03/2012 01:43 PM, apoy2k [via jogamp] wrote:
> I'm using the latest jogamp along with the forked version of Java3D from
> hharrison <https://github.com/hharrison/java3d-core> and keep getting these
> errors whenever my program loads up.
>
> The program works fine and everything, I just wonder where the errors are
> coming from and that eventually it will have an impact on my applications.
>
> 3D [dev] 1.6.0-pre1-daily-experimental daily
>
> 2012-05-31 11:04:21.345 java[16845:11d03] *** __NSAutoreleaseNoPool(): Object 0x100112c60 of class NSCFNumber autoreleased with no pool in place - just leaking
> 2012-05-31 11:04:21.346 java[16845:11d03] *** __NSAutoreleaseNoPool(): Object 0x10013ef60 of class NSConcreteValue autoreleased with no pool in place - just leaking
> 2012-05-31 11:04:21.347 java[16845:11d03] *** __NSAutoreleaseNoPool(): Object 0x108500b40 of class NSCFNumber autoreleased with no pool in place - just leaking
> ...
>
>
> The developer said
> <https://github.com/hharrison/java3d-core/issues/3#issuecomment-6082957> it
> will probably come from the OpenGL calls of jogamp, so here I am, asking you
> for any leads :-)
I used the following runtime settings to 'get an idea' of the cause:
"export NSZombieEnabled=YES"
and compile all native libraries w/ debug enabled:
"ant -Dc.compiler.debug=true"
+++
If you can create a precise recipe to reproduce this 'leak'
(incl. GPU; OSX-, Java-, Java3D-, JOGL- and native GL-driver version, ...)
_and_ a small and simple test case, we may be able to reproduce it
and investigate/fix it.
The native OSX autorelease messages above don't give us a clue as they are,
but maybe the NSZombieEnabled flag helps.
+++
For now it seems that NEWT itself is clean and we do lock
the native surface on in JOGL before we lock the GLContext
and allow GL commands to be issued. Then we release 'em in the
reversed order. This usually makes all GL operations safe.
It is true that our JNI code does not wrap the native function call
in an autorelease pool. So if the native GL call (of the driver)
expect us to provide such a pool within the call stack .. such
a message could appear.
+++
Hope it helps.
~Sven
signature.asc (910 bytes) | Free forum by Nabble | Edit this page |