On Wed, Jan 26, 2011 at 02:31:05PM -0500, Joe Mokos wrote: > I've written an application that uses SQLite 3.7.4. The application runs > fine on WinXP, AIX, HPUX and Linux. When I try to run on Solaris 5.8 SPARC > I get a bus error when I call sqlite3_close. I get the following stack > trace: > > > > (/opt/SUNWspro/bin/../WS6U2/bin/sparcv9/dbx) where > > current thread: t@1 > > =>[1] t_delete(0x1b5ed0, 0xfefbc008, 0x40, 0x1b5e90, 0x1a3840, 0x38), at > 0xfef427bc > > [2] realfree(0x1b5ec8, 0xfefc2858, 0xfefbc008, 0x1b5e90, 0x3b, 0x1b5e98), > at 0xfef423dc > > [3] _free_unlocked(0xfefc27cc, 0xfefbc008, 0x2a57c8, 0xfefbc008, > 0xffbede4a, 0x0), at 0xfef42c1c > > [4] free(0x2a57c8, 0xfefc3a54, 0xfefbfc78, 0xfefbfc78, 0xe9, 0x2a57c8), at > 0xfef42b6c > > [5] sqlite3MemFree(0x2a57d0, 0xffffffff, 0xc, 0xfef91bf8, 0x1b5d40, > 0x2a57c8), at 0x5a8cc
Faults from within the libc memory allocator are almost always the result of heap corruption, typically caused by buffer overruns. Check your code for potential buffer overruns. Solaris has good default memory error detection available within libumem. Check out: http://developers.sun.com/solaris/articles/libumem_library.html In combination with mdb, you can find the source of the nmemory allocation that is corrupted, which may give you a clue about where to look for overruns. Differences in malloc implementation between different OSes can mask bugs, as some implementations are quite tolerent of subtle bugs like off by one overruns. As Solaris has a slab based allocator by default, overunning one buffer puts you straight into the next buffer in the slab, corrupting memory that under Linux Windows or AIX might be dead space between blocks. Hope that helps, Christian _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
