ogr library on osx

53 views
Skip to first unread message

Justin Deoliveira

unread,
Apr 19, 2012, 11:13:27 AM4/19/12
to nativel...@googlegroups.com
Hi all,

I am attempting to utilize some recent work of Andrea for interacting with the gdal/ogr libraries via bridj. Unfortunately I am having little success with it on OSX. As far as I can tell the library is loaded fine but the first call to it results in:

Invalid memory access of location 0x4be498dc eip=0x384f3f

My question is how i can get some more useful information. I have tried re-running jnearator with verbose settings but haven't been able to yield anything useful out of that. I have also tried using gdb to get a backtrace of where the segfault occurs, and that yields the following:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x4c6498dc
0x00384f3f in JVM_Lseek ()
(gdb) where
#0  0x00384f3f in JVM_Lseek ()
#1  0x0038f7e8 in JVM_Lseek ()
#2  0x003a78f0 in JVM_MonitorWait ()
#3  0x003a786d in JVM_MonitorWait ()
#4  0x0ff8adca in Java_org_bridj_JNI_getLibrarySymbols ()

Not sure if that is terribly useful either.

I have read some reports of similar issues running under 64 bit. So i tried to recompile the ogr library for 32 bit and started the jvm with -d32 but it yields the same result.

Anyways, I guess i am looking for some general pointers for some strategies that i might be able to employ to figure out where the issues might lie.

Thanks!

-Justin
 

Andrea Aime

unread,
Apr 24, 2012, 11:14:34 AM4/24/12
to nativel...@googlegroups.com
I don't have a OSX installation to try this out, but I guess what Justin was asking is more on the lines
of "is OSX somehow different jnaerator/bridj wise"? Any particular build flag required for the natives
to be usable?

Cheers
Andrea
 
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead

Via Poggio alle Viti 1187
55054  Massarosa (LU)
Italy

phone: +39 0584 962313
fax:      +39 0584 962313
mob:    +39 339 8844549

http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf

-------------------------------------------------------

Justin Deoliveira

unread,
Apr 24, 2012, 11:29:50 AM4/24/12
to nativel...@googlegroups.com
Sort of. But that is a good question, although the docs don't seem to illustrate anything special about osx. '

In general i was asking for a strategy to get more information than just the report that a segfault occurred. I thought about perhaps recompiling the bridj native components with debug information to try and get a better stack trace but not sure if that will even help. 
--
Justin Deoliveira
Enterprise support for open source geospatial.

Olivier Chafik

unread,
Apr 25, 2012, 3:25:34 AM4/25/12
to nativel...@googlegroups.com
Hi Justin,

Sorry for the late reply !

This issue would seem to indicate a bug in BridJ's symbol enumeration code (actually inside dyncall), which would most certainly be my bad :


To help further diagnose the issue, you can indeed rebuild BridJ's native library with DEBUG=1, as described here : 


Also, you should have a look at the exact compiler + linker flags used to build your library and compare them to those used by BridJ to build, say, its test library (which is also a universal binary) :


(Ideally you should try and remove suspicious linker flags to see if they trigger the bug)

Finally, if you can share your binary with the community, please file an issue with it and I'll be happy to investigate the issue and fix it asap :-) (please also mention the exact version of XCode / gcc you're using)


Cheers
2012/4/24 Justin Deoliveira <jdeo...@opengeo.org>

Justin Deoliveira

unread,
Apr 26, 2012, 9:00:56 AM4/26/12
to nativel...@googlegroups.com
Hi Olivier,

Thanks a lot for the info. So as it turns out when I build bridj locally it works! Although oddly enough i also can't reproduce the original error when i revert back to the original version of bridj which is confusing. I have done a couple of rebuilds of the original library which might be part of it. Anyways, I will continue to play around and file an issue if i find something concrete, but your info gives me a lot to work with.

I also ran into some minor hitches during the bridj build (building a9a43d915 from master):

1. OpenCL modules didn't build for me... some compiler errors:

[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] /Users/jdeolive/Projects/bridj/git/libraries/OpenCL/Core/src/test/java/com/nativelibs4java/opencl/JOGLTest.java:[7,29] package com.jogamp.opengl.util does not exist

