Re: [sqlite] [regression] SQLite 3.8.7 causes Evolution to crash

[Richard Hipp]

On Sat, Oct 25, 2014 at 6:15 AM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

>
> thank you a lot for the analysis leading to a solution.
>
> Was it just bad luck that such a change to use different code paths is
> done for a bug fix release (3.8.6 to 3.8.7)? Or don’t you use semantic
> versioning for SQLite?
>
>
The 4th digit increments for bug-fix releases.  For example:  3.8.6 to
3.8.6.1.


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [regression] SQLite 3.8.7 causes Evolution to crash

[Paul Menzel]

Dear Richard,


Am Mittwoch, den 22.10.2014, 21:53 -0400 schrieb Richard Hipp:
> On Wed, Oct 22, 2014 at 5:14 PM, Paul Menzel wrote:

> > after the upgrade of libsqlite3 from 3.8.6 to 3.8.7 Evolution crashes
> > with a segmentation fault.
> >
> > pool[6371]: segfault at 0 ip   (null) sp a67d26ec error 14
> >
> > Several people have reproduced this [1].
> 
> The problem *might* be an incomplete VFS implementation in Evolution.  I
> put a more detailed comment on the Bugzilla ticket.

thank you a lot for the analysis leading to a solution.

Was it just bad luck that such a change to use different code paths is
done for a bug fix release (3.8.6 to 3.8.7)? Or don’t you use semantic
versioning for SQLite?


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=738965


signature.asc
Description: This is a digitally signed message part
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [regression] SQLite 3.8.7 causes Evolution to crash

[Jungle Boogie]

Dear Richard, Ralf

From: Richard Hipp <d...@sqlite.org>
Sent:  Wed, 22 Oct 2014 21:53:36 -0400
To: General Discussion of SQLite Database <sqlite-users@sqlite.org> Cc: Ralf 
Mardorf <ralf.mard...@alice-dsl.net>

Subject: Re: [sqlite] [regression] SQLite 3.8.7 causes Evolution to crash
>

On Wed, Oct 22, 2014 at 5:14 PM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:


Dear SQLite folks,


after the upgrade of libsqlite3 from 3.8.6 to 3.8.7 Evolution crashes
with a segmentation fault.

 pool[6371]: segfault at 0 ip   (null) sp a67d26ec error 14

Several people have reproduced this [1].



The problem *might* be an incomplete VFS implementation in Evolution.  I
put a more detailed comment on the Bugzilla ticket.




For posterity, Richard is right:
https://bugzilla.gnome.org/show_bug.cgi?id=738965


In the stack trace linked in Comment 1 above, in Thread 45, I see that the
SQLite routine sqlite3OsRead() invokes an external routine named
camel_sqlite3_file_xRead().  From this I presume that evolution is using a
custom VFS for SQLite that is implemented in the file named "camel-db.c".  Is
that correct?


Thanks for the investigation. You are absolutely right, camel-db provides its
own SQLite VFS to have delayed writes to a disk.


Dr. Hipp, thank you for all your efforts to continue making SQLite still so 
usable and powerful.




--
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [regression] SQLite 3.8.7 causes Evolution to crash

[Richard Hipp]

On Wed, Oct 22, 2014 at 5:14 PM, Paul Menzel <
paulepan...@users.sourceforge.net> wrote:

> Dear SQLite folks,
>
>
> after the upgrade of libsqlite3 from 3.8.6 to 3.8.7 Evolution crashes
> with a segmentation fault.
>
> pool[6371]: segfault at 0 ip   (null) sp a67d26ec error 14
>
> Several people have reproduced this [1].
>

The problem *might* be an incomplete VFS implementation in Evolution.  I
put a more detailed comment on the Bugzilla ticket.


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] [regression] SQLite 3.8.7 causes Evolution to crash

[Paul Menzel]

Dear SQLite folks,


after the upgrade of libsqlite3 from 3.8.6 to 3.8.7 Evolution crashes
with a segmentation fault.

pool[6371]: segfault at 0 ip   (null) sp a67d26ec error 14

Several people have reproduced this [1].

Milan, one of the main developers of Evolution, analyzed the crash a
little [2]:


Am Montag, den 20.10.2014, 11:12 +0200 schrieb Milan Crha:

[…]

> If you are wondering, then according to the backtrace the sqlite 
> was executing "SELECT uid,flags FROM 'Inbox' order by dreceived" or 
> your ~/.local/share/evolution/mail/local/folders.db file, which you 
> can run outside of evolution too, with this command:
>$ sqlite3 ~/.local/share/evolution/mail/local/folders.db \
> "SELECT uid,flags FROM 'Inbox' order by dreceived;"
> It should return many lines or just crash like evolution did, when 
> you'll use "the affected" sqlite version.

