On Jan 16, 2009, at 12:58 PM, Nicolas Williams wrote:
> Failures on these tests: malloc-1.transient.40 malloc-10.transient.40
> malloc-14.transient.40 malloc-17.transient.41
> malloc-20.transi ent.40 malloc-26.transient.40
>
> malloc-1.transient.40...
> Expected: [1 1]
> Got: [0 {1 2.3 4.5 hi there^@ 6 7.0 0.8 hello {out yonder} 1
> {out yonder} 7.0}]
> malloc-10.transient.40...
> Expected: [1 1]
> Got: [0 {}]
> malloc-14.transient.40...
> Expected: [1 1]
> Got: [0 {1 2}]
> malloc-17.transient.41...
> Expected: [1 1]
> Got: [0 0]
> malloc-20.transient.40...
> Expected: [1 1]
> Got: [0 {}]
> malloc-26.transient.40...
> Expected: [1 1]
> Got: [0 {}]
>
> What do those mean? Are these errors a problem?
>
These are simulated malloc() failures. They are important for
embedded devices (which tend to run out of memory) but not so much on
Solaris. When was the last time you remember that malloc() really
failed on a workstation or a server?
The errors you are getting seem to indicate that the memory allocation
problems are simply not getting reported back up to the top-level.
SQLite is able to complete whatever it was doing in spite of malloc()
returning NULL. I do not know why. If you want to try to debug the
problem, set a breakpoint on the routine "sqlite3Fault()" for the test
case that is given a problem. The sqlite3Fault() routine is called
whenever one of the simulated malloc() failures occurs. Then look at
the stack to see where the problem is occurring.
D. Richard Hipp
d...@hwaci.com
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
