from:"Paul Menzel"

Re: [sqlite] Segfault with Evolution and patched SQLite 3.8.7.4

2015-01-10 Thread Paul Menzel

Am Freitag, den 09.01.2015, 21:04 -0500 schrieb Richard Hipp:
> On 1/9/15, Paul Menzel wrote:
> > Am Dienstag, den 30.12.2014, 16:15 +0100 schrieb Paul Menzel:
> >
> > With still around 1.3 GB free on the partition mounted to `/var/`,
> > Evolution crashed with the f received the following segmentation fault
> > today.
> 
> Which build of SQLite are you using.  What is SQLITE_SOURCE_ID?

I downloaded the source of Debian package for SQLite 3.8.7.4-1 and
applied the patch from [2] (also attached).

$ /usr/bin/sqlite3 --version
3.8.7.4 2014-12-09 01:34:36
f66f7a17b78ba617acde90fc810107f34f1a1f2e

> Also, we have some new "sqlite3.c" and "sqlite3.h" files for the
> upcoming 3.8.8 release.  Can I encourage you to try them out.

I’ll try to test the 3.8.8 files. Unfortunately, I have not found a way
to reproduce the issue.

> > 0xb3f9af51 in sqlite3Strlen30 (z=0x18  > at address 0x18>) at sqlite3.c:22902
> >
> >
> > Thread 53 (Thread 0xa7e04b40 (LWP 3576)):
> > #0  0xb3f9af51 in sqlite3Strlen30 (z=0x18  > memory at address 0x18>) at sqlite3.c:22902
> 
> sqlite3Strlen30() is called with an invalid string pointer,
> apparently.  The sqlite3Strlen30() function is just a strlen()
> implementation that returns int instead of size_t. Stack frames 0
> through 5 look fine, except for the invalid string pointer, of coruse.
> 
> > #5  0xb3f9ce21 in unixSync (id=0xacbe7898, flags=2) at 
> > sqlite3.c:28396
> > dirfd = 668585276
> > rc = 
> > pFile = 0xacbe7898
> > isDataOnly = 0
> > isFullsync = 0
> 
> The unixSync routine above calls frame 4 from
> (https://www.sqlite.org/src/artifact/949cdedc74dbf3c1?ln=3589).
> Apparently, pFile->zPath is an invalid pointer.
> 
> 
> > #6  0xb7ad33d6 in call_old_file_Sync (flags=, 
> > cFile=) at camel-db.c:66
> 
> The pFile object with the invalid zPath field is a parameter to
> unixSync(), and hence comes from call_old_file_Sync(), which is not a
> part of the SQLite source tree.  I don't have the sources to
> camel-db.c so I cannot trace this any further.

You can view the source at [3].

static gint
call_old_file_Sync (CamelSqlite3File *cFile,
gint flags)
{
g_return_val_if_fail (old_vfs != NULL, SQLITE_ERROR);
g_return_val_if_fail (cFile != NULL, SQLITE_ERROR);

g_return_val_if_fail (cFile->old_vfs_file->pMethods != NULL, 
SQLITE_ERROR);
return cFile->old_vfs_file->pMethods->xSync 
(cFile->old_vfs_file, flags);
}

> My guess (based on the name of the function) is that camel-db.c is
> trying to "sync" an sqlite3_file object that has been previously
> destroyed.

That sounds reasonable. I created a ticket in GNOME’s bug tracker
Bugzilla and it was assigned the ID #742688 [4]. I added you to the CC
list. Hopefully, you do not mind.

> This appears to be completely unrelated to the previous issue.  The
> previous issue was that a file was not being extended correctly
> because of a lack of disk space, so that a memcpy() into a mmap() of
> that file segfaulted.  That does not appear to be what is happening
> here, unless I'm missing something.

[…]

As always thank you very much for the quick and detailed reply!


Thanks,

Paul


> >> [1] https://packages.debian.org/corekeeper
> >> [2] 
> >> https://www.sqlite.org/src/info/776648412c30dce206f1024ff849c2cb025bb006
[3] 
http://sources.debian.net/src/evolution-data-server/3.12.9~git20141128.5242b0-2/camel/camel-db.c/#L66
[4] https://bugzilla.gnome.org/show_bug.cgi?id=742688


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] Segfault with Evolution and patched SQLite 3.8.7.4 (was: Bus error with Evolution 3.12.9 and SQLite 3.8.7.4)

