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 315856 - Evolution hangs while importing email.
Evolution hangs while importing email.
Status: RESOLVED DUPLICATE of bug 305633
Product: evolution
Classification: Applications
Component: Mailer
2.4.x (obsolete)
Other All
: Normal major
: ---
Assigned To: Shreyas Srinivasan
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2005-09-09 20:39 UTC by Miguel de Icaza
Modified: 2005-09-19 03:55 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Miguel de Icaza 2005-09-09 20:39:31 UTC
Please describe the problem:
My email is loaded from /var/spool/mail/miguel

About 30% of the time when I import my email into evolution, I will see a label
that says "Waiting" on the "Send and Receive Mail" dialog box for the receiving
component and the "Waiting" never goes away.

I can close the window and cancel the operations but no mail import will work
after this, and quitting evolution is not possible.


Steps to reproduce:
1. Setup /var/spool/mail/XXXX email
2. Import it.
3. Repeat until evolution produces the "Waiting" message


Actual results:


Expected results:


Does this happen every time?
30% of the time.

Other information:
I attached to Evolution, this sounds like a deadlock somewhere, here is the
stack trace:



Comment 1 Miguel de Icaza 2005-09-12 06:42:59 UTC
I saw these things on the logs:

(evolution:23695): GLib-CRITICAL **: g_source_remove: assertion `tag > 0' failed

** (evolution:11277): WARNING **: failed request with status 1030

** (evolution:11277): WARNING **: failed request with status 1030

** (evolution:11277): WARNING **: failed request with status 1030

** (evolution:11277): WARNING **: failed request with status 1030

** (evolution:11277): WARNING **: failed request with status 1030

** (evolution:11277): WARNING **: failed request with status 1030

** (evolution:11277): WARNING **: failed request with status 1030
** (evolution:11322): WARNING **: Serious fd usage error 11

and also:

** (evolution:11324): WARNING **: Serious fd usage error 16

** (evolution:11324): WARNING **: Serious fd usage error 14

** (evolution:11324): WARNING **: Serious fd usage error 15

** (evolution:11324): WARNING **: Serious fd usage error 13

** (evolution:11324): WARNING **: Serious fd usage error 11

** (evolution:11326): WARNING **: Serious fd usage error 16

** (evolution:11326): WARNING **: Serious fd usage error 14

** (evolution:11326): WARNING **: Serious fd usage error 15

** (evolution:11326): WARNING **: Serious fd usage error 13

** (evolution:11326): WARNING **: Serious fd usage error 11

They are aggregates from a bunch of uses, as I said, I have to restart evolution
every 2 to 3 imports so the data there is mixed.

Comment 2 Miguel de Icaza 2005-09-12 06:46:57 UTC
More impotrant, I just started evolution again and imported a fresh batch of
emails, this is what i got:

adding hook target 'source'

(evolution:23725): Gdk-CRITICAL **: gdk_gc_set_foreground: assertion `GDK_IS_GC
(gc)' failed

** (evolution:23768): WARNING **: Serious fd usage error 16

** (evolution:23768): WARNING **: Serious fd usage error 14

** (evolution:23768): WARNING **: Serious fd usage error 15

** (evolution:23768): WARNING **: Serious fd usage error 13

** (evolution:23768): WARNING **: Serious fd usage error 11

This I know happened when I clicked on Send/Receive and it imported the email

Going to sleep now, but will post more when I get more email that I can import.

Comment 3 Shreyas Srinivasan 2005-09-16 13:42:28 UTC
http://bugzilla.gnome.org/show_bug.cgi?id=314574 Also reported the same problem.

It could be the problem of not trying to libexec the right camel-lock-helper.
The fix actually went into gnome-2.12 branch post release(sep 12). So maybe you
could try with one of the latest rpms from build buddy.

I am looking at other possible code which may cause lock ups. Will update as and
when i find something. With the same setup i cant replicate it and am mostly
hunting for possible lock ups in the code. Also it would be helpful if you could
do a CAMEL_VERBOSE_DEBUG=1 and get the debug log.
Comment 4 Miguel de Icaza 2005-09-17 01:01:35 UTC
I looked at the patch that you pointed out, and since I can not find a version
of Evolution with said patch available anywhere, instead I copied 

camel-lock-helper-1.2 to camel-lock-helper-

So that evolution would load the proper one, and this did not work.

Now it hangs with *any* import.

Besides, I do not believe this is the problem, as I said, sometimes its possible
to import one, two maybe even three times before it locks up.

Also notice that the code is locked inside "camel_init", where is camel_init
being called from?   My guess is that it is some macro
Comment 5 Miguel de Icaza 2005-09-19 00:30:09 UTC
You might be correct in that the bug is this file name change.

I did not see the change as Evolution did not shut everything down the last time

I did a link and mail importing is working for now.  I still need to upgrade
Comment 6 Not Zed 2005-09-19 03:15:28 UTC
When you copied the file, was it properly set-uid/set-gid the same as the
installed one?

Looks like evolution-2-4-0 was taken from the wrong branch, it may be that the
patch didn't make it into the released version.

The trace is just broken - nothing every calls camel_init directly except
application code (and certainly enable_stop doesn't call filter_junk doesn't
call do_movemail).
Comment 7 Shreyas Srinivasan 2005-09-19 03:55:24 UTC
Yeah, the released version never had the patch. I missed the comment of the
issue being fixed. So i am closing as duplicate. I would get back to you
regarding the update issue, we have a build buddy system which creates rpms
everyday but i am not entirely sure of whether it is active after the release. I
will ping you on irc if anything comes through on the rpms side.

*** This bug has been marked as a duplicate of 305633 ***