Page 2 of 9

Posted: Tue 03 Jul 2012, 17:18
by akash_rawal
The output is similar to one I get when I plug in my usb modem which also behaves like an optical drive. Yet when I plug it in, it is detected by the volume monitor and shown.

All I can guess is that /etc/udev/rules.d/50-pup-volume-monitor.rules could have gone missing. Don't know how it happens it has happened to me several times while working with autotools.

Posted: Tue 03 Jul 2012, 18:40
by jemimah
Udev events from other drives make it through - I can see them with pup-volume-monitor-admin -e.

I've attached the udevd debug log.

Posted: Tue 03 Jul 2012, 23:08
by jemimah
It's definitely a packaging problem of some sort. I booted a fresh install on my development machine and it doesn't work with the internal drive there either.

I'll try to figure out what's missing.

Posted: Wed 04 Jul 2012, 14:39
by akash_rawal
Udev events are as expected. But what maybe going wrong is totally unexpected.

I am attaching modified plugins/cdrom.c with debugging code added wherever necessary. Hope it will help with debugging.

Posted: Thu 05 Jul 2012, 18:24
by jemimah
I'm not seeing the additional debugging output even on the working system. Strange - can't figure out why that would be.

Posted: Thu 05 Jul 2012, 18:52
by jemimah
I changed the g_degugs to printfs and now I can see output on the working system.

On the nonworking system I get this:

# pup-volume-monitor

Code: Select all

pup-volume-monitor-Message: Config file for plugin libcdrom not found, it will use default settings

