On Thu, May 28, 2009 at 04:00:07PM -0400, D. Richard Hipp wrote:
> These are tests that simulate a malloc() failure (aka "out-of-memory"
> or OOM fault) to verify that nothing crashes or leaks following an OOM
> fault and that an SQLITE_NOMEM error is reported back out at the top
> level. The problem here seems to be that the SQLITE_NOMEM is not
> making it back up to the top. This is not a serious error because (1)
> nothing crashed and (2) you probably will never hit a real OOM fault
> on virtual-memory platform like Solaris anyhow.
Thanks. Solaris can definitely return ENOMEM. The Solaris VM subsystem
does not oversubscribe memory+swap (there's no OOM killer in Solaris).
> To debug, set a breakpoint on sqlite3Fault(). That routine is called
> whenever an OOM fault is simulated. Run to the point of the OOM fault
> that is causing the problem. Figure out which malloc() is falling and
> why the problem is not being reported back up to the top level.
How would I run a single test?
> I really did run a complete regression with no errors on Linux x86,
> x86_64, and mac x86 prior to releasing 3.6.14.2. I'm very curious to
> know what is different about Solaris that is causing the extra
> undetected OOM fault.
I'll let you know. What I'll do (once I know how to run a single test
:) is use DTrace like this:
# Run the test, catch a call to sqlite3Fault(), print a stack trace,
# stop the process, and exit.
dtrace -w -n 'pid$target::sqlite3Fault:entry{ustack(); stop(); exit();}'
<sqlite3 test>
Then I'll use DTrace again to trace all function call entry/return
events as the program unwinds, something like this:
# Set the stopped program to run and trace the time on every function
# call and all return values.
dtrace -F -n 'BEGIN {system("prun $1");}' \
-n 'pid$1:::entry{trace(timestamp);}' \
-n 'pid$1:::return{trace(arg1);}' <PID of the stopped program>
> > Also, I got this more serious looking test failure on x86, 32-bit:
> >
> > perm-memsubsys1.fts3expr-3.18...
> > Expected: [AND one wo]
> > Got: [AND one woe]
Did you mean to tell me about this one?
Nico
--
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
