Even,<br><br>Thanks for the suggestions. I'll be working through them and will try to factor out into a standalone test case if possible.<br><br>Best regards,<br>Brian<br><br><br><div class="gmail_quote">On Thu, Sep 30, 2010 at 6:01 PM, Even Rouault <span dir="ltr"><<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">Brian,<br>
<br>
This is indeed going be difficult to help you in an efficient way without a<br>
testable case...<br>
<br>
First, check that GDAL is configured --with-threads<br>
<br>
Then try the OGRFeature and OGRTestGC test applications that are generated in<br>
swig/java/build/apps<br>
<br>
How ogrinfo and ogr2ogr work on the TIGER data ? (try with valgrind) That<br>
could be a bug in the TIGER driver if it doesn't occur with other format.<br>
<br>
Your errors seem to indicate some native heap memory corruption. Perhaps a bug<br>
in GDAL or the Java bindings, or perhaps a misuse of the API that lead to<br>
that. (There are indeed some ways of causing corruption by misusing the API if<br>
you don't follow the do's / dont do's in the API doc, and potentially other<br>
undocumented ways...)<br>
<br>
The best would really for you to extract the parts where you use OGR API and<br>
try having a minimum app that trigger the issue.<br>
<br>
Best regards,<br>
<br>
Even<br>
<br>
Le jeudi 30 septembre 2010 15:18:48, Brian Kelly a écrit :<br>
<div><div></div><div class="h5">> Hi all,<br>
><br>
> Apologies in advance for not providing a testable case that can be fired<br>
> up. I'm hoping the background info provided and investigation work shown<br>
> below is enough to help trace what the issue is.<br>
><br>
> PROBLEM DEFINITION:<br>
> I work with a custom java application that loads GIS data using GDAL<br>
> (current TRUNK code in use though issue occurs with v1.7.2 also). We can<br>
> load a variety of data types (MapInfo, DGN,etc) with no issues. A problem<br>
> occurs when TIGER data is loaded though - the TIGER data loads and is<br>
> viewable but after a few pans and zooms the JAVA server process crashes.<br>
> This seems to happen when it tries to unload loaded features. Was using US<br>
> Census data tiger files.<br>
><br>
> PROBLEM ANALYSIS:<br>
> Two sources of debug information were looked at. A (1) general log file<br>
> generated by java and (2) a core dump file. The outputs of these are below.<br>
><br>
> 1. LOG NUMBER ONE: The log file generated on crash indicates the source of<br>
> the problem is the GDAL library when features are deleted.<br>
><br>
> Current thread (0x0000000041a4d800): JavaThread<br>
> "FeatureNativeObjectsCleaner" daemon [_thread_in_native, id=28311,<br>
> stack(0x00007ff5f4cc8000,0x00007ff5f4dc9000)]<br>
> siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR),<br>
> si_addr=0x000000000000003a<br>
> Stack: [0x00007ff5f4cc8000,0x00007ff5f4dc9000], sp=0x00007ff5f4dc77a8,<br>
> free space=3fd0000000000000018k<br>
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native<br>
> code)<br>
> C 0x0000000042355af0<br>
> j org.gdal.ogr.FeatureNative.delete()V+23<br>
><br>
> 2. LOG NUMBER TWO: A linux core dump was captured when the JVM crashed.<br>
> This was analysed for more precise details using the GDB debugger using<br>
> the approach outlined at<br>
> <a href="http://www.dialogic.com/support/helpweb/dxall/tn957.aspx" target="_blank">http://www.dialogic.com/support/helpweb/dxall/tn957.aspx</a><br>
><br>
> The output from the core dump file analysis was:<br>
> Loaded symbols for /usr/lib/jvm/jrrt-4.0.1-1.6.0/jre/lib/amd64/libdcpr.so<br>
> Core was generated by `/usr/lib/jvm/java-6-jrockit/bin/java -Xms2048m<br>
> -Xmx2048m -<a href="http://Djava.util.logging.ma" target="_blank">Djava.util.logging.ma</a>'.<br>
> Program terminated with signal 6, Aborted.<br>
> #0 0x00007f51ac719a75 in raise () from /lib/libc.so.6<br>
> (gdb) bt<br>
> #0 0x00007f51ac719a75 in raise () from /lib/libc.so.6<br>
> #1 0x00007f51ac71d5c0 in abort () from /lib/libc.so.6<br>
> #2 0x00007f51ac7534fb in ?? () from /lib/libc.so.6<br>
> #3 0x00007f51ac75d5b6 in ?? () from /lib/libc.so.6<br>
> #4 0x00007f51ac7616d8 in ?? () from /lib/libc.so.6<br>
> #5 0x00007f51ac76258e in malloc () from /lib/libc.so.6<br>
> #6 0x00007f515d06c262 in OGRLineString::exportToWkt (this=0x7f5154722bb0,<br>
> ppszDstText=0x7f5158804728) at ogrlinestring.cpp:1049<br>
> #7 0x00007f515d51655f in OGRGeometryShadow_ExportToWkt__SWIG_1<br>
> (jenv=0x5952bf0,<br>
> jcls=<value optimized out>, jarg1=6, jarg1_=0xffffffffffffffff)<br>
> at ogr_wrap.cpp:1792<br>
> #8 Java_org_gdal_ogr_ogrJNI_Geometry_1ExportToWkt_1_1SWIG_11<br>
> (jenv=0x5952bf0,<br>
> jcls=<value optimized out>, jarg1=6, jarg1_=0xffffffffffffffff)<br>
> at ogr_wrap.cpp:7166<br>
> #9 0x00007f5166de2715 in ?? ()<br>
> #10 0x00000000827520c0 in ?? ()<br>
><br>
><br>
> 1. The core dump file indicates that an exception occurs in the file<br>
> ogrlinestring.cpp at L1049. In the GDAL trunk source code that I have this<br>
> corresponds to the line:<br>
> *ppszDstText = (char *) VSIMalloc( nMaxString );<br>
> 2. The output from Log #1 indicates that there might be an issue with<br>
> memory pointers. This is based on the SEGV_MAPERR error output and the<br>
> opinion on the post here:<br>
> <a href="http://www.linuxquestions.org/questions/programming-9/free-invalid-next-siz" target="_blank">http://www.linuxquestions.org/questions/programming-9/free-invalid-next-siz</a><br>
> e-fast-c-error-729852/<br>
><br>
> It looks like the problem could be a memory pointer size issue related to<br>
> ogrlinestring. If anyone could take a quick look and suggest a fix that<br>
> would be appreciated. I'm a java programmer lost in a C++ world on this<br>
> one.<br>
><br>
> Thanks,<br>
> Brian<br>
</div></div></blockquote></div><br>