2015-01-09 Thread Paul Menzel

Am Dienstag, den 30.12.2014, 16:15 +0100 schrieb Paul Menzel:
> Am Dienstag, den 30.12.2014, 08:21 -0500 schrieb Richard Hipp:
> > On Mon, Dec 29, 2014 at 10:37 AM, László Böszörményi (GCS) wrote:
> 
> > > > it’s not obvious that these might cause such a regression.
> > >
> > > I'm the maintainer of SQLite3 in Debian and can't reproduce it on
> > > AMD64. Even if I've a local mailbox, normal IMAP4 ones and some from
> > > GMail. OK, other than the updated SQLite3 library I run on a clean
> > > Jessie.
> > 
> > Our latest theory is that the problem only arises when /var/tmp runs out of
> > space.
> 
> That seems to be a reasonable theory. Looking at `~/.bash_history` I
> indeed cleaned up `/var/crash/1300`, where my core dump files are stored
> by corekeeper [1], and only downgraded to SQLite 3.8.7.1 afterward.
> 
> Upgrading to SQLite 3.8.7.4 again I am unable to reproduce the crash
> with 2 GB free space on the partition `/var`.
> 
> I’ll rebuild SQLite now with the fix applied [2] and try to reproduce
> the issue by filling up `/var` intentionally.

With still around 1.3 GB free on the partition mounted to `/var/`,
Evolution crashed with the f received the following segmentation fault
today.

0xb3f9af51 in sqlite3Strlen30 (z=0x18 ) at sqlite3.c:22902

Here is part of the backtrace.

Thread 54 (Thread 0xa24feb40 (LWP 3581)):
#0  0xb7fdcd3c in __kernel_vsyscall ()
No symbol table info available.
#1  0xb7cb5fdf in fsync () at ../sysdeps/unix/syscall-template.S:81
No locals.
#2  0xb3f9cde9 in full_fsync (fullSync=0, dataOnly=0, fd=) at sqlite3.c:28292
rc = 
#3  unixSync (id=0xa14e4b00, flags=2) at sqlite3.c:28381
rc = 
pFile = 0xa14e4b00
isDataOnly = 0
isFullsync = 0
#4  0xb7ad33d6 in call_old_file_Sync (flags=, 
cFile=) at camel-db.c:66
No locals.
#5  sync_request_thread_cb (task_data=0xa132c4d8, null_data=0x0) at 
camel-db.c:92
sync_data = 0xa132c4d8
done = 
#6  0xb52d7e64 in g_thread_pool_thread_proxy (data=0x81a73958) at 
/build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gthreadpool.c:307
task = 0xa132c4d8
#7  0xb52d73da in g_thread_proxy (data=0x890b0230) at 
/build/glib2.0-EvFudu/glib2.0-2.42.1/./glib/gthread.c:764
No locals.
#8  0xb7caeefb in start_thread (arg=0xa24feb40) at pthread_create.c:309
__res = 
pd = 0xa24feb40
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {-1211363328, 
-1571820736, 4001536, -1571823064, -643453236, -742727961}, 
  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"
#9  0xb51a6dfe in clone () at 
../sysdeps/unix/sysv/linux/i386/clone.S:129
No locals.

Thread 53 (Thread 0xa7e04b40 (LWP 3576)):
#0  0xb3f9af51 in sqlite3Strlen30 (z=0x18 ) at sqlite3.c:22902
z2 = 0x18 
#1  sqlite3VXPrintf (pAccum=pAccum@entry=0xa7e03e30, 
bFlags=bFlags@entry=0, fmt=0xb400f0f8 "s", ap=0xa7e03e90 "\003") at 
sqlite3.c:21385
c = 
bufpt = 0x18 
precision = 
length = 
idx = 
width = 
flag_leftjustify = 0 '\000'
flag_plussign = 24 '\030'
flag_blanksign = 0 '\000'
flag_alternateform = 0 '\000'
flag_altform2 = 0 '\000'
flag_zeropad = 0 '\000'
flag_long = 0 '\000'
flag_longlong = 0 '\000'
done = 
xtype = 6 '\006'
bArgList = 0 '\000'
useIntern = 0 '\000'
prefix = 
longvalue = 
realvalue = 
infop = 
zOut = 
nOut = 
zExtra = 0x0
exp = 
e2 = 
nsd = 
rounder = 
flag_dp = 
flag_rtz = 
pArgList = 0x0
buf = 
"\203\210,\000\000\000\066W+\265\001\000\000\000$\000\000\000\271\231\264\267\234\361)\265\003\000\000\000(\034\021\254\020\000\020\254\000@&\265\020\000\020\254\220\302\021\254\210(\253\201\214\022\023\265\310W\247\201E\n\270\251\371M(\265"
#2  0xb3f9b7d5 in sqlite3_vsnprintf (n=512, zBuf=0xa7e03e9b "\265", 
zFormat=0xb400f0f7 "%s", ap=0xa7e03e8c "\030") at sqlite3.c:21731

