This page has three main sections. (Note that the listings could be empty.) moreā€¦ Tip: Remember the back-button! And don't click the number on the left.

  1. The first item displays a term, URL, text or picture.
  2. Followed by a (still unordered) listing of statements about this subject. (for details follow ">"-link)
  3. Separated by a horizontal rule a "reverse" listing of statements referring to this item in object position.
4017 comment >

With sqlite 3.7.8 updates on a frequently used application broke on "out of memory".

Only fts3 applications using fts3 tables where effected.

Turned out this bug has existed since 2010-07-08 fossil commit e1974f6aa, when the VFS support was initially completed.

The xFileControl method did since return SQLITE_OK instead of SQLITE_NOTFOUND as it should for pragma commands it did not handle (all).

This in turn would greatly confuse sqlite3.

Older versions did not complain and (mostly) execute as expected anyway. Newer versions ran out of memory.

Having fixed the problem (2015-09-16) there another strange issue disappeared for now:

All the "tonido plug" boxes locked the BALL process up several times a day. It was not possible to kill the process even as root. The only way to recover them was to reboot the machine. (Note: This was never observed elswhere, not at those Sheeva plugs running the very same debian version, let alone those x86 based versions. Looks like a very interesting Linux issue - I just never was interested enough by that one. ;-) Sadly enough the work-around has eventually made it into the distributions code since.)

Since the bug was fixed three days ago, no reboot was issued. It looks as if the confused sqlite3 memory has somehow caused the whole Linux to lock up.

4010 is a > issue
4013 title > sqlite update on fts3 table breaks on "out of memory"
4015 state > solved comment
issue container member