jogamp › jogl

JOGL 2.3.1 on armv6hf

Classic

List

Threaded

15 messages Options

Xenosb

JOGL 2.3.1 on armv6hf

Hi,

we have problem deploying our application on Nvidia Tegra TK1 (armv6hf) embedded board.
We are using latest jar files from download page and libraries seem to be broken. Error displayed when trying to launch the application is

Error in java: free(): corrupted unsorted chunks

Since we have successfully deployed one application on the same hardware in august we pulled that jogl and gluegen libraries and modified application to work with them. This was success but we lack features like labels and we had to organize imports (javax instead of jogamp).
We have also tried building libraries from the git source and the build failed with malloc@GLIBC_2.4 error. With the help of forum we have solved geluegen build but this error still occurs during the jogamp.all build. Could you please check is Jenkins reporting some build errors when building armv6hf binaries and do you have some explanations for free() corrupted unsorted chunks error?

With regards,
Bruno

Xerxes Rånby

Re: JOGL 2.3.1 on armv6hf

This post was updated on .

I recommend that you download the 2.3.1 release unpack it and generate a "runtime version check" and a "runtime debug test" log

http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases#Runtime_Version_Check
http://jogamp.org/wiki/index.php/Jogamp_Versioning_and_Releases#Runtime_Debug_Logs

like this:

wget http://jogamp.org/deployment/jogamp-current/archive/jogamp-all-platforms.7z
7z x jogamp-all-platforms.7z
cd jogamp-all-platforms
sh etc/test.sh
sh etc/test_dbg.sh

and send us the generated test.log and test_dbg.log

It is likely "i am guessing" that you have both the properitary nvidia tegra drivers and free-software mesa3d drivers installed on the same system.

The armv6hf librarys are known to work on many kinds of armhf systems when then are used in combination with correctly installed opengl es drivers.

Xerxes Rånby

Re: JOGL 2.3.1 on armv6hf

This post was updated on .

In reply to this post by Xenosb

We have seen crashes with "Error in java: free(): corrupted unsorted chunks" if mesa3d failed to initialize the GPU. https://jogamp.org/bugzilla/show_bug.cgi?id=1166

Please try if you can use the workaround to disable glx in your xorg.conf, that will prevent jogamp from using libGL (mesa3d) http://forum.jogamp.org/JOGL-on-ODROID-XU3-Lite-tp4034217p4034222.html

you can also try to use jogl-all-mobile.jar instead of jogl-all.jar that will as well skip using libGL and go directly to use libEGL.

gouessej

Re: JOGL 2.3.1 on armv6hf

Administrator

In reply to this post by Xenosb

Xenosb wrote

This was success but we lack features like labels and we had to organize imports (javax instead of jogamp).

You have to adapt your code to the new package names, we no longer use javax.media.*.

Julien Gouesse | Personal blog | Website

asambol

Re: JOGL 2.3.1 on armv6hf

gouessej wrote

You have to adapt your code to the new package names, we no longer use javax.media.*.

We refactored everything to use com.jogamp.* instead of javax.media.* in our new application which uses Jogl 2.3.1 and it works fine on Windows, the problem is it doesn't work on TK1 so we had to revert everything to a version we had half a year ago (which has a completely different Graph API) to run on TK1.

Right now we are running the app on TK1 (for presentation purposes) using old Jogl that works, but without some features like Graph Fonts from new Jogl. In about a week we can try Xerxes' recommendations and will then post the logs.

It is strange, if it's a driver issue, that it works fine with older Jogl but not with 2.3.1.

Xenosb

Re: JOGL 2.3.1 on armv6hf

In reply to this post by Xerxes Rånby

As asambol said, we'll try Xerxes solution after this presentation.

Since I checked the forum before asking a question, I have tried disabling glx in xorg.conf and it didn't work. X11 wouldn't show anything on screen with glx disabled in modules. It possible that jogamp is trying to use mesa instead of nvida.

Xerxes Rånby

Re: JOGL 2.3.1 on armv6hf

This post was updated on .

In reply to this post by Xenosb

I have identified what caused the heap corruption during GLX initialization on ARM 32 and created a patch for gluegen that you can try.
https://jogamp.org/bugzilla/show_bug.cgi?id=1166#c10

with the patch applied hardware acceleration is supported using OpenGL ES 1 & 2 using the nvidia driver and OpenGL 2 will be supported using software emulation using mesa3D, jogl will try use the most hardware accelerated driver available depending on the opengl profile your application requests.

asambol

Re: JOGL 2.3.1 on armv6hf

Thanks! Currently we do not have TK1 at our offices, will try the new patch as soon as we can.

gouessej