Re: [sqlite] Bus error with Evolution 3.12.9 and SQLite 3.8.7.4

2014-12-30 Thread Paul Menzel

Am Dienstag, den 30.12.2014, 08:21 -0500 schrieb Richard Hipp:
> On Mon, Dec 29, 2014 at 10:37 AM, László Böszörményi (GCS) wrote:

> > > it’s not obvious that these might cause such a regression.
> >
> > I'm the maintainer of SQLite3 in Debian and can't reproduce it on
> > AMD64. Even if I've a local mailbox, normal IMAP4 ones and some from
> > GMail. OK, other than the updated SQLite3 library I run on a clean
> > Jessie.
> 
> Our latest theory is that the problem only arises when /var/tmp runs out of
> space.

That seems to be a reasonable theory. Looking at `~/.bash_history` I
indeed cleaned up `/var/crash/1300`, where my core dump files are stored
by corekeeper [1], and only downgraded to SQLite 3.8.7.1 afterward.

Upgrading to SQLite 3.8.7.4 again I am unable to reproduce the crash
with 2 GB free space on the partition `/var`.

I’ll rebuild SQLite now with the fix applied [2] and try to reproduce
the issue by filling up `/var` intentionally.

Thank you for the awesome support so far!

Thanks,

Paul

[1] https://packages.debian.org/corekeeper
[2] https://www.sqlite.org/src/info/776648412c30dce206f1024ff849c2cb025bb006

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] Bus error with Evolution 3.12.9 and SQLite 3.8.7.4

2014-12-30 Thread Paul Menzel

Am Montag, den 29.12.2014, 16:37 +0100 schrieb László Böszörményi (GCS):
> On Mon, Dec 29, 2014 at 2:09 PM, Paul Menzel wrote:
> > using Debian Sid/unstable and upgrading from libsqlite3-0 3.8.7.2 to
> > 3.8.7.4, Evolution 3.12.9 started to crash with a bus error [1].
>
> Just for the record, do you have an Intel or AMD type of CPU?

My CPU model is AMD E-350D APU with Radeon(tm) HD Graphics. I am using a
32-bin Linux kernel and userspace.

$ uname -m
i686

[…]


Thanks,

Paul


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

[sqlite] Bus error with Evolution 3.12.9 and SQLite 3.8.7.4

2014-12-29 Thread Paul Menzel

Dear Evolution and SQLite folks,


using Debian Sid/unstable and upgrading from libsqlite3-0 3.8.7.2 to
3.8.7.4, Evolution 3.12.9 started to crash with a bus error [1].

After downgrading to SQLite 3.8.7.1 from Debian Jessie/testing I was
unable to reproduce the issue.

Looking at the changelog [2]

2014-12-09 (3.8.7.4)
  * Bug fix: Add in a mutex that was omitted from the previous
release.
  * SQLITE_SOURCE_ID: "2014-12-09 01:34:36
f66f7a17b78ba617acde90fc810107f34f1a1f2e"
  * SHA1 for sqlite3.c: 0a56693a3c24aa3217098afab1b6fecccdedfd23

2014-12-06 (3.8.7.3)
  * Bug fix: Ensure the cached KeyInfo objects (an internal
abstraction not visible to the application) do not go stale when
operating in shared cache mode and frequently closing and
reopening some database connections while leaving other database
connections on the same shared cache open continuously. Ticket
e4a18565a36884b00edf.
  * Bug fix: Recognize that any column in the right-hand table of a
LEFT JOIN can be NULL even if the column has a NOT NULL
constraint. Do not apply optimizations that assume the column is
never NULL. Ticket 6fd550f5b0ee7ed.
  * SQLITE_SOURCE_ID: "2014-12-05 22:29:24
