After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 557613 - evolution crashed with SIGSEGV in try_open_e_book_cb()
evolution crashed with SIGSEGV in try_open_e_book_cb()
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Contacts
2.28.x (obsolete)
Other Linux
: Urgent critical
: ---
Assigned To: evolution-addressbook-maintainers
Evolution QA team
: 558281 578780 580806 582472 583774 584280 584906 587107 587919 588749 589577 589966 590115 590123 591160 591179 591717 592266 592553 593265 593670 593827 593914 593984 594159 594590 595046 595140 595168 595423 595815 596574 596594 596610 597658 597753 597897 598080 598398 598886 598894 599062 599915 600024 600966 601062 601994 603624 604030 604147 604400 604609 605482 605521 606114 607038 608567 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-10-23 14:01 UTC by Sebastien Bacher
Modified: 2011-01-03 04:19 UTC
See Also:
GNOME target: 2.28.x
GNOME version: 2.27/2.28


Attachments
Proposed patch (1.25 KB, patch)
2008-10-23 15:38 UTC, Matthew Barnes
none Details | Review
Revised patch (1.65 KB, patch)
2008-10-24 14:01 UTC, Matthew Barnes
none Details | Review
Revised patch (1.27 KB, patch)
2008-10-25 15:52 UTC, Matthew Barnes
committed Details | Review
proposed evo hack (3.46 KB, patch)
2009-05-15 17:30 UTC, Milan Crha
none Details | Review
Alternative hack (3.37 KB, patch)
2009-06-29 08:52 UTC, Michel Dänzer
reviewed Details | Review
set flag after confirming the operation is cancelled. (743 bytes, patch)
2009-10-01 10:50 UTC, Chenthill P
accepted-commit_now Details | Review
check with the right enum value [only for master] (740 bytes, patch)
2009-10-01 10:56 UTC, Chenthill P
committed Details | Review

Description Sebastien Bacher 2008-10-23 14:01:54 UTC
The bug has been opened on https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/287136

"While starting Evolution and it was refreshing my folders it crashed. I was switching messages at the time that it crashed. 

  • #0 pthread_mutex_lock
    from /lib/tls/i686/cmov/libpthread.so.0
  • #1 e_flag_set
    at e-flag.c line 83
  • #2 try_open_e_book_cb
    at em-utils.c line 2048
  • #3 emit_async_open_response
    at e-book.c line 2762
  • #4 g_idle_dispatch
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c line 4235
  • #5 IA__g_main_context_dispatch
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c line 2144
  • #6 g_main_context_iterate
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c line 2778
  • #7 IA__g_main_loop_run
    at /build/buildd/glib2.0-2.18.2/glib/gmain.c line 2986
  • #8 bonobo_main
    at bonobo-main.c line 311
  • #9 main
    at main.c line 689

The bug is new in 2.24.1 and due to the change on http://bugzilla.gnome.org/show_bug.cgi?id=364542
Comment 1 Sebastien Bacher 2008-10-23 14:04:29 UTC
not sure if that's the issue but the change has

"+	if (e_book_async_open (book, only_if_exists, try_open_e_book_cb, &data) != FALSE) {
+		e_flag_free (flag);
+		g_set_error (error, E_BOOK_ERROR, E_BOOK_ERROR_OTHER_ERROR, "Failed to call e_book_async_open.");
+		return FALSE;
+	}"

or try_open_e_book_cb() uses "e_flag_set (data->flag);" which can be done after the e_flag_free there
Comment 2 Sebastien Bacher 2008-10-23 14:05:57 UTC
the ubuntu bug already has 8 duplicates
Comment 3 Matthew Barnes 2008-10-23 15:02:29 UTC
I think I see a potential race here:

+	while (canceled = camel_operation_cancel_check (NULL), !canceled && !e_flag_is_set (flag)) {
+		GTimeVal wait;
+
+		g_get_current_time (&wait);
+		g_time_val_add (&wait, 250000); /* waits 250ms */
+
+		e_flag_timed_wait (flag, &wait);
+	}
+
+	e_flag_free (flag);
+
+	if (canceled) {
+		g_set_error (error, E_BOOK_ERROR, E_BOOK_ERROR_CANCELLED, "Operation has been canceled.");
+		e_book_cancel_async_op (book, NULL);
+		return FALSE;
+	}

