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 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


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=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