Re: [sqlite] SIGBUS errors with WAL mode and multiple simultaneous updating clients

[Richard Hipp]

On 12/2/19, avinash.jha2493  wrote:
> Was this resolved?

What what resolved?

There are no known issues in SQLite's WAL mode.  In fact, there are no
known segfault issues with SQLite.  Perhaps there is a problem with
tensorflow, but we don't have anything to do with that - you will need
to discuss this with the TF people.
-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] SIGBUS errors with WAL mode and multiple simultaneous updating clients

[avinash.jha2493]

Was this resolved?



--
Sent from: http://sqlite.1065341.n5.nabble.com/
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] SIGBUS errors with WAL mode and multiple simultaneous updating clients

[Brodie Thiesfield]

Hi,

I seeing some SIGBUS faults during startup in the debug version of my
app, but only when running under valgrind, and only for some clients.
The faults appear to be occurring around the same location in the
sqlite WAL code. If I disable WAL then there are no faults. If I don't
run it under valgrind then there are no problems (so don't run it
under valgrind?). I don't know if this problem is caused by my code or
perhaps an issue in the sqlite WAL code caused by timing (since the
startup is much slower under valgrind).

The error occurs with a newly created database file containing a
number of tables and data. It is small -> about 80kb. I've upgraded
everything to latest versions and the problem persists, currently
using valgrind 3.6.1 and sqlite 3.7.7.1 (amalgamation). CentOS 5.6.
app built with gcc 4.4.4. I'm not using any sqlite compile time flags.

The app is a parent process that does a fork/exec of 5 children (same
results with different numbers of children). Each child runs some
simple test code mostly simultaneously. I find that usually 1 child
faults, sometimes more or less. The busy handler is usually called a
number of times for the clients, sometimes delaying for up to a few
seconds before retrying.

The parent may have multiple database connections open at the time of
the fork. They are closed in the child process before the exec. I
can't close them before that as they are in active use in the parent.
I've checked that there are no open file descriptors (other than those
that valgrind has) at the time of process startup.

If there is something that anyone can suggest to narrow down the
problem then I would be interested to hear it.

Regards,
Brodie


Some example stack traces:

==23787== Process terminating with default action of signal 7
(SIGBUS): dumping core
==23787==  Non-existent physical address at address 0x5D94068
==23787==    at 0x8484CAF: walIndexRecover (sqlite3.c:44817)
==23787==    by 0x8485DE2: walIndexReadHdr (sqlite3.c:45569)
==23787==    by 0x8485EC0: walTryBeginRead (sqlite3.c:45682)
==23787==    by 0x8486231: sqlite3WalBeginReadTransaction (sqlite3.c:45839)
==23787==    by 0x84802A6: pagerBeginReadTransaction (sqlite3.c:39822)
==23787==    by 0x84820A5: sqlite3PagerSharedLock (sqlite3.c:41678)
==23787==    by 0x848A0EC: lockBtree (sqlite3.c:49813)
==23787==    by 0x848A7AA: sqlite3BtreeBeginTrans (sqlite3.c:50105)
==23787==    by 0x84C637C: sqlite3InitOne (sqlite3.c:89829)
==23787==    by 0x84C678D: sqlite3Init (sqlite3.c:89998)
==23787==    by 0x84C6876: sqlite3ReadSchema (sqlite3.c:90035)
==23787==    by 0x84C3298: sqlite3Pragma (sqlite3.c:88616)
==23787==    by 0x84DF79A: yy_reduce (sqlite3.c:106258)
==23787==    by 0x84E00FF: sqlite3Parser (sqlite3.c:106641)
==23787==    by 0x84E0D13: sqlite3RunParser (sqlite3.c:107465)
==23787==    by 0x84C6BD5: sqlite3Prepare (sqlite3.c:90212)
==23787==    by 0x84C6ED4: sqlite3LockAndPrepare (sqlite3.c:90304)
==23787==    by 0x84C7043: sqlite3_prepare (sqlite3.c:90367)
==23787==    by 0x84C1A35: sqlite3_exec (sqlite3.c:86911)
==23787==    by 0x840F554:
cl::DatabaseSqlite::Connect(cl::StringBuffer
const&, int) (DatabaseSqlite.cpp:113)
==23787==    by 0x83F1BCC: cl::Database::InitDatabaseSqlite(void*)
(Database.cpp:631)
==23787==    by 0x83F07DA:
cl::Database::Init(boost::shared_ptr&)
(Database.cpp:465)
==23787==    by 0x83F03E7:
cl::Database::Connect(boost::shared_ptr&,
boost::shared_ptr&) (Database.cpp:382)
==23787==    by 0x82CDE08: clsoapmain(int, char**) (clsoapMain.cpp:306)
==23787==    by 0x82DA099: main (clsoapUnix.cpp:32)



==23771== Process terminating with default action of signal 7
(SIGBUS): dumping core
==23771==  Non-existent physical address at address 0x5D9B686
==23771==    at 0x84863B0: sqlite3WalRead (sqlite3.c:45931)
==23771==    by 0x847FF1D: readDbPage (sqlite3.c:39604)
==23771==    by 0x84822AF: sqlite3PagerAcquire (sqlite3.c:41841)
==23771==    by 0x848929B: btreeGetPage (sqlite3.c:49066)
==23771==    by 0x848938E: getAndInitPage (sqlite3.c:49119)
==23771==    by 0x848C586: moveToChild (sqlite3.c:51633)
==23771==    by 0x848C8EA: moveToLeftmost (sqlite3.c:51798)
==23771==    by 0x848D2E3: sqlite3BtreeNext (sqlite3.c:52180)
==23771==    by 0x848D2A7: sqlite3BtreeNext (sqlite3.c:52170)
==23771==    by 0x84A2469: sqlite3VdbeExec (sqlite3.c:67148)
==23771==    by 0x849ABBF: sqlite3Step (sqlite3.c:61204)
==23771==    by 0x849ADAB: sqlite3_step (sqlite3.c:61277)
==23771==    by 0x8410AEB: cl::RequestSqlite::Step() (DatabaseSqlite.cpp:566)
==23771==    by 0x83F5777: cl::Database::LoadStrings(char,
std::vector&) (Database.cpp:1623)
==23771==    by 0x83F0C91: cl::Database::TestDatabaseStrings()
(Database.cpp:532)
==23771==    by 0x83F0A96:
cl::Database::Init(boost::shared_ptr&)
(Database.cpp:508)
==23771==    by 0x83F03E7:
cl::Database::Connect(boost::shared_ptr&,
boost::shared_ptr&) (Database.cpp:382)
==23771==    by 0x82CDE08: clsoapmain(int, char**)