It's not the same as Bug 561090 ?

No, obviously there is a python error that can be found and fixed. I encounter lockups _without_ any usefull error messages.

I'm experiencing the same issue on an Ubuntu 8.10

Created attachment 127589 [details]
conduit backtrace on freeze

Same issue with CAL_SOURCE_TYPE_TODO. Simple script works fine, conduit hangs in EvolutionModule.py:303.
I loaded python into gdb, ran conduit, clicked 'refresh' on a evo task item and the gui stopped responding. I then pressed ctrl-c to obtain a backtrace. I'm missing a few symbols though.

I can confirm this on Debian with evolution 2.22 and conduit-trunk, and for all evolution dataproviders.

*** Bug 561090 has been marked as a duplicate of this bug. ***

Bollocks. Dunno what is up here.

No idea if this helps at all, but I tried building Evolution 2.25.9 and had the same problem.

I tried getting a backtrace during a recreation of the problem with Evolution 2.24, but it looks pretty useless. :S

Some more testing :
conduit 0.3.15 on Debian repository work.
rebuilding the same source on actual Debian Sid have the bug.

The build was made on December 22, so I think it's a bug in a python package update since this date.

Here's a traceback of the relevant thread could it be related to the version of libebook, libbonobo or libORBIT?

(gdb) bt

+ Trace 212785

*** Bug 568056 has been marked as a duplicate of this bug. ***

(In reply to comment #9)
> Some more testing :
> conduit 0.3.15 on Debian repository work.
> rebuilding the same source on actual Debian Sid have the bug.
> 
> The build was made on December 22, so I think it's a bug in a python package
> update since this date.
> 

I cannot think what caused the bug. The python-gnome-desktop package has not bee updated in a while, and my usage of it has not changed. It must be something else that has changed, something the evo hackers changed.

But simple test cases work, like the following, so it seems to be something to do with the way the module is used in conduit?

from EvolutionModule import *

a=EvoContactTwoWay("default")
print a
a.refresh()
contactList=a.get_all()
for contact in contactList:
    print a.get(contact)

(In reply to comment #13)
> But simple test cases work, like the following, so it seems to be something to
> do with the way the module is used in conduit?
> 
> from EvolutionModule import *
> 
> a=EvoContactTwoWay("default")
> print a
> a.refresh()
> contactList=a.get_all()
> for contact in contactList:
>     print a.get(contact)
> 

Conduits use of the module has not changed, which I think points to a confusing and hard to debug threading bug. Sounds like fun to fix. It must have been introduced in libebook or something

I can recreate the bug, most of the time I run following code. I was attempting to get simultaneous ebook calls. But can this happen in conduit, i.e. multiple simultaneous threads making ebook calls?


from threading import Thread

from EvolutionModule import *
import random,  time,  os

class testit(Thread):
    def __init__ (self):
      Thread.__init__(self)
    def run(self):
        a=EvoContactTwoWay()
        r=random.uniform(1,  2)
        name=self.getName()+" (%d)" % os.getpid()
        print "%s Sleeping for %f"  % (name, r)
        time.sleep(r)
        a.refresh()
        contactList=a.get_all()
        for contact in contactList:
            print "%s Contact %s" % (name,  a.get(contact))


for i in range(2):
    test=testit()
    test.start()

(In reply to comment #15)
> I can recreate the bug, most of the time I run following code. I was attempting
> to get simultaneous ebook calls. But can this happen in conduit, i.e. multiple
> simultaneous threads making ebook calls?

No, or at least it certainly does not happen in a conduit test case that reliably triggers the bug. (Create a EvoContactTwoWay and click refresh)

In that case. the closest thing to multiple thread access is non concurrent access to evoltuion from different threads. For example there is a call in EvoContact.__init__ that gets the available addressbooks, and another call in refresh() that gets the contacts. Code in refresh() , get(), get_all(), put() are all accessed in a different thread to that in __init__, but this should not be a problem if the gtk threading system has been initialized (gtk.gdk.threads_init(), which it has)

> 
> 
> from threading import Thread
> 
> from EvolutionModule import *
> import random,  time,  os
> 
> class testit(Thread):
>     def __init__ (self):
>       Thread.__init__(self)
>     def run(self):
>         a=EvoContactTwoWay()
>         r=random.uniform(1,  2)
>         name=self.getName()+" (%d)" % os.getpid()
>         print "%s Sleeping for %f"  % (name, r)
>         time.sleep(r)
>         a.refresh()
>         contactList=a.get_all()
>         for contact in contactList:
>             print "%s Contact %s" % (name,  a.get(contact))
> 
> 
> for i in range(2):
>     test=testit()
>     test.start()
> 

Cool. To clarify a little, my suspicion regarding usage from multiple threads requires at least one of the threads to be the gtk MainLoop. Also, you should call gtk.gdk.threads_init(), or gobject.threads_init()

Created attachment 129362 [details]
test case

Running this reliably triggers the problem. The threaded access is not concurrent

Attachment in comment #17 reliably triggers problem on Ubuntu Jaunty with latest updates as of 2009-02-23

I used the test case to try and trace where the hang occurs and got down to 

bonobo_context_init (); in bonobo-main.c in libbonobo

The problem happens because bonobo_init is being called on-demand by e-d-s:

+ Trace 212845

Moving the bonobo initialization to the python script fixed the problem.  All we need is to 'import bonobo' at the top.  I'll fix the python evolution modules to do it automatically during import.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.