Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0

2013-01-30 Thread Paul Smith
On Wed, 2013-01-23 at 13:05 -0500, Paul Smith wrote:
> I did file a bug (sorry I forgot to post that here).  But today I used
> jhbuild to create a local Evo 3.6.4 and tried that, and it worked fine
> so that bug has been fixed since 3.6.0 was released and I resolved the
> bug again.

FYI my distro released a new version of Evolution (3.6.2) and I upgraded
to that and tested it and this issue is not seen there either.  And, I
get back my theme support so that's nice...

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0

2013-01-23 Thread Paul Smith
On Mon, 2013-01-21 at 14:51 -0500, Paul Smith wrote:
> On Mon, 2013-01-21 at 20:35 +0100, Milan Crha wrote:
> > Yeah, I also think the backend doesn't matter. It'll be good to save
> > the message as mbox, strip private information from it and share it at
> > [1], which seems to be the same crash, I only wasn't able to find the
> > message or otherwise reproduce it again.
> 
> OK, I'll try to do this.

I did file a bug (sorry I forgot to post that here).  But today I used
jhbuild to create a local Evo 3.6.4 and tried that, and it worked fine
so that bug has been fixed since 3.6.0 was released and I resolved the
bug again.

The new Evo seems to work great, but it doesn't use any of my local
desktop theming since I installed it into /opt/gnome (?).  So it looks
somewhat clunky and old-school with the base theming and icons.
However, it works better and that's more important to me than having it
look pretty :-).  The only really annoying thing is that when I use
mouse selection, I get black foreground AND background resulting in
unreadable selected text.  If anyone knows how to fix that I'd
appreciate it.


I did note with interest the recently-reported possibility of Ubuntu
moving to a "rolling release" model in between the Long Term Support
releases.  If they did that I wonder if they could be convinced to
package the Gnome point releases as they come out.  That would be a huge
advantage (to me anyway).

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers


Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0

2013-01-21 Thread Paul Smith
Hi Milan;

On Mon, 2013-01-21 at 20:35 +0100, Milan Crha wrote:
> Yeah, I also think the backend doesn't matter. It'll be good to save
> the message as mbox, strip private information from it and share it at
> [1], which seems to be the same crash, I only wasn't able to find the
> message or otherwise reproduce it again.

OK, I'll try to do this.  The problem is that that I can't display the
email at all in the preview buffer; if I even select the message Evo
immediately dumps core.  So saving it is a challenge.  I'll try turning
off the preview pane and see if I can select and save it that way.

You're right about the libcamel debug: there's a separate libcamel
package which doesn't have a debug variant, but when I installed the
debug package for evolution-data-server it gave me the debug info for
libcamel.


Thanks!


In case it matters, here's the trace with all debugging.  It doesn't
seem to be related to GMutex, but if it's a memory corruption who knows.