Re: JOGL 2.3.1 on armv6hf

Administrator

In reply to this post by Xerxes Rånby

Good job. I like the solution "C" because there is no support of capacity expressed with a long in the current Java SE API and under Android. However, the maximum capacity is Integer.MAX_VALUE, i.e 2 GiB.

Julien Gouesse | Personal blog | Website

Xerxes Rånby

Re: JOGL 2.3.1 on armv6hf

gouessej wrote

Good job. I like the solution "C" because there is no support of capacity expressed with a long in the current Java SE API and under Android. However, the maximum capacity is Integer.MAX_VALUE, i.e 2 GiB.

Yes it is a misfortunate API decision in java to use signed ints, it limits the max capacity of Direct ByteBuffer's to 2GB.
There has been filed enhancement bugs since 2001 to fix it
https://bugs.openjdk.java.net/browse/JDK-4496703 - (bf) Buffer classes limited by 32-bit addressing
but it has been ignored.

While investigating i found that there exist one alternative way to create a direct ByteBuffers using the MappedByteBuffer class. MappedByteBuffer is using mmap internally thus it should not have any size limitation. Unfortunally the implementation of MappedByteBuffer has added a fictive limitation of 2Gb here as well.
https://bugs.openjdk.java.net/browse/JDK-6347833 - (fs) Enhance MappedByteBuffer to support sizes >2GB on 64 bit platforms.

I hope these two bugs will be worked and fixed before i grow a white beard.

gouessej

Re: JOGL 2.3.1 on armv6hf

Administrator

Xerxes Rånby wrote

I hope these two bugs will be worked and fixed before i grow a white beard.

Actually, it's a very difficult task. The NIO buffers work with arrays, the indirect ones are mapped by arrays whose size is stored in an integer. A complete revamp of its API requires a support of bigger arrays too. Moreover, what should happen on 32-bit systems?

Julien Gouesse | Personal blog | Website

Sven Gothel

Re: JOGL 2.3.1 on armv6hf

Administrator

In reply to this post by Xerxes Rånby

On 07/09/2015 05:03 PM, Xerxes Rånby [via jogamp] wrote:

> gouessej wrote
> Good job. I like the solution "C" because there is no support of capacity
> expressed with a long in the current Java SE API and under Android.
> However, the maximum capacity is Integer.MAX_VALUE, i.e 2 GiB
> <https://en.wikipedia.org/wiki/Gibibyte>.
>
> Yes it is a misfortunate API decision in java to use signed ints, it limits
> the max capacity of Direct ByteBuffer's to 2GB.
> There has been filed enhancement bugs since 2001 to fix it
> https://bugs.openjdk.java.net/browse/JDK-4496703 - (bf) Buffer classes limited
> by 32-bit addressing
> but it has been ignored.
>
> While investigating i found that there exist one alternative way to create a
> direct ByteBuffers using the MappedByteBuffer class. MappedByteBuffer is using
> mmap internally thus it should not have any size limitation. Unfortunally the
> implementation of MappedByteBuffer has added a fictive limitation of 2Gb here
> as well.
> https://bugs.openjdk.java.net/browse/JDK-6347833 - (fs) Enhance
> MappedByteBuffer to support sizes >2GB on 64 bit platforms.

GlueGen supports mapped buffers > 2GiB
via slicing, see:

MappedByteBufferInputStream

<http://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/com/jogamp/common/nio/MappedByteBufferInputStream.html>

MappedByteBufferOutputStream
<http://jogamp.org/deployment/jogamp-next/javadoc/gluegen/javadoc/com/jogamp/common/nio/MappedByteBufferOutputStream.html>

~Sven

signature.asc (828 bytes) Download Attachment

gouessej

Re: JOGL 2.3.1 on armv6hf

Administrator

Yes I remember those classes :) Actually, this is typically what is suggested in some comments, using several buffers for a single file.

Julien Gouesse | Personal blog | Website

Xerxes Rånby

Re: JOGL 2.3.1 on armv6hf

In reply to this post by asambol

asambol wrote

Thanks! Currently we do not have TK1 at our offices, will try the new patch as soon as we can.

Please try the RC Test Build 2.3.2-rc-20150716
http://jogamp.org/deployment/archive/master/gluegen_868-joal_596-jogl_1401-jocl_1057-signed/
http://forum.jogamp.org/RC-Test-Build-2-3-2-rc-20150716-td4034915.html

It is expected to fix your issue.

Xenosb

JOGL 2.3.1 on armv6hf

Thanks for fixing the bug.

We have finally received our Jetson back so we deployed jogl 596 build and tested. Everything works as it should. Thank you for the effort and support!