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.
_______________________________________________
evolution maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution
