libspatialite-2.dll Crashes JavaVM

[Toomy]

Hi
I'm currently facing a crash in the JavaVM that is cause by
libspatialite-2.dll

Does anybody know something about this?
We use libspatialite-2 with the sqlite-jdbc-3.7.2.jar jdbc driver.

Thanks

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x618692f5, pid=9980,
tid=4204
#
# JRE version: 6.0_27-b07
# Java VM: Java HotSpot(TM) Server VM (20.2-b06 mixed mode windows-
x86 )
# Problematic frame:
# C [libspatialite-2.dll+0x692f5]
#
# An error report file with more information is saved as:
# R:\\hs_err_pid9980.log
#
# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

[Brad Hards]

On Friday 10 February 2012 23:42:02 Toomy wrote:
> Hi
> I'm currently facing a crash in the JavaVM that is cause by
> libspatialite-2.dll
>
> Does anybody know something about this?
> We use libspatialite-2 with the sqlite-jdbc-3.7.2.jar jdbc driver.

I don't do Java, but I don't anticipate seeing this fixed without some way to
reproduce it. It may alos know which version of libspatialite you are using.

Can you provide a small / minimal, runnable example that shows the problem?

Brad

[Pepijn Van Eeckhoudt]

Could you post the hotspot dump file as well (hs_err_pid... file)? That should contain the entire stack trace which might point in the right direction.

Pepijn

> --
> You received this message because you are subscribed to the Google Groups "SpatiaLite Users" group.
> To post to this group, send email to spatiali...@googlegroups.com.
> To unsubscribe from this group, send email to spatialite-use...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/spatialite-users?hl=en.
>

[Toomy]

Hi,
Thanks for your participation. Unfortunately I don't have the data
that could reproduce this problem. It crashes everytime during data
import but not everytime at the same data. This means when I resume
from the data import from the last successful commit, It runs to the
next crash. After two attempts the data is processed. I don't expect
that the problem is related to a particular data value.

Here is the hotspot dump file ( I have shortened it a bit )

#
# A fatal error has been detected by the Java Runtime Environment:
#
# EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x618692f5, pid=9980,
tid=4204
#
# JRE version: 6.0_27-b07
# Java VM: Java HotSpot(TM) Server VM (20.2-b06 mixed mode windows-
x86 )
# Problematic frame:
# C [libspatialite-2.dll+0x692f5]
#

# If you would like to submit a bug report, please visit:
# http://java.sun.com/webapps/bugreport/crash.jsp
# The crash happened outside the Java Virtual Machine in native code.
# See problematic frame for where to report the bug.
#

--------------- T H R E A D ---------------

Current thread (0x089bcc00): JavaThread "pool-150-
thread-1" [_thread_in_native, id=4204, stack(0x596e0000,0x59730000)]

siginfo: ExceptionCode=0xc0000005, writing address 0x00000000

Registers:
EAX=0x63d54580, EBX=0x63613c08, ECX=0x00000000, EDX=0x00000000
ESP=0x5972f3e8, EBP=0x5972f3e8, ESI=0x06a4b028, EDI=0x06a66e88
EIP=0x618692f5, EFLAGS=0x00010202

Top of Stack: (sp=0x5972f3e8)
0x5972f3e8: 5972f428 618694a9 60b97f08 63d54580
0x5972f3f8: 00000000 00000030 60b97f08 00000058
0x5972f408: 5972f428 613864e8 61402214 63f45fe0
0x5972f418: 10defca9 0001e755 0000a532 00014172
0x5972f428: 5972f458 6186b17e 62f1b100 61fc4580
0x5972f438: 61def980 5972f454 06a260b0 63613c08
0x5972f448: 5972f458 61def980 06a4b140 00000000
0x5972f458: 5972f488 6186cb1e 06a260b0 06a5b308

