On 10/28/15, Lohmann, Niels, Dr. (CQTN) <niels.lohmann at carmeq.com> wrote: > Hi there, > > unfortunately, the stack trace is truncated: > > (gdb) bt > #0 0x010385c4 in SignalProcmask_r () from > C:\QNX650\target\qnx6/armle-v7/lib/libc.so.3 > #1 0x010206d8 in pthread_sigmask () from > C:\QNX650\target\qnx6/armle-v7/lib/libc.so.3 > #2 0x01028acc in __abort () from > C:\QNX650\target\qnx6/armle-v7/lib/libc.so.3 > #3 0x0038fc00 in defaultAbort () > #4 0x0012ebfc in nsc::NavServerApplication::onSignal (this=0x58a718, > signalInfo=0xdf3ad4, data=<value optimized out>) at > ../public/../source/navapplApplication.cpp:4226 > #5 0x0036dd20 in aaf::localSignalHandlerExtended () > #6 0x0038f924 in genericSignalHandler () > #7 <signal handler called> > #8 0x78991330 in ?? () from libsqlite_shared.so > Cannot access memory at address 0x329457c > > > Meanwhile, we found out that replacing "file::memory:?cache=shared" by > "file::memory:" may avoid the problem. We have not tested it thouroughly. > What do you think? Could the shared cache be the reason for the issue? >
You might have found some really obscure issue in SQLite. But that will be hard to determine unless we can reproduce the problem, or at least get a complete stack trace. Can you statically link against SQLite instead of using a shared library, and use -g when compiling? That might give a better stack trace. -- D. Richard Hipp drh at sqlite.org
