Bug 256479 – 'load images only if sender in addressbook' / hang ...

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 256479 - 'load images only if sender in addressbook' / hang ...


Summary:	'load images only if sender in addressbook' / hang ...


Status:	RESOLVED DUPLICATE of bug 361145

Product:	evolution
Classification:	Applications
Component:	Contacts
Version:	2.8.x (obsolete)
Hardware:	Other All

Importance:	Normal major
Target Milestone:	Future
Assigned To:	evolution-addressbook-maintainers
QA Contact:	Evolution QA team

URL:
Whiteboard:

Duplicates:	257429 257523 257780 258540 259210 259432 259496 (view as bug list)
Depends on:
Blocks:

Reported:	2004-04-05 09:32 UTC by Michael Meeks
Modified:	2009-02-12 11:24 UTC

See Also:
GNOME target:	---
GNOME version:	---

Description Michael Meeks 2004-04-05 09:32:59 UTC

Browsing mails and junking them at the same time (although may be
unrelated) I occasionally get an odd hang; whereby the evolution GUI
remains responsible, I can select other mails in the mail list - but þe
preview 'sticks' with a single mail, and simply won't update. Most odd; I
can't see any particular pattern to the mails than hang it. It _looks_ from
the stack-trace as if it's some e-book problem (to me) - and Michael says
it's related to this setting.

The bug showed up for me (the first time) about mid-last week; at the
earliest ~29th March.

Thread 3 - looks like it never gets signalled.

(gdb) t a a bt

+ Trace 45712

Thread 11 (Thread 573451 (LWP 31623))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 g_async_queue_pop_intern_unlocked
at gasyncqueue.c line 226
#4 g_async_queue_pop_unlocked
at gasyncqueue.c line 288
#5 g_thread_pool_thread_proxy
at gthreadpool.c line 96
#6 g_thread_create_proxy
at gthread.c line 559
#7 pthread_start_thread
from /lib/i686/libpthread.so.0
#8 clone
from /lib/i686/libc.so.6

Thread 10 (Thread 327689 (LWP 22311))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/i686/libpthread.so.0
#6 clone
from /lib/i686/libc.so.6

Thread 9 (Thread 311304 (LWP 22310))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/i686/libpthread.so.0
#6 clone
from /lib/i686/libc.so.6

Thread 7 (Thread 81926 (LWP 22266))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 g_async_queue_pop_intern_unlocked
at gasyncqueue.c line 226
#4 g_async_queue_pop
at gasyncqueue.c line 266
#5 worker
at e-book-async.c line 25
#6 g_thread_create_proxy
at gthread.c line 559
#7 pthread_start_thread
from /lib/i686/libpthread.so.0
#8 clone
from /lib/i686/libc.so.6

Thread 5 (Thread 49156 (LWP 22264))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/i686/libpthread.so.0
#6 clone
from /lib/i686/libc.so.6

Thread 4 (Thread 32771 (LWP 22263))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 e_msgport_wait
at e-msgport.c line 511
#4 thread_dispatch
at e-msgport.c line 874
#5 pthread_start_thread
from /lib/i686/libpthread.so.0
#6 clone
from /lib/i686/libc.so.6

Thread 3 (Thread 16386 (LWP 22262))

#0 __pthread_sigsuspend
from /lib/i686/libpthread.so.0
#1 __pthread_wait_for_restart_signal
from /lib/i686/libpthread.so.0
#2 pthread_cond_wait
from /lib/i686/libpthread.so.0
#3 fetch_corba_book
at e-book.c line 1834
#4 e_book_load_source
at e-book.c line 1919
#5 em_utils_in_addressbook
at em-utils.c line 2761
#6 emfh_gethttp
at em-format-html.c line 446
#7 efh_format_do
at em-format-html.c line 1212
#8 mail_msg_received
at mail-mt.c line 507
#9 thread_received_msg
at e-msgport.c line 826
#10 thread_dispatch
at e-msgport.c line 907
#11 pthread_start_thread
from /lib/i686/libpthread.so.0
#12 clone
from /lib/i686/libc.so.6

Comment 1 Not Zed 2004-04-05 09:38:02 UTC

note that thread 3 isn't the main thread, does it need to run in that?

chris said the sync api should be ok to call from any thread.

PS it should happen for any mail that has remote http images in it
with that setting turned on.

since mail formatting is done from another thread, the rest of the app
will continue to function.

Comment 2 JP Rosevear 2004-04-28 02:46:17 UTC

*** bug 257523 has been marked as a duplicate of this bug. ***

Comment 3 JP Rosevear 2004-04-28 02:46:38 UTC

