Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0
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
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
[Evolution-hackers] Regular core dumps in Evo 3.6.0
Hi all; I'm using Evolution 3.6.0 in GNU/Linux Mint 14 with Cinnamon as
the desktop.
I'm using IMAP+ to access 3 different IMAP accounts: two Google accounts
and one normal IMAP (from my ISP; I think using Dovecot).
I'm finding that I'm getting core dumps in Evolution fairly often: once
every couple of days (from SIGTRAP?), 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).
I realize that I'm not using the latest (it really bugs me how the
standard distributions never seem to bother to package the Gnome point
releases :-/). Is it worthwhile sending along backtraces (I've
installed the evolution-dbg packages at least)?
Should I just build my own latest versions? In the past (but this was
Gnome 2.x) I've had problems with this: confusing dbus between the
different installations, etc. Maybe this is more cleanly supported now?
Cheers!
Just FYI, I'll include the stack trace of the reproducible core, on a
particular email; unfortunately the libcamel library doesn't seem to
have a debug package available:
(gdb) bt full
#0 __memcpy_ssse3_back () at
../sysdeps/x86_64/multiarch/memcpy-ssse3-back.S:1432
No locals.
#1 0x7f1cffb264ee in memcpy (__len=optimized out, __src=0x7f1cb811a7c0,
__dest=optimized out) at /usr/include/x86_64-linux-gnu/bits/string3.h:52
No locals.
#2 g_array_append_vals (farray=farray@entry=0x7f1cdc00b730,
data=0x7f1cb811a7c0, len=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=optimized out, len=optimized out) at
/build/buildd/glib2.0-2.34.1/./glib/garray.c:1639
No locals.
#4 0x7f1d0266916a in ?? () from /usr/lib/libcamel-1.2.so.40
No symbol table info available.
#5 0x7f1d0266a3da in camel_stream_write () from /usr/lib/libcamel-1.2.so.40
No symbol table info available.
#6 0x7f1ce56504a8 in emfe_text_html_format (extension=0x7f1d05d97e80,
formatter=0x7f1cb8124600, context=0x7f1cb81252d0, part=0x7f1cb812a040,
stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at
e-mail-formatter-text-html.c:328
uri = 0x7f1cb811b660
mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2
str = 0x7f1cb811a7c0 div class=\part-container-nostyle\iframe
width=\100%\ height=\10\ frameborder=\0\
src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\
id...
#7 0x7f1ce5648a55 in e_mail_formatter_format_as
(formatter=formatter@entry=0x7f1cb8124600,
context=context@entry=0x7f1cb81252d0, part=part@entry=0x7f1cb812a040,
stream=stream@entry=0x7f1cb8109d20, as_mime_type=optimized out,
cancellable=cancellable@entry=0x7f1d062b2f80) at e-mail-formatter.c:951
extension = optimized out
reg = 0x7f1ca805ef40
formatters = optimized out
iter = 0x7f1d05d97ec0
ok = 0
__PRETTY_FUNCTION__ = e_mail_formatter_format_as
#8 0x7f1ce5648d19 in mail_formatter_run (formatter=0x7f1cb8124600,
context=0x7f1cb81252d0, stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at
e-mail-formatter.c:124
part = 0x7f1cb812a040
ok = optimized out
iter = 0x7f1cb81265b0
hdr = optimized out
#9 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 = optimized out
__PRETTY_FUNCTION__ = e_mail_formatter_format_sync
#10 0x7f1ce5d092c0 in handle_mail_request (res=0x7f1d06213900,
object=optimized out, cancellable=0x7f1d062b2f80) at e-mail-request.c:144
request = 0x7f1d0622a190
stream = optimized out
formatter = 0x7f1cb8124600
part_list = 0x7f1cb8124540
registry = optimized out
ba = optimized out
part_id = 0x0
val = optimized out
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=0headers_collapsable=1headers_collapsed=0}
__PRETTY_FUNCTION__ = handle_mail_request
#11 0x7f1d000bde3e in run_in_thread (job=optimized out, c=0x7f1d062b2f80,
_data=0x7f1d0625c7d0) at
/build/buildd/glib2.0-2.34.1/./gio/gsimpleasyncresult.c:869
data = 0x7f1d0625c7d0
simple = 0x7f1d06213900
source = optimized out
#12 0x7f1d000ac236 in io_job_thread (data=0x7f1d062b4970,
user_data=optimized out) at
/build/buildd/glib2.0-2.34.1/./gio/gioscheduler.c:162
job =
Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0
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
Re: [Evolution-hackers] Regular core dumps in Evo 3.6.0
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=optimized out, __src=0x7f1cb811a7c0, __dest=optimized out) 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 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., len=len@entry=387) at /build/buildd/glib2.0-2.34.1/./glib/garray.c:1639 No locals. #4 0x7f1d0266916a in stream_mem_write (stream=optimized out, buffer=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., n=387, cancellable=optimized out, error=optimized out) at camel-stream-mem.c:131 priv = 0x7f1cb8109d60 nwrite = 387 #5 0x7f1d0266a3da in camel_stream_write (stream=stream@entry=0x7f1cb8109d20, buffer=buffer@entry=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., n=387, cancellable=cancellable@entry=0x7f1d062b2f80, error=error@entry=0x0) at camel-stream.c:158 class = 0x7f1c9c003e10 n_bytes = optimized out __PRETTY_FUNCTION__ = camel_stream_write #6 0x7f1d0266a991 in camel_stream_write_string (stream=stream@entry=0x7f1cb8109d20, string=string@entry=0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id..., cancellable=cancellable@entry=0x7f1d062b2f80, error=error@entry=0x0) at camel-stream.c:265 __PRETTY_FUNCTION__ = camel_stream_write_string #7 0x7f1ce56504a8 in emfe_text_html_format (extension=0x7f1d05d97e80, formatter=0x7f1cb8124600, context=0x7f1cb81252d0, part=0x7f1cb812a040, stream=0x7f1cb8109d20, cancellable=0x7f1d062b2f80) at e-mail-formatter-text-html.c:328 uri = 0x7f1cb811b660 mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2 str = 0x7f1cb811a7c0 div class=\part-container-nostyle\iframe width=\100%\ height=\10\ frameborder=\0\ src=\mail://1357328483.21150.3/pdsdesk/INBOX/183?part_id=.message.alternative-prefer-plain.2.text_htmlmode=2\ id... #8 0x7f1ce5648a55 in e_mail_formatter_format_as (formatter=formatter@entry=0x7f1cb8124600, context=context@entry=0x7f1cb81252d0, part=part@entry=0x7f1cb812a040, stream=stream@entry=0x7f1cb8109d20, as_mime_type=optimized out, cancellable=cancellable@entry=0x7f1d062b2f80) at e-mail-formatter.c:951 extension = optimized out reg = 0x7f1ca805ef40 formatters = optimized out 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 = optimized out iter = 0x7f1cb81265b0 hdr = optimized out #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