I guess i miss the jogl opengl bindings? Do those have to be built manually before hand?

2. Small typo regarding the dyncall patch. The docs refere to dyncall.patch but the file appears to be named dyncall.diff instead.

Thanks for the great work. Quite an impressive project!

-Justin

Olivier Chafik

unread,
Apr 26, 2012, 2:50:41 PM4/26/12
to nativel...@googlegroups.com
Hi Justin,

2012/4/26 Justin Deoliveira <jdeo...@opengeo.org>

Thanks a lot for the info. So as it turns out when I build bridj locally it works!

Hehe, what's your exact OS & GCC version ? (BridJ's Mac binaries are built on OSX 10.7.3 with GCC 4.2)
 
Although oddly enough i also can't reproduce the original error when i revert back to the original version of bridj which is confusing. I have done a couple of rebuilds of the original library which might be part of it.

Well, it's half a good news then :-) (my 2 cents : make sure you're using version 0.6.1 in your Maven dependencies, or that you clear your local Maven repo in ~/.m2/repository/com/nativelibs4java/bridj )
 
I also ran into some minor hitches during the bridj build (building a9a43d915 from master):

1. OpenCL modules didn't build for me... some compiler errors:
[...] 
package com.jogamp.opengl.util does not exist

I guess i miss the jogl opengl bindings? Do those have to be built manually before hand?

Oops, I forgot to mention that to build NativeLibs4Java (which includes JavaCL) you need to install JOGL, as explained on JavaCL's wiki... More below.

2. Small typo regarding the dyncall patch. The docs refere to dyncall.patch but the file appears to be named dyncall.diff instead.

Thanks a lot for the feedback, I've fixed that typo and updated the build instructions with a link to the "Install JOGL" section of JavaCL's wiki :


Thanks for the great work. Quite an impressive project!

Thank you very much !

(amazing what you can do with kind, motivated users and passionate contributors !)

Cheers
-- 

Justin Deoliveira

unread,
Apr 26, 2012, 9:11:27 PM4/26/12
to nativel...@googlegroups.com
Hey Olivier,

Thanks again for the info and great support!

On Thu, Apr 26, 2012 at 2:50 PM, Olivier Chafik <olivier...@gmail.com> wrote:
Hi Justin,

2012/4/26 Justin Deoliveira <jdeo...@opengeo.org>
Thanks a lot for the info. So as it turns out when I build bridj locally it works!

Hehe, what's your exact OS & GCC version ? (BridJ's Mac binaries are built on OSX 10.7.3 with GCC 4.2)

gcc is version 4.2.1. 
osx version 10.6.8. Kernel version is 10.8.0.


 
Although oddly enough i also can't reproduce the original error when i revert back to the original version of bridj which is confusing. I have done a couple of rebuilds of the original library which might be part of it.

Well, it's half a good news then :-) (my 2 cents : make sure you're using version 0.6.1 in your Maven dependencies, or that you clear your local Maven repo in ~/.m2/repository/com/nativelibs4java/bridj )

Right, i think i did this correctly. First version was 0.6. After bulding locally i changed it to 0.6.2-SNAPSHOT, then tried again back at 0.6. 
 
I also ran into some minor hitches during the bridj build (building a9a43d915 from master):

1. OpenCL modules didn't build for me... some compiler errors:
[...] 
package com.jogamp.opengl.util does not exist

I guess i miss the jogl opengl bindings? Do those have to be built manually before hand?

Oops, I forgot to mention that to build NativeLibs4Java (which includes JavaCL) you need to install JOGL, as explained on JavaCL's wiki... More below.

2. Small typo regarding the dyncall patch. The docs refere to dyncall.patch but the file appears to be named dyncall.diff instead.

Thanks a lot for the feedback, I've fixed that typo and updated the build instructions with a link to the "Install JOGL" section of JavaCL's wiki :


Thanks for the great work. Quite an impressive project!

Ahh cool. Thanks. 

Thank you very much !

(amazing what you can do with kind, motivated users and passionate contributors !)

Cheers
-- 
Reply all
Reply to author
Forward
0 new messages