Instructions: (pc=0x618692f5)
0x618692d5: 24 e8 7d 55 22 00 c9 c3 55 89 e5 8b 55 08 8b 45
0x618692e5: 08 8b 40 08 8d 0c 85 00 00 00 00 8b 12 8b 45 0c
0x618692f5: 89 04 11 8b 45 08 ff 40 08 5d c3 55 89 e5 56 53
0x61869305: 83 ec 18 dd 05 40 80 a9 61 dd 5d e8 8b 45 08 8b


Register to memory mapping:

EAX=0x63d54580 is an unknown value
EBX=0x63613c08 is an unknown value
ECX=0x00000000 is an unknown value
EDX=0x00000000 is an unknown value
ESP=0x5972f3e8 is pointing into the stack for thread: 0x089bcc00
EBP=0x5972f3e8 is pointing into the stack for thread: 0x089bcc00
ESI=0x06a4b028 is an unknown value
EDI=0x06a66e88 is an unknown value


Stack: [0x596e0000,0x59730000], sp=0x5972f3e8, free space=316k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [libspatialite-2.dll+0x692f5]
C [libspatialite-2.dll+0x694a9]
C [libspatialite-2.dll+0x6b17e]
C [libspatialite-2.dll+0x6cb1e]
C [sqlite-3.7.2-sqlitejdbc.dll+0x2b4fb]
C [sqlite-3.7.2-sqlitejdbc.dll+0x239b2]
C [sqlite-3.7.2-sqlitejdbc.dll+0x23aee]
C [sqlite-3.7.2-sqlitejdbc.dll+0x217f]
J org.sqlite.NativeDB.step(J)I

Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
J org.sqlite.NativeDB.step(J)I
J org.sqlite.DB.execute(Lorg/sqlite/Stmt;[Ljava/lang/Object;)Z
J org.sqlite.PrepStmt.executeQuery()Ljava/sql/ResultSet;
J
mhcc.app.geoservice.app.internal.routing.strategies.AbstractRoutingStrategy.route(Lmhcc/
app/geoservice/app/internal/routing/MapMatchResult;Lmhcc/app/
geoservice/app/internal/routing/MapMatchResult;)Lmhcc/app/geoservice/
app/internal/routing/RoutingSolution;
J
mhcc.app.geoservice.app.internal.routing.strategies.AbstractRoutingStrategy.findNextSolutions(Ljava/
util/ArrayList;IILjava/util/ArrayList;)Ljava/util/ArrayList;
J
mhcc.app.geoservice.app.internal.routing.strategies.AbstractRoutingStrategy.route([Lmhcc/
app/gis/model/dstructs/IPointShared;)[Lmhcc/app/gis/model/dstructs/
ILinestringShared;
j
mhcc.app.geoservice.app.internal.routing.RoutingServiceImpl.route([Lmhcc/
app/gis/model/dstructs/IPointShared;Lmhcc/app/core/dtypes/
OperationalBranchTypeEnum;)[Lmhcc/app/gis/model/dstructs/
ILinestringShared;+85
J
mhcc.app.geoservice.app.internal.routegeometry.CalculateRouteGeometryJob.run()V
j java.util.concurrent.Executors$RunnableAdapter.call()Ljava/lang/
Object;+4
j java.util.concurrent.FutureTask$Sync.innerRun()V+30
j java.util.concurrent.FutureTask.run()V+4
j java.util.concurrent.ScheduledThreadPoolExecutor
$ScheduledFutureTask.access$301(Ljava/util/concurrent/
ScheduledThreadPoolExecutor$ScheduledFutureTask;)V+1
j java.util.concurrent.ScheduledThreadPoolExecutor
$ScheduledFutureTask.run()V+15
J java.util.concurrent.ThreadPoolExecutor$Worker.run()V
j java.lang.Thread.run()V+11
v ~StubRoutines::call_stub

--------------- P R O C E S S ---------------

Java Threads: ( => current thread )

... snip

=>0x089bcc00 JavaThread "pool-150-thread-1" [_thread_in_native,
id=4204, stack(0x596e0000,0x59730000)]

... snip

Other Threads:
0x027d6800 VMThread [stack: 0x06270000,0x062c0000] [id=3276]
0x061ae800 WatcherThread [stack: 0x075d0000,0x07620000] [id=7892]

VM state:not at safepoint (normal execution)

VM Mutex/Monitor currently owned by a thread: None

Heap
PSYoungGen total 215296K, used 24795K [0x38070000, 0x48070000,
0x48070000)
eden space 179712K, 13% used [0x38070000,0x398a6f88,0x42ff0000)
from space 35584K, 0% used [0x42ff0000,0x42ff0000,0x452b0000)
to space 43456K, 0% used [0x45600000,0x45600000,0x48070000)
PSOldGen total 524288K, used 524287K [0x18070000, 0x38070000,
0x38070000)
object space 524288K, 99% used [0x18070000,0x3806fff8,0x38070000)
PSPermGen total 60032K, used 59749K [0x10070000, 0x13b10000,
0x18070000)
object space 60032K, 99% used [0x10070000,0x13ac9760,0x13b10000)

Code Cache [0x027e0000, 0x034b8000, 0x057e0000)
total_blobs=4172 nmethods=3952 adapters=173 free_code_cache=37039424
largest_free_block=62592

Dynamic libraries:
0x00400000 - 0x00424000 R:\MHDevEnv\tools\jdk1.6.0_27\bin\javaw.exe
0x77980000 - 0x77b00000 C:\Windows\SysWOW64\ntdll.dll
0x76a10000 - 0x76b20000 C:\Windows\syswow64\kernel32.dll
0x765d0000 - 0x76616000 C:\Windows\syswow64\KERNELBASE.dll
0x76b20000 - 0x76bc0000 C:\Windows\syswow64\ADVAPI32.dll
0x75150000 - 0x751fc000 C:\Windows\syswow64\msvcrt.dll
0x76240000 - 0x76259000 C:\Windows\SysWOW64\sechost.dll
0x76d40000 - 0x76e30000 C:\Windows\syswow64\RPCRT4.dll
0x75060000 - 0x750c0000 C:\Windows\syswow64\SspiCli.dll
0x75050000 - 0x7505c000 C:\Windows\syswow64\CRYPTBASE.dll
0x76140000 - 0x76240000 C:\Windows\syswow64\USER32.dll
0x750c0000 - 0x75150000 C:\Windows\syswow64\GDI32.dll
0x76f10000 - 0x76f1a000 C:\Windows\syswow64\LPK.dll
0x766b0000 - 0x7674d000 C:\Windows\syswow64\USP10.dll
0x76bc0000 - 0x76c20000 C:\Windows\system32\IMM32.DLL
0x76780000 - 0x7684c000 C:\Windows\syswow64\MSCTF.dll
0x10000000 - 0x10067000 C:\Program Files (x86)\ThreatFire\TfWah.dll
0x763d0000 - 0x76405000 C:\Windows\syswow64\WS2_32.dll
0x768e0000 - 0x768e6000 C:\Windows\syswow64\NSI.dll
0x754f0000 - 0x7613a000 C:\Windows\syswow64\SHELL32.dll
0x76eb0000 - 0x76f07000 C:\Windows\syswow64\SHLWAPI.dll
0x76270000 - 0x763cc000 C:\Windows\syswow64\ole32.dll
0x76620000 - 0x766af000 C:\Windows\syswow64\OLEAUT32.dll
0x7c340000 - 0x7c396000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin
\msvcr71.dll
0x6db70000 - 0x6dfc8000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin\server
\jvm.dll
0x74490000 - 0x744c2000 C:\Windows\system32\WINMM.dll
0x74510000 - 0x7455c000 C:\Windows\system32\apphelp.dll
0x6d850000 - 0x6d85c000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin
\verify.dll
0x6d3d0000 - 0x6d3ef000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin
\java.dll
0x6d890000 - 0x6d89f000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin\zip.dll
0x6d600000 - 0x6d609000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin
\management.dll
0x6d6b0000 - 0x6d6c3000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin\net.dll
0x74700000 - 0x7473c000 C:\Windows\system32\mswsock.dll
0x74390000 - 0x74396000 C:\Windows\System32\wship6.dll
0x74780000 - 0x74790000 C:\Windows\system32\NLAapi.dll
0x74770000 - 0x74780000 C:\Windows\system32\napinsp.dll
0x74750000 - 0x74762000 C:\Windows\system32\pnrpnsp.dll
0x74740000 - 0x7474d000 C:\Windows\system32\wshbth.dll
0x746b0000 - 0x746f4000 C:\Windows\system32\DNSAPI.dll
0x746a0000 - 0x746a8000 C:\Windows\System32\winrnr.dll
0x74560000 - 0x74565000 C:\Windows\System32\wshtcpip.dll
0x06bb0000 - 0x06bcc000 C:\Windows\system32\IPHLPAPI.DLL
0x72d70000 - 0x72d77000 C:\Windows\system32\WINNSI.DLL
0x06b10000 - 0x06b16000 C:\Windows\system32\rasadhlp.dll
0x06bd0000 - 0x06c08000 C:\Windows\System32\fwpuclnt.dll
0x72dc0000 - 0x72dd6000 C:\Windows\system32\CRYPTSP.dll
0x72d80000 - 0x72dbb000 C:\Windows\system32\rsaenh.dll
0x744e0000 - 0x744f7000 C:\Windows\system32\USERENV.dll
0x744d0000 - 0x744db000 C:\Windows\system32\profapi.dll
0x6d6d0000 - 0x6d6d9000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin\nio.dll
0x72bc0000 - 0x72bcf000 R:\MHDevEnv\workplaces\wp-server\.metadata
\.plugins\org.eclipse.pde.core\mhcc.cci.container.01.ide.product
\org.eclipse.osgi\bundles\185\1\.cp\jWinHttp-1.0.0.dll
0x74080000 - 0x740d8000 C:\Windows\system32\WINHTTP.dll
0x73f80000 - 0x73fcf000 C:\Windows\system32\webio.dll
0x72b50000 - 0x72b5d000 C:\Windows\system32\dhcpcsvc6.DLL
0x72d50000 - 0x72d62000 C:\Windows\system32\dhcpcsvc.DLL
0x6d0b0000 - 0x6d1fc000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin\awt.dll
0x74f20000 - 0x74f71000 C:\Windows\system32\WINSPOOL.DRV
0x4d590000 - 0x4d72e000 C:\Windows\WinSxS
\x86_microsoft.windows.common-
controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\COMCTL32.dll
0x6d830000 - 0x6d838000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin
\sunmscapi.dll
0x76f50000 - 0x7706d000 C:\Windows\syswow64\CRYPT32.dll
0x75230000 - 0x7523c000 C:\Windows\syswow64\MSASN1.dll
0x06dd0000 - 0x06ddb000 R:\MHDevEnv\tools\jdk1.6.0_07\jre\bin
\clib_jiio_util.dll
0x5dd90000 - 0x5de9c000 R:\MHDevEnv\tools\jdk1.6.0_07\jre\bin
\clib_jiio_sse2.dll
0x72f30000 - 0x72f43000 C:\Windows\system32\DWMAPI.DLL
0x539a0000 - 0x53a20000 C:\Windows\system32\uxtheme.dll
0x6d2e0000 - 0x6d32f000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin
\fontmanager.dll
0x70370000 - 0x70533000 C:\Windows\system32\d3d9.dll
0x74f80000 - 0x74f89000 C:\Windows\system32\VERSION.dll
0x0dcb0000 - 0x0dcb6000 C:\Windows\system32\d3d8thk.dll
0x65770000 - 0x6641c000 C:\Windows\system32\nvd3dum.dll
0x73c50000 - 0x73c75000 C:\Windows\system32\powrprof.dll
0x75240000 - 0x753dd000 C:\Windows\syswow64\SETUPAPI.dll
0x76f20000 - 0x76f47000 C:\Windows\syswow64\CFGMGR32.dll
0x754d0000 - 0x754e2000 C:\Windows\syswow64\DEVOBJ.dll
0x6d220000 - 0x6d24f000 R:\MHDevEnv\tools\jdk1.6.0_27\jre\bin\cmm.dll
0x68080000 - 0x68174000 R:\temp\libiconv2.dll
0x6a200000 - 0x6a385000 R:\temp\libgeos-3-1-1.dll
0x68280000 - 0x68423000 R:\temp\libgeos-3-2-2.dll
0x70040000 - 0x700a8000 R:\temp\libgeos_c-1.dll
0x64c40000 - 0x64cd2000 R:\temp\libproj-0.dll
0x61380000 - 0x61409000 R:\temp\sqlite-3.7.2-sqlitejdbc.dll
0x61800000 - 0x61bfc000 R:\temp\libspatialite-2.dll
0x77950000 - 0x77955000 C:\Windows\system32\PSAPI.DLL

VM Arguments:
jvm_args: -Xmx768m -XX:MaxPermSize=128m -Dosgi.noShutdown=false -
Dosgi.startLevel=20 -Dosgi.defaultStartLevel=20 -Dosgi.console=9101 -
Djava.io.tmpdir=temp -Dosgi.clean=true -
Dcci.startupMonitorEnabled=false -Dcci.startupMonitorProduct=CONTAINER
-Dmhcc.orgUnits=NONE -Dmhcc.environment=localhost -Dmhcc.container=c01
-Dcom.sun.management.jmxremote -
Dcom.sun.management.jmxremote.port=9201 -
Dcom.sun.management.jmxremote.authenticate=false -
Dcom.sun.management.jmxremote.ssl=false -
DXorg.aspectj.tracing.debug=true -DXorg.aspectj.tracing.enabled=true -
DXaj.weaving.verbose=true -DXorg.aspectj.osgi.verbose=true -
DXosgi.framework.extensions=org.eclipse.equinox.weaving.hook -
Ddistribution.provider.type=jms -Dmhcc.log4j.bridge.port=9501 -
Dmhcc.orgUnits=NONE -Djava.io.tmpdir=R:/MHDevEnv\..\temp -
Dmhcc.configDir=R:/MHCommon2/feature_mhcc.cci.component/rootfiles/
configuration/mhcfg -Dfile.encoding=Cp1252
java_command: org.eclipse.equinox.launcher.Main -product
mhcc.cci.container.core.product -data R:\MHDevEnv\workplaces\wp-
server/../runtime-mhcc.cci.container.01.ide.product -configuration
file:R:/MHDevEnv/workplaces/wp-server/.metadata/.plugins/
org.eclipse.pde.core/mhcc.cci.container.01.ide.product/ -dev file:R:/
MHDevEnv/workplaces/wp-server/.metadata/.plugins/org.eclipse.pde.core/
mhcc.cci.container.01.ide.product/dev.properties -os win32 -ws win32 -
arch x86 -nl en -consoleLog -nosplash -consolelog -debug -vm ./../jre/
bin
Launcher Type: SUN_STANDARD

Environment Variables:
JAVA_HOME=R:/MHDevEnv\tools\jdk1.6.0_07
PATH=R:/MHDevEnv/tools/jdk1.6.0_07/bin/../jre/bin/client;R:/MHDevEnv/
tools/jdk1.6.0_07/bin/../jre/bin;R:/MHDevEnv/tools/jdk1.6.0_07/bin/../
jre/lib/i386;R:/MHDevEnv\tools\pax-construct-1.0\bin;R:/MHDevEnv\tools
\apache-ant-1.7.0\bin;R:/MHDevEnv\tools\jdk1.6.0_07\bin;R:/MHDevEnv
\tools\Subversion\bin;D:\Programs\apache-maven-3.0.3\bin;C:\Program
Files (x86)\NVIDIA Corporation\PhysX\Common;C:\Windows\SYSTEM32;C:
\Windows;C:\Windows\SYSTEM32\WBEM;C:\Windows\SYSTEM32\WINDOWSPOWERSHELL
\V1.0\;C:\PROGRAM FILES\INTEL\WIFI\BIN\;C:\PROGRAM FILES\COMMON FILES
\INTEL\WIRELESSCOMMON\;C:\PROGRAM FILES (X86)\MICROSOFT SQL SERVER
\90\TOOLS\BINN\;;C:\Program Files\WIDCOMM\Bluetooth Software\;C:
\Program Files\WIDCOMM\Bluetooth Software\syswow64;C:\Program Files
(x86)\Graphviz 2.28\bin;D:\Programs\doxygen\bin;D:\Programs\Android
\android-sdk\tools;D:\Programs\Android\android-sdk\platform-tools;C:
\Program Files\SlikSvn\bin;C:\Program Files\TortoiseSVN\bin;D:\Programs
\Java\jdk1.6.0_29\bin;C:\Program Files\TortoiseGit\bin;R:\MHDevEnv\..
\cygwin\bin;R:/MHDevEnv\tools\ffmpeg\bin;R:\;
USERNAME=uide7588
OS=Windows_NT
PROCESSOR_IDENTIFIER=Intel64 Family 6 Model 30 Stepping 5,
GenuineIntel



--------------- S Y S T E M ---------------

OS: Windows 7 , 64 bit Build 7601 Service Pack 1

CPU:total 8 (4 cores per cpu, 2 threads per core) family 6 model 30
stepping 5, cmov, cx8, fxsr, mmx, sse, sse2, sse3, ssse3, sse4.1,
sse4.2, popcnt, ht

Memory: 4k page, physical 8319364k(1301268k free), swap
16636880k(8595208k free)

vm_info: Java HotSpot(TM) Server VM (20.2-b06) for windows-x86 JRE
(1.6.0_27-b07), built on Jul 19 2011 00:55:35 by "java_re" with MS VC+
+ 7.1 (VS2003)

time: Fri Feb 10 11:57:53 2012
elapsed time: 1442 seconds




I have the

On Feb 12, 8:00 am, Pepijn Van Eeckhoudt <pep...@vaneeckhoudt.net>
wrote:

[Pepijn Van Eeckhoudt]

Brad,

Do you know how to map the addresses from the stack trace back to source
line numbers? I've only done this is in the past with gcc (addr2line).
Not sure how to do this on Windows with dlls.

How does this setup work BTW? It looks like the Java code is calling
into a sqlite 3.7.2 dll which in turn makes calls to the spatialite dll.
But that one seems to be linked against its own internal version of
sqlite. If the versions are mismatched then that looks like a recipe for
disaster...

Pepijn

[Toomy]

Pepijn,

I don't know how to map addresses to source numbers..
But what you write that spatialite.dll has its own version of sqlite
is interesting.
Do you know how I can check that?

Should I just try to run that without a sqlite.dll loaded?



On Feb 14, 8:54 am, Pepijn Van Eeckhoudt <pep...@vaneeckhoudt.net>
wrote:

[a.fu...@lqt.it]

> It looks like the Java code is calling into a sqlite 3.7.2 dll
> which in turn makes calls to the spatialite dll.
> But that one seems to be linked against its own internal
> version of sqlite. If the versions are mismatched then that looks
> like a recipe for disaster...
>

AFAIK situation is even worse than this:
- the Xerial JDBC connector contains an internal private
copy of libsqlite (statically linked)
- many java users seem to deploy libspatialite-amalgamation;
this too contains another internal private copy of
libspatialite, this too being statically linked
- this frightening scenario becomes terrifying when you
consider that both copies are of different versions
(3.7.2 -> 3.7.10)

anyway simply using a generic non-amalgamated libspatialite.dll
doesn't seems enough; this dll should to be built against
the same identical version of sqlite internally included
in the Xerial JDBC connector.

bye Sandro

[Brad Hards]

On Tuesday 14 February 2012 18:54:52 Pepijn Van Eeckhoudt wrote:
> Brad,
>
> Do you know how to map the addresses from the stack trace back to source
> line numbers? I've only done this is in the past with gcc (addr2line).
> Not sure how to do this on Windows with dlls.

I wouldn't even try. Without a reproduceable test case, there is no way to
test any fix without many cycles of trying to guess the problem, send off
another experimental DLL, get a different stack trace, and so on.

I like Sandro's idea of testing the non-amalgamated version much more.

It would be best if the problem can be reproduced without use of Java, of
course. If the import process is pretty simple, and can be shown with a
standalone spatialite command-line tool, then we are potentially much closer
to some kind of fix.

Brad

[Pepijn Van Eeckhoudt]

I realize I sound like a broken record, but the way we've solved this is
by compiling spatialite without any links to sqlite (i.e. strictly using
the extension API). Unless sqlite introduces serious version
incompatibilities in the extension API, this avoids the whole version
mismatch problem altogether. AFAICT this hasn't happened in the past and
it looks like the extension API is carefully updated to be backwards
compatible (i.e., they only add new function pointers to the end of the
struct and never change the signature of existing functions).

Might be worthwhile to provide a binary of spatialite in this form as well?

Pepijn

[Pepijn Van Eeckhoudt]

On 14/02/2012 09:40, Brad Hards wrote:
> On Tuesday 14 February 2012 18:54:52 Pepijn Van Eeckhoudt wrote:
> I wouldn't even try. Without a reproduceable test case, there is no way to
> test any fix without many cycles of trying to guess the problem, send off
> another experimental DLL, get a different stack trace, and so on.

Well, given a pointer to where the thing is segfaulting it might be
obvious what's going wrong. I would be happy to take a look at the code,
but I need to know where to look first obviously :)
IIRC the windows builds are made with mingw right? If that's the case
then it's simply a matter of running addr2line with the addresses from
the stack trace.

> It would be best if the problem can be reproduced without use of Java, of
> course. If the import process is pretty simple, and can be shown with a
> standalone spatialite command-line tool, then we are potentially much closer
> to some kind of fix.

Markus, could you provide a sample dataset and the SQL query that you're
executing in
mhcc.app.geoservice.app.internal.routing.strategies.AbstractRoutingStrategy.route?

[Toomy]

Yes I will try to get that information today.
Thanks.

On Feb 14, 9:55 am, Pepijn Van Eeckhoudt <pep...@vaneeckhoudt.net>
wrote:

[Toomy]

Finally I managed to get the SQL Query that causes the Proplem. It is
a NearestNeighbourStatement.

String statement =
"SELECT " + tableName + ".id," + tableName +
".from_node," + tableName + ".to_node," + tableName
+ ".oneway_to_from,AsText(" + tableName +
".the_geom) AS the_geom, Distance(" + tableName
+ ".the_geom,MakePoint(?,?," +
GeoServiceConstants.DATA_SRID + ")) AS dist FROM idx_" + tableName +
"_the_geom, "
+ tableName + " ON idx_" + tableName +
"_the_geom.pkid=" + tableName + ".id WHERE ";
// bounds are within query
statement += "(( xmin < ? AND xmax > ? AND ymin < ? AND ymax
> ? ) ";
// bounds are intersecting with query
statement += "OR ( xmin > ? AND xmin < ? AND ymin > ? AND ymin
< ? ) ";
statement += "OR ( xmin > ? AND xmin < ? AND ymax > ? AND ymax
< ? ) ";
statement += "OR ( xmax > ? AND xmax < ? AND ymin > ? AND ymin
< ? ) ";
statement += "OR ( xmax > ? AND xmax < ? AND ymax > ? AND ymax
< ? )) ";
statement += "AND dist <= ?";
statement += "ORDER BY dist ASC LIMIT ?";

I will try to find out if I'm screwed up with multiple sqlite libs and
let u know if this helped.

[Pepijn Van Eeckhoudt]

On 16/02/2012 09:05, Toomy wrote:
> I will try to find out if I'm screwed up with multiple sqlite libs and
> let u know if this helped.

Even if the versions match exactly it's still a pretty fragile setup.
All it takes is one global variable that gets out of sync between the
two copies to make the whole thing come tumbling down.
The safest bet is to compile the jdbc driver with spatialite included
into it.

Pepijn