Re: [sqlite] sqlite 3.22.0 read-only WAL mode clarifications

2018-02-10 Thread Leonard Lausen 
Hey Simon,

thanks for your clarification.

> Will any of the processes accessing the database have write permission
> ? If not, if they're all just reading the existing database, then
> there's no opportunity for corruption. Think of it as

All of the processes (on "main" and remote host) have read and write
access, though I am only reading data in the processes accessing the db
on a network filesystem. So it may be safer to open the database with
SQLITE_OPEN_READONLY on the remote host.

> 1) Reading a database while it's being written to may yield corrupt results.  
> SQLite uses locking to avoid this.
> 2) Two processes writing a database at once will corrupt the database.  
> SQLite uses locking to avoid this.
> 3) Locking does not work properly across a network

Thanks for making me aware of potential corrupt results on read.

Due to the potential corruption I changed my scripts to ssh into the
main host and create a backup of the database with 'journal_mode delete'
that can then safely be used to read data even when on a network
filesystem.

Best regards
Leonard
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] sqlite 3.22.0 read-only WAL mode clarifications

2018-02-09 Thread Leonard Lausen 
sqlite 3.22.0 added the ability to read from WAL mode databases even if
the application lacks write permission on the database and its
containing directory, as long as the -shm and -wal files exist in that
directory.

Even though the wiki page states that WAL does not work over a network
filesystem, I am able to use WAL over a network filesystem when using
sqlite 3.22.0 as long as the respective -shm and -wal files exist. (This
may or may not work with earlier versions.)

Could someone clarify if this is intended or may result in database
corruption? (I am only reading from the database on the remote host)

Is there some way to force the -shm and -wal files to always be present?

Best regards
Leonard

PS: The details of the network filesystem mount: hostname:/home/data on
/home/hostname type nfs4
(ro,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=IPADDR,local_lock=none,addr=IPADDR)

___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Crash in libsqlite3 with sqlite-3.21.0 and KDE plasmashell

2018-01-19 Thread Leonard Lausen 

Thanks for your prompt reply Richard. With this information I will go
back to the KDE developers and let you know once/if there is further and
detailed evidence for sqlites fault.

Best regards
Leonard

Richard Hipp  writes:

> On 1/19/18, Leonard Lausen  wrote:
>>
>> A crash in sqlite crashes plasmashell. Downstream bug
>> https://bugs.kde.org/show_bug.cgi?id=388140. Please find the backtrace
>> below:
>>
>
> (1) These kinds of things are almost always the result of heap
> corruption in the application.  In other words, there is nothing wrong
> with SQLite.  SQLite just happened to be the unlucky victim to first
> stumble over the corrupted heap.  In fact, we find that whenever there
> is heap corruption of any sort, SQLite is more likely that most other
> libraries to be the first to stumble into it.
>
> (2) You have provided us very little to go on:  There is no version
> number on the SQLite library, no information on the platform on which
> the application is running, no line-number information on the stack
> trace, and no reproducible test case.
>
> (3) Given the above, we will take no action on this.
>
> (4) We will reconsider (3) if you can provide a scintilla of evidence
> that SQLite is at fault.
>
> -- 
> D. Richard Hipp
> d...@sqlite.org

-- 
Leonard Lausen
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Crash in libsqlite3 with sqlite-3.21.0 and KDE plasmashell

2018-01-18 Thread Leonard Lausen 

A crash in sqlite crashes plasmashell. Downstream bug
https://bugs.kde.org/show_bug.cgi?id=388140. Please find the backtrace
below:

-- Backtrace:
Application: Plasma (plasmashell), signal: Segmentation fault
Using host libthread_db library "/lib64/libthread_db.so.1".
[Current thread is 1 (Thread 0x7f81e59b3e00 (LWP 2825))]

