Re: [Evolution] Evo 0.10 hangs with IMAP servers

[Not Zed <notzed ximian com>]

On 15 May 2001 21:02:03 +0500, Dan Winship wrote:
> > #3  0x403087ba in __pthread_mutex_lock (mutex=0x8143ba8) at mutex.c:84
> > #4  0x400505d4 in folder_finalize (folder=0x817e888, event_data=0x0, 
> >     user_data=0x81436f0) at camel-store.c:181
> > #5  0x400491b6 in camel_object_unref (obj=0x817e888) at
> > camel-object.c:501
> > #6  0x40a4ac2b in camel_imap_command (store=0x81436f0, folder=0x817e798,
> >     ex=0x0, fmt=0x40a52f69 "NOOP") at camel-imap-command.c:91
>
> So, two issues. First, camel_imap_command is probably mistakenly
> unreffing a folder. I fixed some refcounting issues with
> imap_store->current_folder post-0.10, so that may be fixed already (in
> CVS).
>
> Second, folder_finalize is deadlocking because it's trying to get the
> CamelStore cache_lock from a call chain that already has it (from
> store_sync). So either store_sync needs to change its locking behavior
> or cache_lock needs to be recursive. (Opinions on that?)

Well, why should an imap folder be unreffing another imap folder?  That
seems to be a logic problem.

If there is no other way around it, then you'll have to use a recursive
lock I guess.