(gdb) bt full
#0  __memcpy_ssse3_back () at 
../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1432
No locals.
#1  0x7f1cffb264ee in memcpy (__len=, __src=0x7f1cb811a7c0, 
__dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
No locals.
#2  g_array_append_vals (farray=farray@entry=0x7f1cdc00b730, 
data=data@entry=0x7f1cb811a7c0, len=len@entry=387) at 
/build/buildd/glib2.0-2.34.1/./glib/garray.c:419
array = 0x7f1cdc00b730
__PRETTY_FUNCTION__ = "g_array_append_vals"
#3  0x7f1cffb27569 in g_byte_array_append (array=0x7f1cdc00b730, 
data=data@entry=0x7f1cb811a7c0 ", 
buffer=0x7f1cb811a7c0 ", error=) at 
camel-stream-mem.c:131
priv = 0x7f1cb8109d60
nwrite = 387
#5  0x7f1d0266a3da in camel_stream_write 
(stream=stream@entry=0x7f1cb8109d20, buffer=buffer@entry=0x7f1cb811a7c0 "
__PRETTY_FUNCTION__ = "camel_stream_write"
#6  0x7f1d0266a991 in camel_stream_write_string 
(stream=stream@entry=0x7f1cb8109d20, string=string@entry=0x7f1cb811a7c0 ", 
cancellable=cancellable@entry=0x7f1d062b2f80) at e-mail-formatter.c:951
extension = 
reg = 0x7f1ca805ef40
formatters = 
iter = 0x7f1d05d97ec0
ok = 0
__PRETTY_FUNCTION__ = "e_mail_formatter_format_as"
#9  0x7f1ce5648d19 in mail_formatter_run (formatter=0x7f1cb8124600, 
context=0x7f1cb81252d0, stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at 
e-mail-formatter.c:124
part = 0x7f1cb812a040
ok = 
iter = 0x7f1cb81265b0
hdr = 
#10 0x7f1ce56484e8 in e_mail_formatter_format_sync 
(formatter=0x7f1cb8124600, parts=0x7f1cb8124540, stream=0x7f1cb8109d20, 
flags=1, mode=E_MAIL_FORMATTER_MODE_NORMAL, cancellable=0x7f1d062b2f80) at 
e-mail-formatter.c:784
context = 0x7f1cb81252d0
formatter_class = 
__PRETTY_FUNCTION__ = "e_mail_formatter_format_sync"
#11 0x7f1ce5d092c0 in handle_mail_request (res=0x7f1d06213900, 
object=, cancellable=0x7f1d062b2f80) at e-mail-request.c:144
request = 0x7f1d0622a190
stream = 
formatter = 0x7f1cb8124600
part_list = 0x7f1cb8124540
registry = 
ba = 
part_id = 0x0
val = 
context = {message = 0x7f1d0608b810, folder = 0x7f1d057fa660, 
message_uid = 0x7f1cb8110d70 "183", parts = 0x7f1cb8126560, mode = 
E_MAIL_FORMATTER_MODE_NORMAL, flags = 1, uri = 0x7f1d0625a5c0 
"mail://1357328483.21150.3/pdsdesk/INBOX/183?mode=0&headers_collapsable=1&headers_collapsed=0"}
__PRETTY_FUNCTION__ = "handle_mail_request"
#12 0x7f1d000bde3e in run_in_thread (job=, c=0x7f1d062b2f80, 
_data=0x7f1d0625c7d0) at 
/build/buildd/glib2.0-2.34.1/./gio/gsimpleasyncresult.c:869
data = 0x7f1d0625c7d0
simple = 0x7f1d06213900
source = 
#13 0x7f1d000ac236 in io_job_thread (data=0x7f1d062b4970, 
user_data=) at 
/build/buildd/glib2.0-2.34.1/./gio/gioscheduler.c:162
job = 0x7f1d062b4970
result = 
#14 0x7f1cffb74e62 in g_thread_pool_thread_proxy (data=) at 
/build/buildd/glib2.0-2.34.1/./glib/gthreadpool.c:309
task = 0x7f1d062b4970
pool = 0x7f1d058d5550
#15 0x7f1cffb74645 in g_thread_proxy (data=0x7f1d05c822d0) at 
/build/buildd/glib2.0-2.34.1/./glib/gthread.c:797
thread = 0x7f1d05c822d0
#16 0x7f1cff8f3e9a in start_thread (arg=0x7f1cccf4a700) at 
pthread_create.c:308
__res = 
pd = 0x7f1cccf4a700
now = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 3801891934299807951, 
140736017219120, 139761674398144, 0, 3, -3820581376097460017, 
-3820469151749840689}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 
0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}}
not_first_call = 0
pagesize_m1 = 
sp = 
freesize = 
__PRETTY_FUNCTION__ = "start_thread"
#17 0x7f1cff620cbd in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:112
No locals.
#18 0x in ?? ()
No symbol table info available.


___

Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0

2013-01-21 Thread Milan Crha
On Mon, 2013-01-21 at 13:11 -0500, Paul Smith wrote:
> I'm finding that I'm getting core dumps in Evolution fairly often: once
> every couple of days (from SIGTRAP?)

Hi,
that might be due to memory leak in 3.6.0. The 3.6.1 is better on it,
the 3.6.2 too, and the 3.6.3 will be released in about a day or so,
which would be preferred to use the 3.6.3, with all its fixes from 3.6.0
till now.

> and I can also get Evo to dump
> core (with SIGSEGV) every time I visit a particular email (received
> through one of the Google accounts, but the dump appears to happen in
> the display engine so the backend is probably not relevant).

Yeah, I also think the backend doesn't matter. It'll be good to save the
message as mbox, strip private information from it and share it at [1],
which seems to be the same crash, I only wasn't able to find the message
or otherwise reproduce it again.

By the way, the camel library resides in evolution-data-server, which I
guess is the reason why you do not have debug info for it.

With respect of compilation I do not know, maybe if you can just rebuild
the packages with more recent sources, and install those, then it'll
work as well? It does for Fedora, at least.
Bye,
Milan

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

___
evolution-hackers mailing list
evolution-hackers@gnome.org
To change your list options or unsubscribe, visit ...
https://mail.gnome.org/mailman/listinfo/evolution-hackers