On May 28, 2009, at 3:32 PM, Nicolas Williams wrote:
> I'm getting these failures in gmake fulltest output for SQLite3
> 3.6.14.2
> on Solaris x86 (32- and 64-bit):
>
> altermalloc-1.transient.42...
> Expected: [1 1]
> Got: [0 {}]
>
> Are these failures a problem? How would I start to debug this?
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.
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.
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.
>
>
> 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]
>
> Thanks,
>
> Nico
> --
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
D. Richard Hipp
d...@hwaci.com
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
