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 <[email protected]>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 >
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
