[sylpheed:36570] Re: Seg fault when reading directory with a large number of messages

[Rich Coe]

On Sun, 11 Jun 2017 19:02:51 -0700
Dennis Carr <dennisthetiger at chez-vrolet.net> wrote:
> On Wed, 7 Jun 2017 07:57:20 -0500
> Rich Coe <rcoe at wi.rr.com> wrote:
> 
> > On Sat, 3 Jun 2017 00:20:27 -0700
> > Dennis Carr <dennisthetiger at chez-vrolet.net> wrote:
> > > I have a folder of over 50,000 notification messages from Facebook
> > > from the years, and every time I access this folder of late I get a
> > > segmentation fault.  If I do 'sylpheed --debug' from the command
>  
> > (Rich's instructions on how to use gdb for this purpose have been
> > removed for brevity.)
> 
> I got this on crash:
> 
> Thread 1 "sylpheed" received signal SIGSEGV, Segmentation fault.
> 0x00007f1015c3bc8b in _int_malloc (av=av at entry=0x7f1015f5cb00
> <main_arena>, bytes=bytes at entry=4) at malloc.c:3387
> 3387	malloc.c: No such file or directory.
> 
> #0  0x00007f1015c3bc8b in _int_malloc (
>     av=av at entry=0x7f1015f5cb00 <main_arena>, bytes=bytes at entry=4)
>     at malloc.c:3387
> #1  0x00007f1015c3df34 in __GI___libc_malloc (bytes=4) at malloc.c:2928
> #2  0x00007f10161d2ec8 in g_realloc ()
>    from /lib/x86_64-linux-gnu/libglib-2.0.so.0
> #3  0x00007f1018aad26e in gtk_tree_path_append_index ()
>    from /usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0

A crash in malloc usually means that some code has overwritten it's boundries
and the structures that malloc uses to manage the heap have been corrupted.

I would use valgrind to find the culprit.

valgrind --tool=memcheck --error-limit=no --log-file=sylpheed.log sylpheed 

Sylpheed under valgrind is going to run a little slower than you are used to.
And it won't crash.  You'll need to go through the steps to reproduce the
problem and then exit sylpheed.

In the log, look for entries that say 'Invalid write of size X'.
Each entry will show where the overwrite occurs and where the block was
allocated, 'Address 0x-- is N bytes after a block of size M alloc'd'. 
There may be several entries at the beginning of the log about
'points to uninitialised byte(s)', those are going to be errors for a level
of analysis you are not interested in.

Here's an example entry:
==16988== Invalid write of size 1
==16988==    at 0x4C32647: __stpcpy_sse2_unaligned (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16988==    by 0x1A04F8: strcat (string3.h:147)
==16988==    by 0x1A04F8: LoadPNG (xvpng.c:1162)
==16988==    by 0x124F98: openPic (xv.c:2520)
==16988==    by 0x11DD5C: openFirstPic (xv.c:3666)
==16988==    by 0x11DD5C: mainLoop (xv.c:3785)
==16988==    by 0x11DD5C: main (xv.c:1043)
==16988==  Address 0x7953d9a is 15 bytes after a block of size 11 alloc'd
==16988==    at 0x4C2C0AF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==16988==    by 0x1A045C: LoadPNG (xvpng.c:1154)
==16988==    by 0x124F98: openPic (xv.c:2520)
==16988==    by 0x11DD5C: openFirstPic (xv.c:3666)
==16988==    by 0x11DD5C: mainLoop (xv.c:3785)
==16988==    by 0x11DD5C: main (xv.c:1043)

Rich
-- 
Rich Coe     rcoe at wi.rr.com