Dan
I thought the test was from async3.test... But I'm probably wrong.
I got the info from ddd and asked it to tell me the contents of ppLock which
was 0.
Here is the output directly from gdb as you requested.
print *ppLock
$1 = (struct lockInfo *) 0x0
gdb) info threads
4 process 262671 0xfef9fa58 in _lwp_sema_wait () from /usr/lib/libc.so.1
3 process 197135 0xfef9cf4c in door_restart () from /usr/lib/libc.so.1
2 process 131599 0xfef9f3a8 in _signotifywait () from /usr/lib/libc.so.1
* 1 process 66063 0x00049750 in findLockInfo (fd=4, ppLock=0x1345ad,
ppOpen=0x1345a9) at ../sqliteSrc/sqlite-3.5.5/src/os_unix.c:670
Let me know if you need anything else.
Dan <[EMAIL PROTECTED]> wrote:
On Feb 1, 2008, at 6:37 AM, Ken wrote:
> Recompiled without the -O2 flags:
>
> #0 0x00049750 in findLockInfo (fd=4, ppLock=0x1345ad,
> ppOpen=0x1345a9)
> at ../sqliteSrc/sqlite-3.5.5/src/os_unix.c:670
> 670 *ppLock = pLock;
>
> *ppLock is Null....
Hi Ken,
This doesn't look quite right to me. In the debugger you can
do "print *ppLock" and it doesn't complain?
The test case you were running (async.test) uses more than one
thread, so maybe the one we're looking at is not the one that
caused the problem.
Can you try running [info threads] in the debugger, and then
see if you can get a stack trace for another thread? Thanks.
Dan.
>
> Ken wrote: Core/backtrace info:
>
>
> (gdb) core-file core
> Core was generated by `/home/ixion/LIB/sqlite3test/.libs/
> testfixture ../sqliteSrc/sqlite-3.5.5/test/qu'.
> Program terminated with signal 10, Bus error.
> Reading symbols from /home/ixion/LIB/sqlite3test/.libs/
> libsqlite3.so.0...done.
> Loaded symbols for /home/ixion/LIB/sqlite3test/.libs/libsqlite3.so.0
> Reading symbols from /usr/lib/libpthread.so.1...done.
> Loaded symbols for /usr/lib/libpthread.so.1
> Reading symbols from /usr/local/lib/libtcl8.5.so...done.
> Loaded symbols for /usr/local/lib/libtcl8.5.so
> Reading symbols from /usr/lib/libdl.so.1...done.
> Loaded symbols for /usr/lib/libdl.so.1
> Reading symbols from /usr/lib/libsocket.so.1...done.
> Loaded symbols for /usr/lib/libsocket.so.1
> Reading symbols from /usr/lib/libnsl.so.1...done.
> Loaded symbols for /usr/lib/libnsl.so.1
> Reading symbols from /usr/lib/libm.so.1...done.
> Loaded symbols for /usr/lib/libm.so.1
> Reading symbols from /usr/lib/librt.so.1...done.
> Loaded symbols for /usr/lib/librt.so.1
> Reading symbols from /usr/lib/libc.so.1...done.
> Loaded symbols for /usr/lib/libc.so.1
> Reading symbols from /usr/local/lib/libgcc_s.so.1...done.
> Loaded symbols for /usr/local/lib/libgcc_s.so.1
> Reading symbols from /usr/lib/libmp.so.2...done.
> Loaded symbols for /usr/lib/libmp.so.2
> Reading symbols from /usr/lib/libaio.so.1...done.
> Loaded symbols for /usr/lib/libaio.so.1
> Reading symbols from /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.
> 1...done.
> Loaded symbols for /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1
> Reading symbols from /usr/lib/libthread.so.1...done.
> Loaded symbols for /usr/lib/libthread.so.1
> #0 0x000345d4 in findLockInfo (fd=567296, ppLock=0xd1995,
> ppOpen=0xd1991)
> at ../sqliteSrc/sqlite-3.5.5/src/os_unix.c:671
> 671 if( ppOpen!=0 ){
> (gdb) backtrace
> #0 0x000345d4 in findLockInfo (fd=567296, ppLock=0xd1995,
> ppOpen=0xd1991)
> at ../sqliteSrc/sqlite-3.5.5/src/os_unix.c:671
> #1 0x000355b4 in unixOpen (pVfs=0x8a96c,
> zPath=0xc0380 "/home/ixion/LIB/sqlite3test/chocolate/banana/
> vanilla/file.db", pFile=0xd196d, flags=262, pOutFlags=0xffffffff)
> at ../sqliteSrc/sqlite-3.5.5/src/os_unix.c:2268
> #2 0x000340bc in sqlite3OsOpen (pVfs=0x2102,
> zPath=0xc0380 "/home/ixion/LIB/sqlite3test/chocolate/banana/
> vanilla/file.db", pFile=0xd196d, flags=262, pFlagsOut=0xffffffff)
> at ../sqliteSrc/sqlite-3.5.5/src/os.c:112
>
> ppOpen os_unxi.c/671 is not !=0 but *ppOpen is 0...
>
>
> James Dennett wrote: > -----Original Message-----
>> From: Ken [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, January 31, 2008 2:55 PM
>> To: sqlite
>> Subject: [sqlite] Solaris bus error
>>
>>
>> After addressing the -lrt sched yield on solaris.
>>
>> make test resulted in:
>>
>> async3-1.0... Ok
>> async3-1.1...make: *** [test] Bus Error (core dumped)
>>
>> Any ideas?
>
> Getting a stack trace out of that core file with a debugger would seem
> to be the next step, and seeing the full text output if there is any
> more.
>
> -- James
>
>
>
>
> James Dennett wrote: > -----Original Message-----
>> From: Ken [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, January 31, 2008 2:55 PM
>> To: sqlite
>> Subject: [sqlite] Solaris bus error
>>
>>
>> After addressing the -lrt sched yield on solaris.
>>
>> make test resulted in:
>>
>> async3-1.0... Ok
>> async3-1.1...make: *** [test] Bus Error (core dumped)
>>
>> Any ideas?
>
> Getting a stack trace out of that core file with a debugger would seem
> to be the next step, and seeing the full text output if there is any
> more.
>
> -- James
>
>
>
>
> James Dennett wrote: > -----Original Message-----
>> From: Ken [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, January 31, 2008 2:55 PM
>> To: sqlite
>> Subject: [sqlite] Solaris bus error
>>
>>
>> After addressing the -lrt sched yield on solaris.
>>
>> make test resulted in:
>>
>> async3-1.0... Ok
>> async3-1.1...make: *** [test] Bus Error (core dumped)
>>
>> Any ideas?
>
> Getting a stack trace out of that core file with a debugger would seem
> to be the next step, and seeing the full text output if there is any
> more.
>
> -- James
>
>
>
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
