Does this happen all the time, or only in certain circumstances? What distro + version are you using? Are you aware of anything unstandard about how you have your machine setup?

Happens all the time.

The thing unusual about my machine is that it's running all the latest GNOME 2.21.5 on PLD Linux. Including conduit 0.3.5.

Will try to reproduce on another machine when I get around to upgrading it if it helps.

Crashes in conduit are usually caused by crashes in external libraries. The most common of which seems to be gtkmozembed. 

Does conduit print anything weird at startup (i.e. does /usr/bin/conduit call /usr/bin/conduit.real correctly)

Does the crash still happen if you uncheck the option "Use built in web browser"?

Second machine, same result. Full run:

[patrys@meaw SPECS]$ LC_ALL=C /usr/lib/mozilla-firefox/run-mozilla.sh /usr/bin/conduit.real 
[Main                ][INFO   ] Conduit v0.3.5 Installed: True (Main.py:76)
[Main                ][INFO   ] Using UI: gtk (Main.py:77)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules (Module.py:103)
[Module              ][DEBUG  ] Reading directory /home/users/patrys/.conduit/modules (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/BackpackModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/BansheeModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/BoxDotNetModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/EvolutionModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/FacebookModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/FeedModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/FileModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/FlickrModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/FspotModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/GConfModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/GmailModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/GoogleModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/N800Module (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/NetworkModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/PicasaModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/RhythmboxModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/ShutterflyModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/SmugMugModule (Module.py:103)
[Module              ][DEBUG  ] Reading directory /usr/lib/conduit/modules/YouTubeModule (Module.py:103)
[dataproviders.SimpleFactory][INFO   ] HAL Initialized (VolumeFactory.py:25)
[Utils               ][DEBUG  ] Adding /usr/lib/conduit/modules/BackpackModule/backpack to python path (Utils.py:117)
[Utils               ][DEBUG  ] Adding /usr/lib/conduit/modules/BoxDotNetModule/BoxDotNetAPI to python path (Utils.py:117)
[Utils               ][DEBUG  ] Adding /usr/lib/conduit/modules/FacebookModule to python path (Utils.py:117)
[Utils               ][DEBUG  ] Adding /usr/lib/conduit/modules/FlickrModule/FlickrAPI to python path (Utils.py:117)
[Module              ][WARNING] Error loading the file: /usr/lib/conduit/modules/FspotModule/FspotModule.py.
Traceback (most recent call last):

+ Trace 185513

[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: YouTube source (UID: YouTubeSource-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Creating Category <conduit.dataproviders.DataProviderCategory.DataProviderCategory instance at 0xb772bd8c> (Tree.py:104)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: RSS Feed source (UID: RSSSource-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Banshee Playlists source (UID: BansheeSource-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Files source (UID: FileSource-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Creating Category <conduit.dataproviders.DataProviderCategory.DataProviderCategory instance at 0xb771ea8c> (Tree.py:104)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Backpack Notes sink (UID: BackpackNoteSink-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Creating Category <conduit.dataproviders.DataProviderCategory.DataProviderCategory instance at 0xb772bd0c> (Tree.py:104)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Shutterfly sink (UID: ShutterflySink-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Creating Category <conduit.dataproviders.DataProviderCategory.DataProviderCategory instance at 0xb772bcec> (Tree.py:104)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Facebook sink (UID: FacebookSink-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Tomboy Notes twoway (UID: TomboyNoteTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Picasa twoway (UID: PicasaTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Box.net twoway (UID: BoxDotNetTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Google Calendar twoway (UID: GoogleCalendarTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Creating Category <conduit.dataproviders.DataProviderCategory.DataProviderCategory instance at 0xb772bd2c> (Tree.py:104)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Evolution Memos twoway (UID: EvoMemoTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Evolution Tasks twoway (UID: EvoTasksTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Evolution Contacts twoway (UID: EvoContactTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Network twoway (UID: NetworkEndpoint-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Evolution Calendar twoway (UID: EvoCalendarTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Folder twoway (UID: FolderTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Email twoway (UID: GmailEmailTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Creating Category <conduit.dataproviders.DataProviderCategory.DataProviderCategory instance at 0x871b6ac> (Tree.py:104)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: SmugMug twoway (UID: SmugMugTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: GConf Settings twoway (UID: GConfTwoWay-None) to TreeModel (Tree.py:100)
[gtkui.Tree          ][DEBUG  ] Adding DataProvider Wrapper: Flickr twoway (UID: FlickrTwoWay-None) to TreeModel (Tree.py:100)
[SyncSet             ][INFO   ] Restoring Sync Set from /home/users/patrys/.conduit/settings-dev.xml (SyncSet.py:174)
[gtkui.UI            ][DEBUG  ] Presenting GUI (UI.py:149)
[ModuleWrapper       ][WARNING] Could not load icon applications-media for Media (ModuleWrapper.py:136)
[ModuleWrapper       ][WARNING] Could not load icon banshee for Banshee Playlists (ModuleWrapper.py:136)
[DBus                ][DEBUG  ] DBus Exported: / (DBus.py:126)
[DBus                ][DEBUG  ] DBus Exported: /syncset/gui (DBus.py:126)
[DBus                ][DEBUG  ] DBus Exported: /syncset/dbus (DBus.py:126)
[modules.Network     ][DEBUG  ] Resolved conduit service meaw on meaw.local - 192.168.0.109:3400
Extra Info: ['version=0.3.5'] (Peers.py:242)
[modules.Network     ][DEBUG  ] Remote host 'meaw.local' detected (Client.py:48)
[modules.Network     ][DEBUG  ] Resolved conduit service meaw on meaw.local - 192.168.76.2:3400
Extra Info: ['version=0.3.5'] (Peers.py:242)
[modules.Network     ][DEBUG  ] Remote host 'meaw.local' detected (Client.py:48)
[Main                ][INFO   ] Closing application (Main.py:226)
[SyncSet             ][INFO   ] Saving Sync Set to /home/users/patrys/.conduit/settings-dev.xml (SyncSet.py:121)
[Main                ][INFO   ] Setting global cancel flag (Main.py:233)
[Main                ][INFO   ] Stopping Synchronization threads (Main.py:237)
[Main                ][INFO   ] Closing dataprovider factories (Main.py:241)
[Main                ][INFO   ] Unitializing dataproviders (Main.py:245)
python: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
025a7096-fac8-fed3-4ef8b863-34d1be5f is dumped

Thanks for taking the time to report this bug.
Without a stack trace from the crash it's very hard to determine what caused it.
Can you get us a stack trace? Please see http://live.gnome.org/GettingTraces for more information on how to do so. Thanks in advance!

This is a mystery. Can you also provide information on your distro, package versions, etc

Here's full trace:

(gdb) where full

+ Trace 185516

Created attachment 102960 [details]
strace -ff result

Thanks.

Can you please try and isolate which conduit module causes the crash by, one-by-one, removing the module's directory and re-starting conduit.

Thanks a lot

Ok, isolated the offending module. It's iPodModule.py and bindings are python-libgpod-0.6.0.

Confusing.

So looking at the looks you don't have an iPod connected when this error occurs. So the only code that should execute is equivalent to:

import gpod
RIGHT_VERSION = gpod.version_info >= (0,6,0)

Could you try the following command at a console:

python -c "import gpod; print gpod.version_info"

Does it crash? Or does it print a tuple?

It crashes when *quitting* conduit so obviously it returns the right tuple (0, 6, 0). Indeed, confusing. Point me to the right direction and I'll start to dig more into it on my own. I'm a Python programmer for living so I can debug pretty much everything once you tell me what is called when shutting down conduit.

Did you try it though? I *did* see that this happens when you close. The point of the exercise was to see if your python bindings are leaving something in an odd state that crashes python on exit when destroying objects, not to see if the tuple was (0, 6, 0).

I'll flesh out my debugging process so you can see im not making wild noobish stabs in the dark.

Assumptions:
 * This is purely the fault of iPodModule.py, and not an interaction with another module (purely to keep it simple for now)

 * You have no iPod connected (the logs suggested that no iPod was detected, but maybe conduit isn't logging that properly).

 * In this case, we look at iPodModule.py and see that there are various classes based on IPodBase. These are not instanced or even touched unless an iPod is connected. 

 * iPodFactory will be instanced, but this won't do anything unless an iPod is connected. This is detected using HAL and several other modules would likely cause this crash too if it was faulty.

 * The only other code left in the file that means Johns external libraries test are the two lines i posted..

If it doesn't crash from this alone then the "no ipod" assumption was wrong or libgpod is reacting badly to something else. You didnt correct my "no ipod" assumption and im not sure if you actually tried the command i posted, so can you update me before we start looking further into this.

Soory if I sounded a bit aggressive. I did try that line and it works as expected with no crash. There was no iPod connected. I use libgpod bindings in my own Python code and am so far unable to come with a simplified crasher example (that would allow me to file a bug against libgpod) :/

Okie dokie. Lets see if its a gtk interaction.. 

If you run ./conduit -c in a terminal (not sure it will work in a tty) then conduit will start without its UI. Press Ctrl+C and it will shut down gracefully. It should still do the Uninitializing step that precedes the crasher, but does it crash if the GTK isn't running?

(I'm hoping it still crashes)

Still crashes? What about interactions with other plugins: Carry on removing plugins from the modules/ until only iPodModule.py is left and see if the crash still happens. Actually, It might be better to remove everything but iPodModule and if the crash goes away, readd modules until the crash comes back..

Good luck!

Command line version crashes as well.

I've been able to narrow the crashing set to these:

[root@purrr modules]# ls
__init__.py   __init__.pyo   iPodModule.pyc  N800Module
__init__.pyc  iPodModule.py  iPodModule.pyo

I fear it maybe the VolumeMonitor code - not liking two versions at the same time. Which works just fine on Gutsy and Hardy :-(

Here is a test case... I'm not sure where this will need to be to work on your setup, for me i put it at the root of an SVN checkout.

import conduit
import conduit.modules.N800Module.N800Module as N
import conduit.modules.iPodModule as I

f1 = N.N800Factory()
f2 = I.iPodFactory()

f1.quit()
f2.quit()

Does this trigger the crash?

Bingo:

[patrys@purrr conduit-0.3.5]$ LC_ALL=C python foo.py 
python: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
74d99499-b343-6d63-10b66b37-0e05dc4f is dumped

(bug-buddy:26304): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed

Does debian sport any special patches? Here's my system:

[patrys@purrr conduit-0.3.5]$ rpm -q gnome-vfs2 gnome-volume-manager
gnome-vfs2-2.20.1-1.i686
gnome-volume-manager-2.22.0-2.i686

Puzzling indeed. I'm certain its because gnomevfs will get hooked to twice, but why has it only hit you? So i have a few work arounds in my mind, but the question is: have we found a python / GnomeVFS bug, or are we just lucky it doesn't crash everywhere? If its their bug i'd rather fix there than here...

John S, thoughts? Singleton/Borg pattern in Vfs.py is one option..

Any more thoughts on this? I am still unable to reproduce. Can anyone else reproduce this?

(In reply to comment #19)
> Any more thoughts on this? I am still unable to reproduce. Can anyone else
> reproduce this?
> 

I can pretty much reproduce it 100% with a build for Fedora 8:

https://bugzilla.redhat.com/show_bug.cgi?id=428838

I'm sure its because we touch GnomeVFS twice from two different places - so the bindings aren't dealing with the python GC properly. Can someone with the problem confirm if this python code is enough to trigger the crash?

import gnomevfs

class Test(object):
    def __init__(self):
        self.vm = gnomevfs.VolumeMonitor()
        self.vm.connect("volume-mounted",self._mounted_cb)
        self.vm.connect("volume-unmounted",self._unmounted_cb)

    def _mounted_cb(self, *args, **kwargs):
        pass

    def _unmounted_cb(self, *args, **kwargs):
        pass

t1 = Test()
t2 = Test()

It should either just exit, or possibly segfault..

John:

[patrys@purrr Desktop]$ LC_ALL=C python foo.py 
python: Modules/gcmodule.c:276: visit_decref: Assertion `gc->gc.gc_refs != 0' failed.
Aborted.

Thanks for the quick response! I think thats a pretty convincing argument that this is a bug in python gnomevfs...

Can you get the source for your distros gnome-python? Where would i be able to get hold of it? Specifically i want to compare this file to your distros (and the same file in ubuntu...)

http://svn.gnome.org/viewvc/gnome-python/trunk/gnomevfs/vfs-volume-monitor.c

Ubuntu Gutsy has same vfs-volume-monitor.c as GNOME SVN

We use unpatched 2.20.1, the file is identical to SVN.

Hmm. Odd. I am verrrry confused..

Is this enough to trigger it?

import gnomevfs
t1 = gnomevfs.VolumeMonitor()
t2 = gnomevfs.VolumeMonitor()

No, this works fine (clean exit).

So its GnomeVFS with multiple callbacks, or GnomeVFS when wrapped in another object and instanced multiple times.. What about:

def _(*args, **kwargs):
    pass

import gnomevfs
t1 = gnomevfs.VolumeMonitor()
t1.connect("volume-mounted",_)
t2 = gnomevfs.VolumeMonitor()
t2.connect("volume-mounted",_)

This crashes as (un)expected.

okie dokie, i'll have a good look through the gnome-python stuff when i get home

John, can you make the gnome-python devs aware of this?

Is this bug still present in 0.3.8?  And if so, is there any simple workaround to keep it from crashing?

John, Any news? Did you ping the gnome-python devs?

Unfortunately I think this is a bit of a dead end, GIO is here now, I expect python-gnomevfs to go into the abyss

Also see:
https://bugzilla.redhat.com/show_bug.cgi?id=429970
https://bugzilla.redhat.com/show_bug.cgi?id=428838

Still a problem with 0.3.11.1 . The bizarre thing is, if I run conduit uninstalled, it crashes on exit; if I run it installed, it crashes on startup (the GUI is never displayed at all).

Is this in Fedora 9, or another distro?

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.