If the Camel operation is cancelled, we (a) free the EFlag, and then (b) cancel the EBook operation.  In the time between (a) and (b), try_open_e_book_cb() may get called, whereby it would be attempting to set a free'd EFlag.

I'd recommend placing the e_flag_free() _after_ the block where we cancel the EBook operation.
Comment 4 Matthew Barnes 2008-10-23 15:38:09 UTC
Created attachment 121202 [details] [review]
Proposed patch

Haven't been able to reproduce the crash yet to test this if this fixes it, but either way it can't hurt.  Also, if try_open_e_book() fails we should emit the warning always.  Not just for debugging.
Comment 5 Guilherme Salgado 2008-10-23 23:40:45 UTC
I tried the attached patch and it didn't fix the problem.  I still get consistent crashes when opening the Preferences dialog (as detailed in https://bugs.launchpad.net/ubuntu/+source/evolution/+bug/287423).

I also added some debug statements which allow me to say that try_open_e_book was called once when evo was starting and that function ran to completion. Then, when I opened the Preferences window the function was called again, but the crash happened before the e_flag_free() call (at the end of that function) was reached.
Comment 6 Guilherme Salgado 2008-10-24 00:03:19 UTC
Could it be a bug on e_book_async_open?
Comment 7 Guilherme Salgado 2008-10-24 00:34:53 UTC
FWIW, I backed out the last change to addressbook/libebook/e-book.c (http://bzr-playground.gnome.org/evolution-data-server/trunk/revision/7751) in the hope that the bug could've been introduced there but it doesn't seem to be the case. I'm still getting consistent crashes.
Comment 8 Matthew Barnes 2008-10-24 02:15:49 UTC
I still haven't seen a backtrace that actually shows the segfault, so this is mostly guesswork.
Comment 9 Guilherme Salgado 2008-10-24 08:11:37 UTC
I followed the instructions on https://wiki.ubuntu.com/DebuggingProgramCrash to get the backtrace, but since I get constant segfaults I could try other things to get you one which actually shows the segfault.
Comment 10 Matthew Barnes 2008-10-24 14:01:22 UTC
Created attachment 121272 [details] [review]
Revised patch

Found another error in the logic.  try_open_e_book_cb() is still called when the EBook operation is cancelled, but by then try_open_e_book() has exited and the closure points to garbage.

try_open_e_book_cb() needs to check the status and return immediately if the status is CANCELLED, without touching the closure.
Comment 11 Guilherme Salgado 2008-10-25 15:23:35 UTC
Matthew,

Here's the output with the debug statements you asked me to add:
(evolution:19455): evolution-mail-WARNING **: try_open_e_book: Thread: 0x9d32be8
(evolution:19455): evolution-mail-WARNING **: Can't get contacts: Operation has been canceled.
(evolution:19455): evolution-mail-WARNING **: try_open_e_book_cb: Thread: 0x9644538
Segmentation fault

Also, when I added the return right after g_set_error() in try_open_e_book_cb() (as suggested by Sebastien), evo stopped crashing. But it also stopped displaying mails (the progress bar indicated the message was being formatted but the formatting would never finish).
Comment 12 Matthew Barnes 2008-10-25 15:43:16 UTC
Okay, that's consistent with what I've observed.  try_open_e_book_cb() always runs in Thread 1 because it's an idle callback (GTK main loop calls it when there are no higher priority tasks).  And try_open_e_book() is called from a different thread.  That's important because otherwise it would deadlock.

All of the backtraces I've seen show the application in try_open_e_book_cb() but not try_open_e_book(), which means try_open_e_book() has already exited.  That's bad news, because the closure for try_open_e_book_cb() is allocated on try_open_e_book()'s call stack.  If try_open_e_book() exits, the pointer to the closure becomes garbage and if the callback tries to use it (like say for calling e_flag_set()) then the application goes boom.

So that seems to be the key question for this bug: how is it that try_open_e_book() is exiting before try_open_e_book_cb() runs?
Comment 13 Matthew Barnes 2008-10-25 15:52:57 UTC
Created attachment 121349 [details] [review]
Revised patch

Guilherme, I had a thought after posting that last comment.

Back out all previous patches for this bug and try this one, if you would.
Comment 14 Guilherme Salgado 2008-10-25 19:52:29 UTC
The latest patch seems to fix it. I have tried opening the Preferences dialog at least 10 times and it hasn't crashed. Before, it would crash at least 50% of the time I opened it. I'll keep trying and will post an update on monday.

Thanks a lot, Matthew.
Comment 15 Srinivasa Ragavan 2008-11-02 17:07:57 UTC
Commit it Matt.
Comment 16 Matthew Barnes 2008-11-02 18:21:38 UTC
Committed to trunk (revision 36715) and gnome-2-24 (revision 36716).
Comment 17 Milan Crha 2008-11-19 16:20:25 UTC
*** Bug 558281 has been marked as a duplicate of this bug. ***
Comment 18 Milan Crha 2009-03-26 16:13:58 UTC
I see that this still can happen, unfortunately, though very rarely.
I see doing it this sequence:
   try_open_e_book: new data 0x7fc7fcff7220 and flag 0x7fc7fcf14b20
   try_open_e_book: canceled on flag 0x7fc7fcf14b20
   try_open_e_book: free data 0x7fc7fcff7220 and flag 0x7fc7fcf14b20
   try_open_e_book_cb: 0x7fc7fcff7220

Thus, even the cancel on the ebook is called, then the open callback is called anyway, accessing some freed memory.
Comment 19 Milan Crha 2009-04-06 19:03:18 UTC
Let's see how will this work with an eds-dbus, then recheck.
Comment 20 Akhil Laddha 2009-04-30 04:01:42 UTC
*** Bug 580806 has been marked as a duplicate of this bug. ***
Comment 21 Akhil Laddha 2009-04-30 04:02:30 UTC
last dupe in 2.26.1
Comment 22 Matthew Barnes 2009-04-30 11:32:29 UTC
Clarifying summary.  The problem is try_open_e_book_cb(), not e_flag_set().
Comment 23 Michel Dänzer 2009-05-09 11:22:10 UTC
I don't remember ever hitting this crash with 2.24, but I'm hitting it about once a day with 2.26.1.1. Is there any hope for fixing this in 2.26?
Comment 24 Michel Dänzer 2009-05-13 07:37:11 UTC
(In reply to comment #23)
> I don't remember ever hitting this crash with 2.24, but I'm hitting it about
> once a day with 2.26.1.1.

If I'm lucky that is, happened 3-4 times within 90 minutes today...

FWIW, one thing that seems to increase the chance of hitting it is being 'ahead of' message formatting, e.g. hitting the delete key or selecting a different message while the message is still being formatted.
Comment 25 Milan Crha 2009-05-15 17:30:24 UTC
Created attachment 134724 [details] [review]
proposed evo hack

for evolution;

It should be harder to reproduce with this hack, though I'm still waiting for the eds-dbus, as I hope it should fix it itself. But we support also 2.26, so this hack.
Comment 26 Michel Dänzer 2009-05-20 08:31:59 UTC
I'm running with the hack patch applied now, and it didn't crash once yesterday. So far, so good, I'll report back if I hit it again...
Comment 27 Gianluca Borello 2009-05-25 11:22:17 UTC
*** Bug 583774 has been marked as a duplicate of this bug. ***
Comment 28 Fabio Durán Verdugo 2009-05-30 14:21:24 UTC
*** Bug 584280 has been marked as a duplicate of this bug. ***
Comment 29 Michel Dänzer 2009-06-02 10:19:09 UTC
Unfortunately, I still seem to be hitting this crash with the patch.

I'm actually not sure it's still crashing in try_open_e_book_cb, since I don't have the evolution debugging symbols installed ATM, but the rest of the backtrace looks the same. The mutex pointer is NULL in __pthread_mutex_lock().
Comment 30 Milan Crha 2009-06-02 16:08:54 UTC
I wonder how you compile evolution, with a patch, and you do not have debug info there. I know you can turn that off when compiling, but somehow I suppose you do not have it turned off. Let's see with updated trace.
Comment 31 Michel Dänzer 2009-06-02 16:11:00 UTC
(In reply to comment #30)
> I wonder how you compile evolution, with a patch, and you do not have debug
> info there.

I'm using patched Debian packages, and I didn't have evolution-dbg installed.
Comment 32 Fabio Durán Verdugo 2009-06-05 12:45:50 UTC
*** Bug 584906 has been marked as a duplicate of this bug. ***
Comment 33 Akhil Laddha 2009-06-29 04:01:05 UTC
*** Bug 587107 has been marked as a duplicate of this bug. ***
Comment 34 Michel Dänzer 2009-06-29 08:52:04 UTC
Created attachment 137543 [details] [review]
Alternative hack

We're still crashing due to stale mutex pointers. This alternative patch avoids the problem in TryOpenEBookStruct itself by using just an atomic counter instead of the mutex; it may be slightly more robust, but I just still got a crash:

  • #6 __pthread_mutex_lock
    at pthread_mutex_lock.c line 51
  • #7 e_flag_set
    from /usr/lib/libedataserver-1.2.so.11
  • #8 try_open_e_book_cb
    at em-utils.c line 2056

To solve this, I guess the TryOpenEBookStruct access would need to be protected by a mutex in a longer lived data structure.
Comment 35 Milan Crha 2009-06-29 10:54:27 UTC
As I understand this, the main reason is the fact that the try_open_e_book_cb is called even after the ebook operation had been canceled. I hoped the eds-dbus will fix this too, as a side effect, but it seems we should take care of this even before.
Comment 36 Milan Crha 2009-07-02 14:58:17 UTC
Bad, I cannot reproduce this reliably on actual master. It happens from time to time, but not when I want, thus I cannot verify my previous hypothesis.
Comment 37 Fabio Durán Verdugo 2009-07-06 22:58:45 UTC
*** Bug 587919 has been marked as a duplicate of this bug. ***
Comment 38 Akhil Laddha 2009-07-16 09:28:26 UTC
*** Bug 588749 has been marked as a duplicate of this bug. ***
Comment 39 Milan Crha 2009-07-24 15:26:32 UTC
I just attached a patch to bug #397265 which rewrites these bits a bit. This can still happen, but if the first fetch survives, then the rest should be working properly onwards.
Comment 40 Michel Dänzer 2009-07-24 15:55:31 UTC
(In reply to comment #39)
> I just attached a patch to bug #397265 which rewrites these bits a bit. This
> can still happen, but if the first fetch survives, then the rest should be
> working properly onwards.

Sounds interesting, but the patch doesn't apply to 2.26.3.
Comment 41 Akhil Laddha 2009-07-27 03:35:19 UTC
*** Bug 589577 has been marked as a duplicate of this bug. ***
Comment 42 Milan Crha 2009-07-27 08:26:53 UTC
(In reply to comment #40)
> Sounds interesting, but the patch doesn't apply to 2.26.3.

Can be. It's created for git master.
Comment 43 Akhil Laddha 2009-07-28 11:49:50 UTC
*** Bug 589966 has been marked as a duplicate of this bug. ***
Comment 44 Fabio Durán Verdugo 2009-07-29 12:50:46 UTC
*** Bug 590123 has been marked as a duplicate of this bug. ***
Comment 45 André Klapper 2009-07-29 17:38:26 UTC
*** Bug 590115 has been marked as a duplicate of this bug. ***
Comment 46 André Klapper 2009-08-09 14:48:26 UTC
*** Bug 591160 has been marked as a duplicate of this bug. ***
Comment 47 André Klapper 2009-08-09 14:48:26 UTC
*** Bug 591179 has been marked as a duplicate of this bug. ***
Comment 48 Fabio Durán Verdugo 2009-08-13 22:50:28 UTC
*** Bug 591717 has been marked as a duplicate of this bug. ***
Comment 49 Akhil Laddha 2009-08-19 04:01:26 UTC
*** Bug 592266 has been marked as a duplicate of this bug. ***
Comment 50 André Klapper 2009-08-21 10:31:28 UTC
*** Bug 592553 has been marked as a duplicate of this bug. ***
Comment 51 Akhil Laddha 2009-08-28 03:56:04 UTC
*** Bug 593265 has been marked as a duplicate of this bug. ***
Comment 52 Akhil Laddha 2009-08-28 03:57:04 UTC
*** Bug 578780 has been marked as a duplicate of this bug. ***
Comment 53 Akhil Laddha 2009-09-01 04:23:24 UTC
*** Bug 593670 has been marked as a duplicate of this bug. ***
Comment 54 Akhil Laddha 2009-09-02 04:51:48 UTC
*** Bug 593827 has been marked as a duplicate of this bug. ***
Comment 55 Fabio Durán Verdugo 2009-09-02 15:14:08 UTC
*** Bug 593914 has been marked as a duplicate of this bug. ***
Comment 56 Akhil Laddha 2009-09-03 04:28:37 UTC
*** Bug 593984 has been marked as a duplicate of this bug. ***
Comment 57 Akhil Laddha 2009-09-04 18:41:06 UTC
*** Bug 594159 has been marked as a duplicate of this bug. ***
Comment 58 Akhil Laddha 2009-09-09 08:10:30 UTC
*** Bug 594590 has been marked as a duplicate of this bug. ***
Comment 59 Akhil Laddha 2009-09-14 04:34:07 UTC
*** Bug 595046 has been marked as a duplicate of this bug. ***
Comment 60 Fabio Durán Verdugo 2009-09-14 15:29:24 UTC
*** Bug 595140 has been marked as a duplicate of this bug. ***
Comment 61 Akhil Laddha 2009-09-15 03:33:52 UTC
*** Bug 595168 has been marked as a duplicate of this bug. ***
Comment 62 Michel Dänzer 2009-09-15 13:56:06 UTC
How many more duplicates will this report need to accumulate before something is done about it? :(
Comment 63 Akhil Laddha 2009-09-17 05:18:26 UTC
*** Bug 595423 has been marked as a duplicate of this bug. ***
Comment 64 Akhil Laddha 2009-09-22 04:27:01 UTC
*** Bug 595815 has been marked as a duplicate of this bug. ***
Comment 65 Sam Morris 2009-09-22 09:49:27 UTC
Bump the version to 2.27.9x, someone?
Comment 66 Fabio Durán Verdugo 2009-09-28 13:46:41 UTC
*** Bug 596574 has been marked as a duplicate of this bug. ***
Comment 67 Akhil Laddha 2009-09-29 04:15:53 UTC
*** Bug 596594 has been marked as a duplicate of this bug. ***
Comment 68 Akhil Laddha 2009-09-29 04:16:13 UTC
*** Bug 596610 has been marked as a duplicate of this bug. ***
Comment 69 Chenthill P 2009-10-01 10:50:00 UTC
Created attachment 144486 [details] [review]
set flag after confirming the operation is cancelled.

It would be nice if someone try this patch to see if it fixes the crash.
Comment 70 Chenthill P 2009-10-01 10:56:53 UTC
Created attachment 144487 [details] [review]
check with the right enum value  [only for master]
Comment 71 Michel Dänzer 2009-10-02 09:30:26 UTC
(In reply to comment #69)
> It would be nice if someone try this patch to see if it fixes the crash.

From quick testing, it appears that the patch may indeed fix the crash, but that the preview pane hangs with 'Formatting Message...' instead - bug 568332 again?
Comment 72 Michel Dänzer 2009-10-02 10:20:49 UTC
Already encountered another preview pane hang, though different this time - an old message was being displayed, and the status bar was spinning with 'Verifying message...' or so.

The preview pane hangs seem to occur more often than the crashes, so I'm afraid this cure seems worse than the disease.
Comment 73 Milan Crha 2009-10-06 10:37:49 UTC
Michel, do you have a backtrace of the hang, please? It'll help to catch the issue.
Comment 74 Michel Dänzer 2009-10-06 10:58:27 UTC
(In reply to comment #73)
> Michel, do you have a backtrace of the hang, please?

No sorry, and I've switched back to the hack patch now. Also, next week I'm going on vacation for the rest of the month, so I may not get around to getting a backtrace for a while.
Comment 75 Akhil Laddha 2009-10-07 11:18:59 UTC
*** Bug 597658 has been marked as a duplicate of this bug. ***
Comment 76 Akhil Laddha 2009-10-08 03:34:27 UTC
*** Bug 597753 has been marked as a duplicate of this bug. ***
Comment 77 Akhil Laddha 2009-10-12 04:04:19 UTC
*** Bug 597897 has been marked as a duplicate of this bug. ***
Comment 78 Akhil Laddha 2009-10-12 04:11:06 UTC
*** Bug 598080 has been marked as a duplicate of this bug. ***
Comment 79 Akhil Laddha 2009-10-15 02:45:54 UTC
*** Bug 598398 has been marked as a duplicate of this bug. ***
Comment 80 Fabio Durán Verdugo 2009-10-19 02:58:30 UTC
*** Bug 598886 has been marked as a duplicate of this bug. ***
Comment 81 Fabio Durán Verdugo 2009-10-19 11:25:44 UTC
*** Bug 598894 has been marked as a duplicate of this bug. ***
Comment 82 André Klapper 2009-10-21 16:09:00 UTC
*** Bug 599062 has been marked as a duplicate of this bug. ***
Comment 83 Chenthill P 2009-10-27 11:28:48 UTC
I also came across the hang as mentioned in comment #72, but eds should no trace of executing book_open. It looked like the response was somehow missed and evo was indefintely waiting. All the code paths were notifying the response though. So was not able to identify the real problem.

But with the fix for bug 397625, this does not happen as the addressbook is opened only once. 

Michel, it would be nice if you have a go with the patch at bug 397625 and let us know if its fixed. Atleast with my testing I don't face this crasher anymore.
Comment 84 Akhil Laddha 2009-10-29 03:55:13 UTC
*** Bug 599915 has been marked as a duplicate of this bug. ***
Comment 85 Akhil Laddha 2009-10-30 04:28:50 UTC
*** Bug 600024 has been marked as a duplicate of this bug. ***
Comment 86 Michel Dänzer 2009-11-05 14:35:06 UTC
(In reply to comment #83)
> Michel, it would be nice if you have a go with the patch at bug 397625 and let
> us know if its fixed. Atleast with my testing I don't face this crasher
> anymore.

I've been running with commit 57712e8456024c5be983f1d934a648034e577208 from the gnome-2-28 branch on top of 2.28.1, and it's looking good so far - not a single crash yet, even though I'm not trying to avoid the problem.

Of course, given the random component of the crashes, it'll take some time to gain confidence it's really fixed. But for now I think we can assume it is, and I'll report back if I hit a crash again.
Comment 87 Chenthill P 2009-11-06 09:30:06 UTC
Michel, Thanks for the feedback. Am closing this bug now, if you face it again, please re-open the same.
Comment 88 Milan Crha 2009-11-06 09:49:24 UTC
Actually, I saw this recently, couple times on start. It either crashes or survives (and it luckily usually survives). There needs to be done something more.
Comment 89 Fabio Durán Verdugo 2009-11-06 14:20:38 UTC
*** Bug 600966 has been marked as a duplicate of this bug. ***
Comment 90 Milan Crha 2009-11-06 16:16:59 UTC
(In reply to comment #69)
> Created an attachment (id=144486) [details] [review]
> set flag after confirming the operation is cancelled.
> 
> It would be nice if someone try this patch to see if it fixes the crash.

I just tried this, and I saw that the cancel can fail, which then can make the invalid operation. Please commit it. Thanks.
Comment 91 Fabio Durán Verdugo 2009-11-07 17:38:36 UTC
*** Bug 601062 has been marked as a duplicate of this bug. ***
Comment 92 Chenthill P 2009-11-09 08:04:00 UTC
pushed to stable and master.
Comment 93 Chenthill P 2009-11-09 11:28:18 UTC
closing it.
Comment 94 Fabio Durán Verdugo 2009-11-15 17:54:05 UTC
*** Bug 601994 has been marked as a duplicate of this bug. ***
Comment 95 Fabio Durán Verdugo 2009-11-19 15:00:11 UTC
*** Bug 602394 has been marked as a duplicate of this bug. ***
Comment 96 Fabio Durán Verdugo 2009-12-02 18:20:31 UTC
*** Bug 603624 has been marked as a duplicate of this bug. ***
Comment 97 Fabio Durán Verdugo 2009-12-08 01:10:49 UTC
*** Bug 604030 has been marked as a duplicate of this bug. ***
Comment 98 Akhil Laddha 2009-12-09 09:35:01 UTC
*** Bug 604147 has been marked as a duplicate of this bug. ***
Comment 99 Fabio Durán Verdugo 2009-12-11 22:39:50 UTC
*** Bug 604400 has been marked as a duplicate of this bug. ***
Comment 100 Akhil Laddha 2009-12-16 04:17:58 UTC
*** Bug 604609 has been marked as a duplicate of this bug. ***
Comment 101 Fabio Durán Verdugo 2009-12-27 18:51:51 UTC
*** Bug 605521 has been marked as a duplicate of this bug. ***
Comment 102 Fabio Durán Verdugo 2009-12-27 19:15:05 UTC
*** Bug 605482 has been marked as a duplicate of this bug. ***
Comment 103 Fabio Durán Verdugo 2010-01-05 15:21:59 UTC
*** Bug 606114 has been marked as a duplicate of this bug. ***
Comment 104 Milan Crha 2010-01-06 21:05:00 UTC
It seems not everything got fixed. I see, though really rarely, this. Note that the reply had been received, but no thread is waiting for it (in try_open_e_book function). It happens during the first fetch (I removed this boring thread and other from the trace), when I change folders quickly or similar. I'm not sure as I'm not able to reproduce it reliably. I'm only noting it here, and let's see whether someone else is seeing it too.

0x000000393fc0e9dd in waitpid () from /lib64/libpthread.so.0

Thread 1 (Thread 0x7f148b25e800 (LWP 8020))

  • #0 waitpid
    from /lib64/libpthread.so.0
  • #1 IA__g_spawn_sync
    at gspawn.c line 386
  • #2 IA__g_spawn_command_line_sync
    at gspawn.c line 700
  • #3 ??
    from /usr/lib64/gtk-2.0/modules/libgnomebreakpad.so
  • #4 <signal handler called>
  • #5 raise
    from /lib64/libc.so.6
  • #6 abort
    from /lib64/libc.so.6
  • #7 __libc_message
    from /lib64/libc.so.6
  • #8 malloc_printerr
    from /lib64/libc.so.6
  • #9 IA__g_free
    at gmem.c line 190
  • #10 IA__g_error_free
    at gerror.c line 138
  • #11 IA__g_clear_error
    at gerror.c line 302
  • #12 try_open_e_book_cb
    at em-utils.c line 1539
  • #13 open_reply
    at e-book.c line 1650
  • #14 org_gnome_evolution_dataserver_addressbook_Book_open_async_callback
    at e-data-book-bindings.h line 43
  • #15 complete_pending_call_and_unlock
    at dbus-connection.c line 2212
  • #16 dbus_connection_dispatch
    at dbus-connection.c line 4352
  • #17 message_queue_dispatch
    at dbus-gmain.c line 101
  • #18 g_main_dispatch
    at gmain.c line 1960
  • #19 IA__g_main_context_dispatch
    at gmain.c line 2513
  • #20 g_main_context_iterate
    at gmain.c line 2591
  • #21 IA__g_main_loop_run
    at gmain.c line 2799
  • #22 gtk_main
    from /usr/lib64/libgtk-x11-2.0.so.0
  • #23 main
    at main.c line 593

Comment 105 Akhil Laddha 2010-01-15 03:15:32 UTC
*** Bug 607038 has been marked as a duplicate of this bug. ***
Comment 106 Akhil Laddha 2010-02-16 03:22:13 UTC
*** Bug 608567 has been marked as a duplicate of this bug. ***
Comment 107 Milan Crha 2010-03-26 18:29:33 UTC
*** Bug 582472 has been marked as a duplicate of this bug. ***
Comment 108 Akhil Laddha 2011-01-03 04:19:10 UTC
Bug 638533 has similar traces as comment#104