(pup-volume-monitor:15730): GModule-CRITICAL **: g_module_symbol: assertion `module != NULL' failed
What's happening here?

Posted: Fri 06 Jul 2012, 14:56
by jemimah
Ok I think I figured it out. The existence of /usr/lib/pup-volume-monitor/libcdrom.a and/or /usr/lib/pup-volume-monitor/libcdrom.la seems to be crashing it.

Posted: Fri 06 Jul 2012, 15:06
by akash_rawal
Surely cdrom plugin failed to load with some error.

I agree there's a bug ahead leading to a call to g_module_symbol() even after plugin failed to load, but it should have shown the plugin path... :?

Code: Select all

// libpupvm/pupvm-settings.c:117

gboolean pup_vm_plugin_load(GTypeModule *module)
{
	PupVMPlugin *self = PUP_VM_PLUGIN(module);
	g_return_val_if_fail(self->plugin_name && self->plugin_path, FALSE);

	self->module = g_module_open(self->plugin_path, 0);
	if (!self->module)
	{
		g_debug("Module path: %s", self->plugin_path);
	}

	if (module && (! self->initialised))
	{ ...

Edit: I didn't notice g_module_error() earlier. I improved pup_vm_plugin_load() error output and fixed that bug. This will not cause plugin to load correctly but we'd come to know why plugin failed to load.

libpupvm/pupvm-settings.c:117

Code: Select all

gboolean pup_vm_plugin_load(GTypeModule *module)
{
	PupVMPlugin *self = PUP_VM_PLUGIN(module);
	g_return_val_if_fail(self->plugin_name && self->plugin_path, FALSE);

	self->module = g_module_open(self->plugin_path, 0);
	if (!self->module)
	{
		//g_debug("Module path: %s", self->plugin_path);
		g_critical("Plugin %s (path: %s) failed to open: %s",
		           self->plugin_name, self->plugin_path, g_module_error());
	}

	if (self->module && (! self->initialised))
	{
		//Load plugin's config
		self->cfg_file = g_key_file_new();
		pup_load_cfg_file(self->cfg_file, self->plugin_name);
		
		//Run the plugin's init func
		PupVMPluginInit plugin_init_func;

		if (g_module_symbol(self->module, "pup_vm_plugin_init",
		                    (gpointer *) &plugin_init_func))
		{
			plugin_init_func(self);
		}
		
		self->initialised = TRUE;
	}
	
	if (module) return TRUE;
	else return FALSE;
}

Posted: Fri 06 Jul 2012, 18:25
by akash_rawal
jemimah wrote:Ok I think I figured it out. The existence of /usr/lib/pup-volume-monitor/libcdrom.a and/or /usr/lib/pup-volume-monitor/libcdrom.la seems to be crashing it.
Updated to version 0.1.4

Changelog:
  • Now static libraries are filtered out while loading plugins
  • A few minor bug-fixes

Posted: Wed 25 Jul 2012, 08:05
by peebee
Hi akash_rawal
The following small test extracted from Frisbee funcs:

Code: Select all

#!/bin/bash
MSG="Please enter the Password."
Xdialog  --title "Frisbee" --password --inputbox "$MSG" 0 0 > /opt/Pwireless-entry 2>&1
when run in check-mate V3 - Puppy latest LXDE desktop !
produces output in /opt/Pwireless-entry
(Xdialog:9249): pup-volume-monitor-WARNING **: Module loaded successfully
0123456789
that contains unwanted warning from pup-volume-monitor in front of the typed password.
Any ideas why this is happening - and how to stop the warning text being produced please? It is stopping Frisbee working correctly on check-mate.
Thanks
PeeBee

Posted: Wed 25 Jul 2012, 10:35
by akash_rawal
peebee wrote: The following small test extracted from Frisbee funcs ... when run in check-mate V3 - Puppy latest LXDE desktop ! produces output in /opt/Pwireless-entry
(Xdialog:9249): pup-volume-monitor-WARNING **: Module loaded successfully
0123456789
that contains unwanted warning from pup-volume-monitor in front of the typed password.
Updated to version 0.1.5

Changelog:
  • Removed the debugging macro that was used to ensure that the volume monitor module was loaded

Posted: Wed 25 Jul 2012, 11:00
by Jejy69
Yeah !
Frisbee works ! ! ! You're the best! :D
Thank you for being so quick and efficient!

Thank you Peebee too, have reacted so quickly, and found that this did not work! Bravo! "GG" !
All my derived will be able to function!

Posted: Wed 25 Jul 2012, 13:04
by peebee
akash_rawal wrote:Updated to version 0.1.5
Changelog:
Removed the debugging macro that was used to ensure that the volume monitor module was loaded
Very many thanks - thought it must have to be something like that....
Cheers
peebee

Posted: Thu 30 Aug 2012, 17:10
by akash_rawal
Updated to version 0.1.6

Changelog:
  • Fixed destructor calling in client module, may fix crashing issues with seamonkey (Edit: It works)

Issue with latest ver 1.6

Posted: Fri 07 Sep 2012, 08:53
by Igo AtM
Hi
I have been testing/using the volume monitor module since it first started appearing here and am much impressed with it as a initial implementation.
However I have recently uploaded the version 1.6 and I believe it started causing segmentation faults on my system. I have since reverted back to version 1.5 and have no issues.
being an event based issue The fault is some what difficult to pin down and is only ever reported as a simple seg fault. It would seem to occur most often when using a popup resource browser as a file system utility to a foreground app. The program will on change of browser window and subsequent save requests crash the parent window leaving no or little logged cause of the problem.
I am currently using Slacko 5.3.3 with window managers of compiz/openbox/icewm and pcfileman 1-0 and Libfm 1-0. I do not run a full gvfs as this also generated issues when run in competition with your event backend. My machine is a Dell Inspiron 1501 and puppy is run from an external usb hard drive. As I say puppy its self remains stable it is only the requesting app that crashes. Predominately Geany and Firefox but I notice these as I run the programs almost consistently.
I would like to be more specific in terms of logs of the issue but it is some what complicated in that to do so would require effectively disabling my set-up whilst using 1.6

Posted: Tue 11 Sep 2012, 01:49
by Geoffrey
I tried the pup-volume-monitor-0.1.6 update in Saluki, as I was getting the browsers firefox and seamonkey crashing when mounting drives, but with the update gtkdialog seg faults on comboboxs so it seems.

I installed pup-volume-monitor-0.1.5 update, now gtkdialog is fine but still have the problem of browsers crashing when mounting drives, this is a random event, I can see no patten to it.

Geoffrey

Posted: Tue 11 Sep 2012, 10:58
by akash_rawal
Updated to version 0.1.7

Changelog:
  • Fixed 'accessing destroyed object' bug (thanks Geoffrey and Igo AtM, the problem was reproducible in saluki 023 and not in slacko 531)

Posted: Wed 12 Sep 2012, 03:23
by Geoffrey
akash_rawal wrote:Updated to version 0.1.7

Changelog:
  • Fixed 'accessing destroyed object' bug (thanks Geoffrey and Igo AtM, the problem was reproducible in saluki 023 and not in slacko 531)
Thanks akash_rawal,

That seems to have fixed the problem, I'll continue to test, though I'm sure you have nailed it.

Cheers,

Geoffrey

swap partitions in SDcards

Posted: Mon 08 Oct 2012, 07:36
by mavrothal
I can understand that may not be a very common situation (outside embedded systems), but pup-volume-monitor shows swap partitions in SDcards as mountable volumes both on the desktop and Thunar. This is the case in both Saluki and Carolina.
Also when an SDcard is inserted the swap partition shows twice both with the card name and as "mmcblk[0-9]p[0-9]". However, if the card is already in before boot, the swap partition shows only with the card name.

Posted: Mon 08 Oct 2012, 14:36
by akash_rawal
Updated to version 0.1.8

Changelog:
  • Fixed filtering of loop devices and swap partitions (thanks mavrothal)