Created attachment 422896 [details]
File: backtrace

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

One additional datapoint. I noticed after the fact that the vpn had dropped and I may have had a partial communication with a server or may have been reading email offline when this happened.

Thanks for a bug report. This [1] is a corresponding upstream bug, though it is closed due to lack of information without any fix. Are you able to reproduce this reliably with some steps? Maybe under valgrind? It seems to me like some kind of bad coincidence.

If you'll try with valgrind, please do also:
   $ export G_SLICE=always-malloc
before you run it.

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

no I'm not able to reproduce it in any reliable way. it seems to crop up periodically though. It has happened 2-3x.

The problem with using valgrind to try to capture it is that it makes evolution run as slow as a dog and trying to make day to day use of it when it under valgrind.

Can you look a bit more deeply at the backtraces and see if you can see something. I'm willing to take an instrumented build which supplies more of its own clues as to where the problem is.

Event posted on 2010-06-14 09:11 PDT by woodard

it might just coincidental but this message is frequently emitted on the
console when I'm working with evolution. Maybe if we can track down why
camel is emitting warnings and resolve that, maybe we can get to the root
cause of this problem.

(evolution:24562): camel-WARNING **: camel_exception_get_id called with
NULL parameter.




This event sent from IssueTracker by woodard 
 issue 1002573

Event posted on 06-14-2010 12:18pm EDT by kbaxley

I got the same thing as well, when trying to reproduce the crash using
valgrind.  Lots of the same messages that Ben is reporting, and valgrind
slowed to a point that evo is almost unusable.


This event sent from IssueTracker by kbaxley 
 issue 1002573

I have an additional clue. The crash seems to be related to the drop of the vpn. So the sequence of events seems to be. I'm over at one account that doesn't need a VPN, e.g. gmail and while I'm reading email over there. The vpn drops. Then I click on the account e.g. Red Hat which does require the VPN and there is a few second pause then poof. It is only then that I discover that the problem is that the VPN has dropped.

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

*** Bug 617005 has been marked as a duplicate of this bug. ***

Created attachment 433712 [details]
test patch

This is a test patch for evolution, which will print some useful debug information on console, because I was unable to reproduce this myself, dropping/connecting my vpn anyhow. I also built evolution test package for it [1], but it's only i386 version, thus probably unusable for you.

Anyway, with this patch, please run evolution always from console, can be like this:
   $ evolution &>evo.log

and use it like before. When it crashes with that camel_msgport_try_pop, then please place here evo.log, but as it's quite chatty then last not more than 100 lines should be sufficient. I suspect some line before the crash will contain "activity_state == 3" in it. Please give here also backtrace, where will be shown the address, so we can match it.

When you test this, and it'll show this line, then please run evolution again, but this time as this:
   $ BUG602667=1 evolution &>evo.log
and try to use it like before, the best if it'll play with your vpn, even that's nothing you can influence much, I know. Anyway, with this variable set it shouldn't crash, it should write to evo.log line containing "activity_state == 3, but didn't", which should proof the fix works. Please attach such log, because I want to check whether the memory is freed as expected.

Thanks in advance.

[1] http://madtux.brq.redhat.com/evolution/

Event posted on 07-22-2010 11:24am EDT by tgummels

Milan,

Would it be possible to have an x86_64 package built?  Customer is more
than willing to test it out, just need the right arch.

Thanks
Travis

Internal Status set to 'Waiting on Engineering'

This event sent from IssueTracker by tgummels 
 issue 1002573

Owen helped me how to build with brew, so here are packages available:
https://brewweb.devel.redhat.com/taskinfo?taskID=2619221

Note they will be automatically erased in a week or so. If you cannot get there, then I can copy them to my machine.

This moves to 6.1 unless we get imeediate feedback on the rebuilt package

New test packages are here:
https://brewweb.devel.redhat.com/taskinfo?taskID=2672996

This is evolution-2.28.3-10.el6 + Milan's test patch for this bug.

Created attachment 460771 [details]
evo patch

for evolution;

I tried to cheat the code a bit to test this and the change seems to be correct, when I remove this mail_msg_free call then evolution doesn't crash. Based on my test prints the msg structure seems to be properly freed, neither valgrind claims anything new.

With respect of reproducer steps:
I'm not aware of any exact steps to reproduce this, as this seems to be related to timing and some issues with the operation - the operation should be cancelled before it gets to the status bar.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

*** Bug 731928 has been marked as a duplicate of this bug. ***

*** Bug 845053 has been marked as a duplicate of this bug. ***

*** Bug 911075 has been marked as a duplicate of this bug. ***

evo crashed after search in email folder was started and computer was effectively offline, and evo was put offline manually in the process.

backtrace_rating: 4
Package: evolution-2.28.3-30.el6
OS Release: Red Hat Enterprise Linux Workstation release 6.4 (Santiago)

Created attachment 718224 [details]
File: backtrace

Marking this with DOCS_SCOPED - as this issue will not be documented in the Virtualization Administration Guide

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2013-1540.html