It’d be great if you could open a bug report in the SQLite bug tracker
and help analyzing the bug.

Please find the backtrace pasted at the end of the message.


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=738965
[2] https://mail.gnome.org/archives/evolution-list/2014-October/msg00126.html


#0  0x in ?? ()

Thread 49 (Thread 0xa20eab40 (LWP 10460)):
#0  0xb7fdcd4c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7cb1c4b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb43d916e in std::condition_variable::wait(std::unique_lock&) 
() from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0xb3b8c3f4 in wait > 
(__p=..., __lock=..., this=0xa9f560c0)
at /usr/include/c++/4.9/condition_variable:98
No locals.
#4  JSC::GCThread::waitForNextPhase (this=0x88410be8) at 
../Source/JavaScriptCore/heap/GCThread.cpp:79
lock = {_M_device = 0xa9f560a8, _M_owns = true}
#5  0xb3b8c4f9 in JSC::GCThread::gcThreadMain (this=0x88410be8) at 
../Source/JavaScriptCore/heap/GCThread.cpp:97
enabler = {m_stack = @0x8847e7d8}
currentPhase = 
#6  0xb3b8c5ba in JSC::GCThread::gcThreadStartFunc (data=0x88410be8) at 
../Source/JavaScriptCore/heap/GCThread.cpp:133
thread = 0x88410be8
#7  0xb3e8805e in WTF::threadEntryPoint (contextData=0xa9f0dd48) at 
../Source/WTF/wtf/Threading.cpp:69
context = 0xa9f0dd48
entryPoint = 0xb3b8c5a0 
data = 0x88410be8
#8  0xb3e880f9 in WTF::wtfThreadEntryPoint (param=0xa9f0c030) at 
../Source/WTF/wtf/ThreadingPthreads.cpp:170
invocation = std::unique_ptr containing 
0xa9f0c030
#9  0xb7cadefb in start_thread (arg=0xa20eab40) at pthread_create.c:309
__res = 
pd = 0xa20eab40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211367424, -1576096960, 
4001536, -1576099288, 917005609, -1101589246}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 
0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#10 0xb51c0d4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
No locals.

Thread 48 (Thread 0xa30ecb40 (LWP 10459)):
#0  0xb7fdcd4c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7cb1c4b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb43d916e in std::condition_variable::wait(std::unique_lock&) 
() from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0xb3b8aefb in JSC::BlockAllocator::blockFreeingThreadMain (this=0xa9f5103c) 
at ../Source/JavaScriptCore/heap/BlockAllocator.cpp:143
lock = {_M_device = 0xa9f51130, _M_owns = true}
regionLocker = {lock_ = 0xa9f5112c}
desiredNumberOfEmptyRegions = 
#4  0xb3b8b12a in JSC::BlockAllocator::blockFreeingThreadStartFunc 
(blockAllocator=0xa9f5103c)
at ../Source/JavaScriptCore/heap/BlockAllocator.cpp:119
No locals.
#5  0xb3e8805e in WTF::threadEntryPoint (contextData=0xa9f0dd70) at 
../Source/WTF/wtf/Threading.cpp:69
context = 0xa9f0dd70
entryPoint = 0xb3b8b110 

data = 0xa9f5103c
#6  0xb3e880f9 in WTF::wtfThreadEntryPoint (param=0xa9f0c010) at 
../Source/WTF/wtf/ThreadingPthreads.cpp:170
invocation = std::unique_ptr containing 
0xa9f0c010
#7  0xb7cadefb in start_thread (arg=0xa30ecb40) at pthread_create.c:309
__res = 
pd = 0xa30ecb40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211367424, -1559311552, 
4001536, -1559313880, 912811307, -1101589246}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 
0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize 

[sqlite] [regression] SQLite 3.8.7 causes Evolution to crash

[Paul Menzel]

Dear SQLite folks,


after the upgrade of libsqlite3 from 3.8.6 to 3.8.7 Evolution crashes
with a segmentation fault.

pool[6371]: segfault at 0 ip   (null) sp a67d26ec error 14

Several people have reproduced this [1].

Milan, one of the main developers of Evolution, analyzed the crash a
little [2]:


Am Montag, den 20.10.2014, 11:12 +0200 schrieb Milan Crha:

[…]