Thread 17 (Thread 0x7f80e159c700 (LWP 10067)):
#0  0x7f81df010c9d in poll () from /lib64/libc.so.6
#1  0x7f81d9c285e6 in ?? () from /usr/lib64/libglib-2.0.so.0
#2  0x7f81d9c286fc in g_main_context_iteration () from 
/usr/lib64/libglib-2.0.so.0
#3  0x7f81df9811eb in 
QEventDispatcherGlib::processEvents(QFlags) () 
from /usr/lib64/libQt5Core.so.5
#4  0x7f81df92ccfa in 
QEventLoop::exec(QFlags) () from 
/usr/lib64/libQt5Core.so.5
#5  0x7f81df77de7a in QThread::exec() () from /usr/lib64/libQt5Core.so.5
#6  0x7f81e2801cf5 in QQmlThreadPrivate::run() () from 
/usr/lib64/libQt5Qml.so.5
#7  0x7f81df7827f4 in QThreadPrivate::start(void*) () from 
/usr/lib64/libQt5Core.so.5
#8  0x7f81de8c7687 in start_thread () from /lib64/libpthread.so.0
#9  0x7f81df01c03f in clone () from /lib64/libc.so.6

Thread 16 (Thread 0x7f810089a700 (LWP 3252)):
#0  0x7f81de8ce586 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7f81df782fab in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib64/libQt5Core.so.5
#2  0x7f8124b35005 in 
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
 bool, bool, bool) () from /usr/lib64/libKF5ThreadWeaver.so.5
#3  0x7f8124b39198 in 
ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () 
from /usr/lib64/libKF5ThreadWeaver.so.5
#4  0x7f8124b340fd in 
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#5  0x7f8124b391f2 in 
ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () 
from /usr/lib64/libKF5ThreadWeaver.so.5
#6  0x7f8124b340fd in 
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#7  0x7f8124b3704b in ThreadWeaver::Thread::run() () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#8  0x7f81df7827f4 in QThreadPrivate::start(void*) () from 
/usr/lib64/libQt5Core.so.5
#9  0x7f81de8c7687 in start_thread () from /lib64/libpthread.so.0
#10 0x7f81df01c03f in clone () from /lib64/libc.so.6

Thread 15 (Thread 0x7f810109b700 (LWP 3251)):
#0  0x7f81de8ce586 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7f81df782fab in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib64/libQt5Core.so.5
#2  0x7f8124b35005 in 
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
 bool, bool, bool) () from /usr/lib64/libKF5ThreadWeaver.so.5
#3  0x7f8124b39198 in 
ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () 
from /usr/lib64/libKF5ThreadWeaver.so.5
#4  0x7f8124b340fd in 
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#5  0x7f8124b391f2 in 
ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () 
from /usr/lib64/libKF5ThreadWeaver.so.5
#6  0x7f8124b340fd in 
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#7  0x7f8124b3704b in ThreadWeaver::Thread::run() () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#8  0x7f81df7827f4 in QThreadPrivate::start(void*) () from 
/usr/lib64/libQt5Core.so.5
#9  0x7f81de8c7687 in start_thread () from /lib64/libpthread.so.0
#10 0x7f81df01c03f in clone () from /lib64/libc.so.6

Thread 14 (Thread 0x7f810189c700 (LWP 3250)):
#0  0x7f81de8ce586 in pthread_cond_wait () from /lib64/libpthread.so.0
#1  0x7f81df782fab in QWaitCondition::wait(QMutex*, unsigned long) () from 
/usr/lib64/libQt5Core.so.5
#2  0x7f8124b35005 in 
ThreadWeaver::Weaver::takeFirstAvailableJobOrSuspendOrWait(ThreadWeaver::Thread*,
 bool, bool, bool) () from /usr/lib64/libKF5ThreadWeaver.so.5
#3  0x7f8124b39198 in 
ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () 
from /usr/lib64/libKF5ThreadWeaver.so.5
#4  0x7f8124b340fd in 
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#5  0x7f8124b391f2 in 
ThreadWeaver::WorkingHardState::applyForWork(ThreadWeaver::Thread*, bool) () 
from /usr/lib64/libKF5ThreadWeaver.so.5
#6  0x7f8124b340fd in 
ThreadWeaver::Weaver::applyForWork(ThreadWeaver::Thread*, bool) () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#7  0x7f8124b3704b in ThreadWeaver::Thread::run() () from 
/usr/lib64/libKF5ThreadWeaver.so.5
#8  0x7f81df7827f4 in QThreadPrivate::start(void*) () from 
/usr/lib64/libQt5Core.so.5
#9  0x7f81de8c7687 in start_thread () from /lib64/libpthread.so.0
#10 0x7f81df01c03f in clone () from /lib64/libc.so.6

Thread 13