[gdal-dev] JVM crash on making a call to the class/method OGRLineString::exportToWkt

[Brian Kelly]

Even,

Thanks for the suggestions. I'll be working through them and will try to
factor out into a standalone test case if possible.

Best regards,
Brian


On Thu, Sep 30, 2010 at 6:01 PM, Even Rouault
<even.rouault at mines-paris.org>wrote:

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