The duplicate has some fairly extensive information.

Comment 4 Gerardo Marin 2004-04-29 21:41:06 UTC

*** bug 257780 has been marked as a duplicate of this bug. ***

Comment 5 Uri David Akavia 2004-05-02 06:31:48 UTC

Since the duplicate explains that by removing the offending Adressbook
sources you can fix the problem, I have a question.

How?

Whenever I try to delete I get a message that says
Error removing address book: e_book_load_uri: no factories available
for uri `ldap://ldap.yahoo.com:389/??one'

What does this mean, and how do I remove these sources anyway?
Should I open another bug or are these two subjects related (they seem
to be)?

Comment 6 JP Rosevear 2004-05-10 14:59:41 UTC

It shouldn't need to run on the main thread unless some gui auth has
to be done.

Comment 7 Gerardo Marin 2004-05-16 02:19:45 UTC

*** bug 257429 has been marked as a duplicate of this bug. ***

Comment 8 Richard Zach 2004-05-16 21:06:17 UTC

*** bug 258540 has been marked as a duplicate of this bug. ***

Comment 9 Chris Toshok 2004-05-20 19:09:22 UTC

Going to mark this as fixed, as (in the information listed in the
duplicate), it's most likely caused by a non-responsive ldap server
(http://bugzilla.ximian.com/show_bug.cgi?id=58495, which is now fixed.)

Comment 10 Federico Mena Quintero 2004-05-25 01:25:12 UTC

As of evolution1.5-1.5.7.0.200405171248-0, this is not fixed.  I don't
have any LDAP sources and it does hang with some messages.

Comment 11 Federico Mena Quintero 2004-05-28 15:20:13 UTC

I still get this with evolution1.5-1.5.8.0.200405260833

Comment 12 Gerardo Marin 2004-05-28 20:20:41 UTC

And 1.5.8 duplicates too

Comment 13 Gerardo Marin 2004-05-28 20:21:10 UTC

*** bug 259210 has been marked as a duplicate of this bug. ***

Comment 14 Gerardo Marin 2004-06-02 20:49:01 UTC

*** bug 259432 has been marked as a duplicate of this bug. ***

Comment 15 jspaar 2004-06-06 19:56:50 UTC

Works for me in 1.5.9.1.

Comment 16 bugs 2004-06-07 22:59:46 UTC

  I am seeing this issue in 1.5.8 with no ldap sources.

Comment 17 Gerardo Marin 2004-06-09 23:17:25 UTC

*** bug 259496 has been marked as a duplicate of this bug. ***

Comment 18 Gerardo Marin 2004-06-09 23:18:19 UTC

bug 259496 has an excellent backtrace. Blame e-d-s

Comment 19 Not Zed 2004-06-16 06:47:56 UTC

ok i've committed some code which does two things:
 - it only queries addressbooks that are part of your 'autocomplete'
list rather than every addressbook available.
 - if it still gets stuck, which seems to be very backend related, you
can hit the 'cancel' button, and it should clean up and reset itself.

Comment 20 Not Zed 2005-01-31 07:46:34 UTC

*** bug 257429 has been marked as a duplicate of this bug. ***

Comment 21 Brian J. Murrell 2006-10-16 13:23:27 UTC

This bug seems to exist in 2.8.1 still.

Since my LDAP server is hosed at the moment and I have been hitting this bug on every single message in my INBOX with an image in it, I have finally come to the conclusion that this problem is that a message has a URL to an image in it, and the setting to allow image loading only when the sender is in an address book is set and some LDAP connected address books are not available.

Hitting cancel does NOT restore working order to the preview pane as comment #19 suggests it should.

Do we re-open this bug or start a new bug?

Comment 22 Sushma Rai 2006-10-17 06:41:13 UTC

Please re-open.

Comment 23 Brian J. Murrell 2006-10-17 11:56:10 UTC

(In reply to comment #22)
> Please re-open.
> 

I don't seem to have any knobs or buttons to reopen bugs in my bugzilla view.  Perhaps somebody else does?

Comment 24 Michael Meeks 2006-10-17 13:55:45 UTC

re-opened.

Comment 25 Wayne A Feick 2007-10-10 23:31:15 UTC

Is bug 361145 a dup of this? The behavior seems similar and I've attached some debug stack traces there.

Comment 26 Michael Meeks 2008-01-07 13:06:59 UTC

Yes, it looks the same - albeit newer :-) feel free to mark the best dup wrt. traces etc. as you like.

Comment 27 Milan Crha 2009-02-12 11:24:31 UTC

Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find.


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