647e77e853e81a5effeb4c33477910400a67ba86"
  * SHA1 for sqlite3.c: 3ad2f5ba3a4a3e3e51a1dac9fda9224b359f0261

it’s not obvious that these might cause such a regression.

Please find the backtraces attached to the bug reported in the GNOME
Bugzilla [1].


Thanks,

Paul


PS: I have not submitted a bug report to the Debian BTS yet, as I do not
know if it is a bug in Evolution or SQLite 3 and I want to avoid a false
assignment as done by myself in [3].


[1] https://bugzilla.gnome.org/show_bug.cgi?id=742080
[2] http://www.sqlite.org/changes.html
[3] 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

2014-10-25 Thread 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

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

2014-10-22 Thread 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

2014-10-22 Thread 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] Best practices for Valgrind

2012-12-05 Thread Paul Menzel

Dear SQLite folks,


using Debian Sid/unstable with SQLite 3.7.14.1-1, running the WebKit
based browser Midori 0.4.7+ from master branch (7567058e) [1] under
Valgrind to analyze WebKit 1.8.1 though, I see a lot of the following.

==31797== 64,008 bytes in 1 blocks are possibly lost in loss record 
10,807 of 10,810
==31797==at 0x48288D8: malloc (vg_replace_malloc.c:270)
==31797==by 0x5279F4A: sqlite3MemMalloc (sqlite3.c:15436)
==31797==by 0x525519D: mallocWithAlarm (sqlite3.c:18734)
==31797==by 0x525D336: sqlite3Malloc (sqlite3.c:18767)
==31797==by 0x5263C7D: setupLookaside.part.209 (sqlite3.c:112140)
==31797==by 0x52A68D8: openDatabase (sqlite3.c:112119)
==31797==by 0x52A6EB1: sqlite3_open16 (sqlite3.c:114103)
==31797==by 0x5BA470C: 
WebCore::SQLiteFileSystem::openDatabase(WTF::String const&, sqlite3**, bool) 
(in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==31797==by 0x5BA2DBC: WebCore::SQLiteDatabase::open(WTF::String 
const&, bool) (in /usr/lib/libwebkitgtk-1.0.so.0.13.2)
==31797==by 0x5A37023: 
WebCore::IconDatabase::iconDatabaseSyncThread() (in 
/usr/lib/libwebkitgtk-1.0.so.0.13.2)
==31797==by 0x5A371DA: 
WebCore::IconDatabase::iconDatabaseSyncThreadStart(void*) (in 
/usr/lib/libwebkitgtk-1.0.so.0.13.2)
==31797==by 0x6CA6A41: WTF::threadEntryPoint(void*) (in 
/usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==31797==by 0x6CA6BAD: WTF::wtfThreadEntryPoint(void*) (in 
/usr/lib/libjavascriptcoregtk-1.0.so.0.13.2)
==31797==by 0x710378D: clone (clone.S:130)
==31797== 
==31797== 64,008 bytes in 1 blocks are possibly lost in loss record 
10,808 of 10,810
==31797==at 0x48288D8: malloc (vg_replace_malloc.c:270)
==31797==by 0x5279F4A: sqlite3MemMalloc (sqlite3.c:15436)
==31797==by 0x525519D: mallocWithAlarm (sqlite3.c:18734)
==31797==by 0x525D336: sqlite3Malloc (sqlite3.c:18767)
==31797==by 0x5263C7D: setupLookaside.part.209 (sqlite3.c:112140)
==31797==by 0x52A68D8: openDatabase (sqlite3.c:112119)
==31797==by 0x1484DD: midori_history_new (in /usr/bin/midori)
==31797==by 0x14785A: midori_normal_app_new (in /usr/bin/midori)
==31797==by 0x12C422: main (in /usr/bin/midori)
==31797== 
==31797== 64,008 bytes in 1 blocks are possibly lost in loss record 
10,809 of 10,810
==31797==at 0x48288D8: malloc (vg_replace_malloc.c:270)
==31797==by 0x5279F4A: sqlite3MemMalloc (sqlite3.c:15436)
==31797==by 0x525519D: mallocWithAlarm (sqlite3.c:18734)
==31797==by 0x525D336: sqlite3Malloc (sqlite3.c:18767)
==31797==by 0x5263C7D: setupLookaside.part.209 (sqlite3.c:112140)
==31797==by 0x52A68D8: openDatabase (sqlite3.c:112119)
==31797==by 0x1890D5: katze_http_cookies_sqlite_open_db (in 
/usr/bin/midori)
==31797==by 0x1892D4: katze_http_cookies_sqlite_attach (in 
/usr/bin/midori)
==31797==by 0x4A1F87A: soup_session_feature_attach (in 
/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0)
==31797==by 0x4A1CD33: soup_session_add_feature (in 
/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0)
==31797==by 0x157F04: midori_load_soup_session_full (in 
/usr/bin/midori)
==31797==by 0x48FD18F: g_idle_dispatch (gmain.c:4657)
==31797==by 0x48FF6D2: g_main_context_dispatch (gmain.c:2539)
==31797==by 0x48FFA6F: g_main_context_iterate.isra.21 (gmain.c:3146)
==31797==by 0x48FFECA: g_main_loop_run (gmain.c:3340)
==31797==by 0x7044E45: (below main) (libc-start.c:228)

I am guessing Valgrind is confused by SQLite’s memory allocator and
therefore these can be ignored. Do you have some Valgrind suppression
files to be used with SQLite using programs like PyGObject has [1]?


Thanks and sorry if I wrote nonsense,

Paul


[1] http://www.midori-browser.org
[2] https://mail.gnome.org/archives/commits-list/2010-December/msg11251.html


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] Bug: Segmentation fault in libsqlite3.so.0.8.6[b69a4000+ac000]

2012-12-04 Thread Paul Menzel

Am Sonntag, den 02.12.2012, 22:49 +0100 schrieb Paul Menzel:

> using Debian Sid/unstable with self-built Evolution 3.4.4 and
> libsqlite3-0 3.7.14.1-1, Evolution crashed with a segmentation fault.
> 
> pool[15522]: segfault at 5 ip b69bafe3 sp 8acf0850 error 6 in 
> libsqlite3.so.0.8.6[b69a4000+ac000]

After doing `apt-get source sqlite3` and building it myself with
`debuild -b -us -uc`, I have the source file `sqlite3.c` and I am able
to look at the code statements.

> The backtrace from the core dump file is the following.
> 
> Thread 1 (Thread 0x8acf1b70 (LWP 15522)):
> #0  0xb69bafe3 in pcache1Fetch (p=0xb8effb00, iKey=35985, 
> createFlag=2) at sqlite3.c:36093
> h = 1169
> nPinned = 
> pCache = 0xb8effb00
> pGroup = 0xb8effb30
> pPage = 0xbf8ab0e8