> If you are wondering, then according to the backtrace the sqlite 
> was executing "SELECT uid,flags FROM 'Inbox' order by dreceived" or 
> your ~/.local/share/evolution/mail/local/folders.db file, which you 
> can run outside of evolution too, with this command:
>$ sqlite3 ~/.local/share/evolution/mail/local/folders.db \
> "SELECT uid,flags FROM 'Inbox' order by dreceived;"
> It should return many lines or just crash like evolution did, when 
> you'll use "the affected" sqlite version.

It’d be great if you could open a bug report in the SQLite bug tracker
and help analyzing the bug.

Please find the backtrace pasted at the end of the message.


Thanks,

Paul


[1] https://bugzilla.gnome.org/show_bug.cgi?id=738965
[2] https://mail.gnome.org/archives/evolution-list/2014-October/msg00126.html


#0  0x in ?? ()

Thread 49 (Thread 0xa20eab40 (LWP 10460)):
#0  0xb7fdcd4c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7cb1c4b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb43d916e in std::condition_variable::wait(std::unique_lock&) 
() from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0xb3b8c3f4 in wait > 
(__p=..., __lock=..., this=0xa9f560c0)
at /usr/include/c++/4.9/condition_variable:98
No locals.
#4  JSC::GCThread::waitForNextPhase (this=0x88410be8) at 
../Source/JavaScriptCore/heap/GCThread.cpp:79
lock = {_M_device = 0xa9f560a8, _M_owns = true}
#5  0xb3b8c4f9 in JSC::GCThread::gcThreadMain (this=0x88410be8) at 
../Source/JavaScriptCore/heap/GCThread.cpp:97
enabler = {m_stack = @0x8847e7d8}
currentPhase = 
#6  0xb3b8c5ba in JSC::GCThread::gcThreadStartFunc (data=0x88410be8) at 
../Source/JavaScriptCore/heap/GCThread.cpp:133
thread = 0x88410be8
#7  0xb3e8805e in WTF::threadEntryPoint (contextData=0xa9f0dd48) at 
../Source/WTF/wtf/Threading.cpp:69
context = 0xa9f0dd48
entryPoint = 0xb3b8c5a0 
data = 0x88410be8
#8  0xb3e880f9 in WTF::wtfThreadEntryPoint (param=0xa9f0c030) at 
../Source/WTF/wtf/ThreadingPthreads.cpp:170
invocation = std::unique_ptr containing 
0xa9f0c030
#9  0xb7cadefb in start_thread (arg=0xa20eab40) at pthread_create.c:309
__res = 
pd = 0xa20eab40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211367424, -1576096960, 
4001536, -1576099288, 917005609, -1101589246}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 
0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#10 0xb51c0d4e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:129
No locals.

Thread 48 (Thread 0xa30ecb40 (LWP 10459)):
#0  0xb7fdcd4c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7cb1c4b in pthread_cond_wait@@GLIBC_2.3.2 () at 
../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:187
No locals.
#2  0xb43d916e in std::condition_variable::wait(std::unique_lock&) 
() from /usr/lib/i386-linux-gnu/libstdc++.so.6
No symbol table info available.
#3  0xb3b8aefb in JSC::BlockAllocator::blockFreeingThreadMain (this=0xa9f5103c) 
at ../Source/JavaScriptCore/heap/BlockAllocator.cpp:143
lock = {_M_device = 0xa9f51130, _M_owns = true}
regionLocker = {lock_ = 0xa9f5112c}
desiredNumberOfEmptyRegions = 
#4  0xb3b8b12a in JSC::BlockAllocator::blockFreeingThreadStartFunc 
(blockAllocator=0xa9f5103c)
at ../Source/JavaScriptCore/heap/BlockAllocator.cpp:119
No locals.
#5  0xb3e8805e in WTF::threadEntryPoint (contextData=0xa9f0dd70) at 
../Source/WTF/wtf/Threading.cpp:69
context = 0xa9f0dd70
entryPoint = 0xb3b8b110 

data = 0xa9f5103c
#6  0xb3e880f9 in WTF::wtfThreadEntryPoint (param=0xa9f0c010) at 
../Source/WTF/wtf/ThreadingPthreads.cpp:170
invocation = std::unique_ptr containing 
0xa9f0c010
#7  0xb7cadefb in start_thread (arg=0xa30ecb40) at pthread_create.c:309
__res = 
pd = 0xa30ecb40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211367424, -1559311552, 
4001536, -1559313880, 912811307, -1101589246}, mask_was_saved = 0}}, 
  priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 
0x0, canceltype = 0}}}
not_first_call = 
pagesize_m1 = 
sp = 
freesize