The following code caused the segmentation fault.

36093   *(void **)pPage->page.pExtra = 0;
(gdb) l
36088   pPage->iKey = iKey;
36089   pPage->pNext = pCache->apHash[h];
36090   pPage->pCache = pCache;
36091   pPage->pLruPrev = 0;
36092   pPage->pLruNext = 0;
36093   *(void **)pPage->page.pExtra = 0;
36094   pCache->apHash[h] = pPage;
36095 }
36096   
36097   fetch_out:
(gdb) p pPage
$1 = (PgHdr1 *) 0xbf8ab0e8
(gdb) p pPage->page.pExtra
$2 = (void *) 0x5
(gdb) info register
eax0x5  5
ecx0xb8effb30   -1192232144
edx0x4911169
ebx0xb6a51d3c   -1230693060
esp0x8acf0850   0x8acf0850
ebp0xb8effb00   0xb8effb00
esi0xbf8ab0e8   -1081429784
edi0xb8effb00   -1192232192
eip0xb69bafe3   0xb69bafe3 <pcache1Fetch+755>
eflags 0x10212  [ AF IF RF ]
cs 0x73 115
ss 0x7b 123
ds 0x7b 123
es 0x7b 123
fs 0x0  0
gs 0x33 51

As

*(void **)pPage->page.pExtra = 0;

is above my basic C knowledge, maybe somebody sees if there is a reason
for the segfault here. Otherwise Richard is probably right, that the
heap corruption is caused by some other program.


Thanks,

Paul


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] Bug: Segmentation fault in libsqlite3.so.0.8.6[b69a4000+ac000]

2012-12-04 Thread Paul Menzel

Dear SQLite folks,


Am Sonntag, den 02.12.2012, 22:49 +0100 schrieb Paul Menzel:

> using Debian Sid/unstable with self-built Evolution 3.4.4 and
> libsqlite3-0 3.7.14.1-1, Evolution crashed with a segmentation fault.
> 
> pool[15522]: segfault at 5 ip b69bafe3 sp 8acf0850 error 6 in 
> libsqlite3.so.0.8.6[b69a4000+ac000]
> 
> The backtrace from the core dump file is the following.
> 
> Thread 1 (Thread 0x8acf1b70 (LWP 15522)):
> #0  0xb69bafe3 in pcache1Fetch (p=0xb8effb00, iKey=35985, 
> createFlag=2) at sqlite3.c:36093
> h = 1169
> nPinned = 
> pCache = 0xb8effb00
> pGroup = 0xb8effb30
> pPage = 0xbf8ab0e8
> #1  0xb69b4a25 in sqlite3PcacheFetch (pCache=0xb8eeeb60, 
> pgno=pgno@entry=35985, createFlag=createFlag@entry=1, ppPage=ppPage@entry=
> 0x8acf092c) at sqlite3.c:34905
> pPage = 0x0
> pPgHdr = 0x0
> eCreate = 2
> #2  0xb69e6980 in sqlite3PagerAcquire (pPager=0xb8eeeaa0, 
> pgno=pgno@entry=35985, ppPage=ppPage@entry=0x8acf092c, 
> noContent=noContent@entry=0) at sqlite3.c:41989
> rc = 
> pPg = 
> #3  0xb69e6b3a in btreeGetPage (pBt=0xb8edef00, pgno=35985, 
> ppPage=ppPage@entry=0x8acf097c, noContent=noContent@entry=0) at 
> sqlite3.c:49488
> rc = 
> pDbPage = 0x140
> #4  0xb69f37f4 in getAndInitPage (pBt=, 
> pgno=, ppPage=0x8acf097c) at sqlite3.c:49541
> rc = 
> #5  0xb69f3866 in moveToChild (pCur=0x92140d50, newPgno= out>) at sqlite3.c:52106
> rc = 
> i = 1
> pNewPage = 
> pBt = 
> #6  0xb69f39ad in moveToLeftmost (pCur=0x92140d50) at sqlite3.c:52284
> rc = 
> pPage = 
> #7  0xb6a2dc8d in sqlite3VdbeExec (p=p@entry=0x921512b0) at 
> sqlite3.c:68025
> pc = 
> aOp = 0x92361a08
> pOp = 0x92361b98
> rc = 
> db = 
> resetSchemaOnFault = 
> encoding = 1 '\001'
> checkProgress = 0
> nProgressOps = 0
> aMem = 0x9235b050
> pIn1 = 
> pIn2 = 
> pIn3 = 
> pOut = 0x0
> iCompare = 
> aPermute = 
> lastRowid = 
> u = {aa = {pcDest = -1844179936}, ab = {cnt = -1844179936}, 
> ac = {pVar = 0x92140c20}, ad = {zMalloc = 0x92140c20 "P\r\024\222", 
> n = 0, p1 = -1966142271, p2 = 10}, ae = {pMem = 
> 0x92140c20, i = 0}, af = {nByte = 2450787360}, ag = {flags = -1844179936, 
> iA = -8444516753228169216, iB = 107374182410, rA = 
> -1.8091740329328587e-113, rB = -1.3866037848944667e-221}, ah = {
> i = -1844179936, pArg = 0x0, ctx = {pFunc = 0x8acf0cc1, 
> pVdbeFunc = 0xa, s = {db = 0x19, z = 0x92140c20 "P\r\024\222", 
> r = -1.3868233835305826e-221, u = {i = 
> -7920691651615126400, nZero = -1844179840, pDef = 0x92140c80, pRowSet = 
> 0x92140c80, 
>   pFrame = 0x92140c80}, n = 26, flags = 31, type = 0 
> '\000', enc = 0 '\000', xDel = 0xb69b7f84 <sqlite3_free+20>, 
> zMalloc = 0x0}, pMem = 0x1, pColl = 0x1, isError = 
> -1230693060, skipFlag = 10}, apVal = 0xb6a51d3c, n = -1230809131}, 
>   ai = {iA = 2450787360, uA = 45278497985, iB = 
> -7920692513059373031, op = 206 '\316'}, aj = {res = -1844179936, 
> affinity = 0 '\000', flags1 = 0, flags3 = 3265}, ak = {n 
> = -1844179936, i = 0, p1 = -1966142271, p2 = 10, pKeyInfo = 0x19, 
> idx = -1844179936, pColl = 0xa88646ce, bRev = 
> -1844179632}, al = {v1 = -1844179936, v2 = 0}, am = {c = -1844179936}, an = {
> payloadSize = 2450787360, payloadSize64 = 
> -8444516753228169216, p1 = 10, p2 = 25, pC = 0x92140c20, zRec = 
> 0xa88646ce 
> "\037\031\002\001\001\001\001\001\001\001\001\002\004\004\201!A3", pCrsr = 
> 0x92140d50, aType = 0x92140c80, aOffset = 
> 0x92140ce8, nField = 26, len = 31, i = -1231323260, zData = 0x0, 
> pDest = 0x1, sMem = {db = 0x1, z = 0xb6a51d3c ",\334\n", 
>   r = -1.8492057199714905e-45, u = {i = 
> -5288166510061987883, nZero = -1230809131, pDef = 0xb6a357d5, pRowSet = 
> 0xb6a357d5, 
> pFrame = 0xb6a357d5}, n = 0, flags = 0, type = 0 
> '\000',

[sqlite] Bug: Segmentation fault in libsqlite3.so.0.8.6[b69a4000+ac000]

2012-12-02 Thread Paul Menzel

Dear SQLite folks,


using Debian Sid/unstable with self-built Evolution 3.4.4 and
libsqlite3-0 3.7.14.1-1, Evolution crashed with a segmentation fault.

pool[15522]: segfault at 5 ip b69bafe3 sp 8acf0850 error 6 in 
libsqlite3.so.0.8.6[b69a4000+ac000]

The backtrace from the core dump file is the following.

Thread 1 (Thread 0x8acf1b70 (LWP 15522)):
#0  0xb69bafe3 in pcache1Fetch (p=0xb8effb00, iKey=35985, createFlag=2) 
at sqlite3.c:36093
h = 1169
nPinned = 
pCache = 0xb8effb00
pGroup = 0xb8effb30
pPage = 0xbf8ab0e8
#1  0xb69b4a25 in sqlite3PcacheFetch (pCache=0xb8eeeb60, 
pgno=pgno@entry=35985, createFlag=createFlag@entry=1, ppPage=ppPage@entry=
0x8acf092c) at sqlite3.c:34905
pPage = 0x0
pPgHdr = 0x0
eCreate = 2
#2  0xb69e6980 in sqlite3PagerAcquire (pPager=0xb8eeeaa0, 
pgno=pgno@entry=35985, ppPage=ppPage@entry=0x8acf092c, 
noContent=noContent@entry=0) at sqlite3.c:41989
rc = 
pPg = 
#3  0xb69e6b3a in btreeGetPage (pBt=0xb8edef00, pgno=35985, 
ppPage=ppPage@entry=0x8acf097c, noContent=noContent@entry=0) at sqlite3.c:49488
rc = 
pDbPage = 0x140
#4  0xb69f37f4 in getAndInitPage (pBt=, pgno=, ppPage=0x8acf097c) at sqlite3.c:49541
rc = 
#5  0xb69f3866 in moveToChild (pCur=0x92140d50, newPgno=) at sqlite3.c:52106
rc = 
i = 1
pNewPage = 
pBt = 
#6  0xb69f39ad in moveToLeftmost (pCur=0x92140d50) at sqlite3.c:52284
rc = 
pPage = 
#7  0xb6a2dc8d in sqlite3VdbeExec (p=p@entry=0x921512b0) at 
sqlite3.c:68025
pc = 
aOp = 0x92361a08
pOp = 0x92361b98
rc = 
db = 
resetSchemaOnFault = 
encoding = 1 '\001'
checkProgress = 0
nProgressOps = 0
aMem = 0x9235b050
pIn1 = 
pIn2 = 
pIn3 = 
pOut = 0x0
iCompare = 
aPermute = 
lastRowid = 
u = {aa = {pcDest = -1844179936}, ab = {cnt = -1844179936}, ac 
= {pVar = 0x92140c20}, ad = {zMalloc = 0x92140c20 "P\r\024\222", 
n = 0, p1 = -1966142271, p2 = 10}, ae = {pMem = 0x92140c20, 
i = 0}, af = {nByte = 2450787360}, ag = {flags = -1844179936, 
iA = -8444516753228169216, iB = 107374182410, rA = 
-1.8091740329328587e-113, rB = -1.3866037848944667e-221}, ah = {
i = -1844179936, pArg = 0x0, ctx = {pFunc = 0x8acf0cc1, 
pVdbeFunc = 0xa, s = {db = 0x19, z = 0x92140c20 "P\r\024\222", 
r = -1.3868233835305826e-221, u = {i = 
-7920691651615126400, nZero = -1844179840, pDef = 0x92140c80, pRowSet = 
0x92140c80, 
  pFrame = 0x92140c80}, n = 26, flags = 31, type = 0 
'\000', enc = 0 '\000', xDel = 0xb69b7f84 , 
zMalloc = 0x0}, pMem = 0x1, pColl = 0x1, isError = 
-1230693060, skipFlag = 10}, apVal = 0xb6a51d3c, n = -1230809131}, 
  ai = {iA = 2450787360, uA = 45278497985, iB = 
-7920692513059373031, op = 206 '\316'}, aj = {res = -1844179936, 
affinity = 0 '\000', flags1 = 0, flags3 = 3265}, ak = {n = 
-1844179936, i = 0, p1 = -1966142271, p2 = 10, pKeyInfo = 0x19, 
idx = -1844179936, pColl = 0xa88646ce, bRev = -1844179632}, 
al = {v1 = -1844179936, v2 = 0}, am = {c = -1844179936}, an = {
payloadSize = 2450787360, payloadSize64 = 
-8444516753228169216, p1 = 10, p2 = 25, pC = 0x92140c20, zRec = 
0xa88646ce 
"\037\031\002\001\001\001\001\001\001\001\001\002\004\004\201!A3", pCrsr = 
0x92140d50, aType = 0x92140c80, aOffset = 
0x92140ce8, nField = 26, len = 31, i = -1231323260, zData = 0x0, 
pDest = 0x1, sMem = {db = 0x1, z = 0xb6a51d3c ",\334\n", 
  r = -1.8492057199714905e-45, u = {i = 
-5288166510061987883, nZero = -1230809131, pDef = 0xb6a357d5, pRowSet = 
0xb6a357d5, 
pFrame = 0xb6a357d5}, n = 0, flags = 0, type = 0 
'\000', enc = 0 '\000', xDel = 0xa, zMalloc = 0x0}, zIdx = 
0xa88646eb "!!297611\001\020", zEndHdr = 0xa88646ed 
"297611\001\020", offset = 1302605444, szField = 0, szHdr = -1228328569, 
avail = 378, t = 3066643705, pReg = 0xb6cf37a3}, ao = 
{zAffinity = 0x92140c20 "P\r\024\222", cAff = 0 '\000'}, ap = {
zNewRecord = 0x92140c20 "P\r\024\222", pRec = 0x0, nData = 
45278497985, nHdr = 25, nByte = -6303272775430435808, 
nZero = -1844179632, nVarint = -1844179840, serial_type = 
2450787560, pData0 = 0x1a, pLast = 0x1f, nField = -1231323260,

[sqlite] list: Please allow signed messages.

2012-12-02 Thread Paul Menzel

Dear list administrators,


please allow signed messages to be sent to the list.

I got: »The message's content type was not explicitly allowed«


Thanks,

Paul


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

Re: [sqlite] Segfault with Evolution and patched SQLite 3.8.7.4

Re: [sqlite] Segfault with Evolution and patched SQLite 3.8.7.4 (was: Bus error with Evolution 3.12.9 and SQLite 3.8.7.4)

Re: [sqlite] Bus error with Evolution 3.12.9 and SQLite 3.8.7.4

Re: [sqlite] Bus error with Evolution 3.12.9 and SQLite 3.8.7.4

[sqlite] Bus error with Evolution 3.12.9 and SQLite 3.8.7.4

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

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

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

[sqlite] Best practices for Valgrind

Re: [sqlite] Bug: Segmentation fault in libsqlite3.so.0.8.6[b69a4000+ac000]

Re: [sqlite] Bug: Segmentation fault in libsqlite3.so.0.8.6[b69a4000+ac000]

[sqlite] Bug: Segmentation fault in libsqlite3.so.0.8.6[b69a4000+ac000]

[sqlite] list: Please allow signed messages.

13 matches

Site Navigation

Mail list logo

Footer information