Bug 133567

Created attachment 104289 [details]
Debugging information produced by bug-buddy.

Created attachment 104290 [details]
Message appeared on the console.

Hm, the stack trace goes into HAL...my suspicion right now is that
it's a bug in the HAL client library.  Pulling in John and David on this.

Takayuki, what version of HAL do you have installed?  Is this right
after a yum upgrade - i.e. are you sure you're actually running the
0.14 version of eggcups that's installed?

These are the versions of eggcups and hal installed in my computer.

[takayuki@coffee ~]$ eggcups --version
Gnome eggcups 0.14
[takayuki@coffee ~]$ rpm -qa | grep hal
hal-0.2.98.cvs20040923-1
hal-cups-utils-0.5.2-1

This bug is also being tracked upstream here:
http://bugzilla.gnome.org/show_bug.cgi?id=153672

If I downgrade hal-0.2.98.cvs20040923-1 to hal-0.2.98-4, (so the
packages installed in my computer are desktop-printing-0.14-1 and
hal-0.2.98-4) the error is still appeared.
But, If I downgrade desktop-printing-0.14-1 to
desktop-printing-0.13-1, (so the packages installed in my computer are
desktop-printing-0.13-1 and hal-0.2.98.cvs20040923-1) the error is not
appeared.

So I think the bug is in eggcups.

Created attachment 104295 [details]
Debugging message produced by bug-buddy when I install hal-0.2.98-4.

Not necessarily, since eggcups simply didn't use HAL before 0.14.

Hmm, wierd since all the hal stuff does is get a list of printers on
startup and then never use hal again.  Ok, I'll check this out to see
if I can reproduce it.

FYI
im getting an eggcups crash happening at desktop login
sounds like what im seeing is related.
desktop-printing-0.14-1
hal-0.2.98.cvs20040923-1

I seem to be unable to coax any significant logging from hal.
i tried running /usr/sbin/hald --daemon=no --verbose=yes
and watching the output and /var/log/messages and then starting
eggcups from a commandline. Hal doesn't tell me anything when eggcups
attempts to start. And I get no useful logging to the commandline from
eggcups. eggcups crashes and gnome session lovingly keeps trying to
restart it for me, but I don't see anything in the logs from hald
suggesting eggcups actually communicated.

for comparison when i turn hald off and run eggcups from commandline i
still get the eggcups crash..but i also get this at the cli:
libhal.c 2242 : Error sending msg: Service "org.freedesktop.Hal" does
not exist

Anything else for me to try?

--jef

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

Colin.  Check out the latest CVS and see if this fixes the problem.  I
was basicly sending nulls ro HAL on startup because I missed
derefrencing a pointer to a pointer when checking if it was NULL.  I
know on some machines this is what was crashing eggcup on startup.  It
should never crash HAL so it is bad if we are weather or not I fixed
this in eggcups.

Well, if I understand this correctly, technically you're not crashing
the hal daemon; you're only crashing the process using libhal. 

FWIW, the new GNOME VFS stuff I just done exercises most of the code
paths in libhal (through libhal-storage) and this seems to work for
me. Of course, perhaps libhal could be a little be more paranoid about
verifying the incoming parameters. Btw, you can grab the latest CVS
build of libhal from 

 http://people.redhat.com/davidz/gnomevfs_patch/

David 

hm, ok I read the above libhal.c 2242 : Error sending msg: Service
"org.freedesktop.Hal" does not exist comment wrong.  Ignore my doom
and gloom ;-) 

Here's a trace with symbols, if it's helpful

Backtrace was generated from '/usr/bin/eggcups'

Using host libthread_db library "/lib/tls/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -151142272 (LWP 13636)]
0x00287782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#0  0x00287782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x004e833b in __waitpid_nocancel () from /lib/tls/libpthread.so.0
#2  0x032d9f50 in libgnomeui_module_info_get ()
   from /usr/lib/libgnomeui-2.so.0
#3  <signal handler called>
#4  0x006d11cd in filter_func (connection=0x9e17f40, message=0x9e18188, 
    user_data=0x9e1a400) at libhal.c:480
#5  0x0074690d in dbus_connection_dispatch (connection=0x9e17f40)
    at dbus-connection.c:2550
#6  0x006fe4e8 in gsource_connection_dispatch (source=0x9e196f0,
callback=0, 
    user_data=0x9e1a400) at dbus-gmain.c:258
#7  0x0061d4fb in g_main_context_dispatch (context=0x9dd8e10) at
gmain.c:1942
#8  0x0061ef82 in g_main_context_iterate (context=0x9dd8e10, block=1, 
    dispatch=1, self=0x9db92b8) at gmain.c:2573
#9  0x0061f22f in g_main_loop_run (loop=0x9dfc928) at gmain.c:2777
#10 0x0097d69e in gtk_main () at gtkmain.c:1173
#11 0x08050811 in main (argc=2, argv=0x2) at main.c:206

Thread 1 (Thread -151142272 (LWP 13636)):
#0  0x00287782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
No symbol table info available.
#1  0x004e833b in __waitpid_nocancel () from /lib/tls/libpthread.so.0
No symbol table info available.
#2  0x032d9f50 in libgnomeui_module_info_get ()
   from /usr/lib/libgnomeui-2.so.0
No symbol table info available.
#3  <signal handler called>
No symbol table info available.
#4  0x006d11cd in filter_func (connection=0x9e17f40, message=0x9e18188, 
    user_data=0x9e1a400) at libhal.c:480
	udi = 0x9e159e8 "/org/freedesktop/Hal/devices/block_11_0-0"
	object_path = 0x9de5c80 "/org/freedesktop/Hal/Manager"
	error = {name = 0x0, message = 0x0, dummy1 = 1, dummy2 = 0, 
  dummy3 = 1, dummy4 = 0, dummy5 = 1, padding1 = 0x8061090}
#5  0x0074690d in dbus_connection_dispatch (connection=0x9e17f40)
    at dbus-connection.c:2550
	filter = (DBusMessageFilter *) 0x9e1a418
	next = (DBusList *) 0x0
	message = (DBusMessage *) 0x9e18188
	link = (DBusList *) 0x9e1a400
	filter_list_copy = (DBusList *) 0x9de4910
	message_link = (DBusList *) 0x9de4904
	result = 165782552
	pending = (DBusPendingCall *) 0x0
	reply_serial = 0
	status = DBUS_DISPATCH_DATA_REMAINS
	__FUNCTION__ = "dbus_connection_dispatch"
#6  0x006fe4e8 in gsource_connection_dispatch (source=0x9e196f0,
callback=0, 
    user_data=0x9e1a400) at dbus-gmain.c:258
	connection = (DBusConnection *) 0x9e17f40
#7  0x0061d4fb in g_main_context_dispatch (context=0x9dd8e10) at
gmain.c:1942
No locals.
#8  0x0061ef82 in g_main_context_iterate (context=0x9dd8e10, block=1, 
    dispatch=1, self=0x9db92b8) at gmain.c:2573
	got_ownership = 165782528
	max_priority = 2147483647
	timeout = 29990
	some_ready = 1
	nfds = 11
	allocated_nfds = 1
	fds = (GPollFD *) 0x9de6c50
	__PRETTY_FUNCTION__ = "g_main_context_iterate"
#9  0x0061f22f in g_main_loop_run (loop=0x9dfc928) at gmain.c:2777
	got_ownership = 165660872
	self = (GThread *) 0x9db92b8
	__PRETTY_FUNCTION__ = "g_main_loop_run"
#10 0x0097d69e in gtk_main () at gtkmain.c:1173
	tmp_list = (GList *) 0x0
	functions = (GList *) 0x0
	init = (GtkInitFunction *) 0x0
	loop = (GMainLoop *) 0x9dfc928
#11 0x08050811 in main (argc=2, argv=0x2) at main.c:206
	client = (GnomeClient *) 0x9dbb840
	restart_argv = (GPtrArray *) 0x9db8e2c
	dotdir = 0x9db8e2c ""
	action = {sa_handler = 0x80502a0 <handle_signal>, sa_mask = {__val = {
      0 <repeats 32 times>}}, sa_flags = 0, sa_restorer = 0xfee85688}
	block_mask = {__val = {0 <repeats 32 times>}}
	dbus = (DBusConnection *) 0x9e1a400
	acquisition_result = 0
	error = {name = 0x0, message = 0x0, dummy1 = 1, dummy2 = 0, 
  dummy3 = 0, dummy4 = 0, dummy5 = 0, padding1 = 0x0}
	popt_options = {{longName = 0x805e8db "debug", shortName = 100 'd', 
    argInfo = 0, arg = 0x8063a4c, val = 0, 
    descrip = 0x805e8e1 "Enable debugging information", argDescrip =
0x0}, {
    longName = 0x805e8fe "show", shortName = 115 's', argInfo = 0, 
    arg = 0x8063a48, val = 0, descrip = 0x805e903 "Show icon by default", 
    argDescrip = 0x0}, {longName = 0x0, shortName = 0 '\0', argInfo = 0, 
    arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}}
	__FUNCTION__ = "main"
#0  0x00287782 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2

I don't know if you need this information.

I can cause the event to occur by powering on my PocketPC PDA when it
is attached to the USB port of my computer. 

My install is a completely clean version of FC3 and I have not
installed synce or multisync yet. 

The event does not occur when my PDA is in the cradle and powered off. 

It also does not occur when I power on and use my Sony DSC-F70V
Digital Camera. 

Hold it! 

The event DOES occur when I power off my Sony DSC-F70V. Powering on or
powering off my digital camera causes the event to occur.

John - I tried your fix from CVS but I still get a crash.  Trying to
track down.

Man, this bug would be way less annoying to test if my kernel didn't
oops when I unplugged devices...

Is the crash during the start of eggcups or when you plug something in?  

When I plug my USB DVD burner in.

Ah, ok. I had David look it over and it appears to be a bug in hal's
cleanup code (hal_shutdown).  It wasn't deregestering a dbus filter
which now makes total sence with the fact that we were crashing on any
hal event after the fact that I was no longer using hal past startup.
 David is going to fix it and roll another HAL package tomorrow. 

Ok, but I should still go ahead and upload 0.14.1 with your changes
from CVS, right?

Right, that fixes the upstream bug of crashing on startup which looked
like the user who filed it had a printer plugged in but no
configuration  in gconf for it.  In those cases the make and model
returned are NULL and should have caused the checks to not call the
cups config daemon.

Anyway update away and when the new HAL is uploaded all should be fixed.

Ok, update committed to CVS, waiting on beehive to get unb0rked to upload.

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

It's built in beehive now, passing the buck to david so he can close
this bug when a new HAL is uploaded.

(Set the bug to MODIFIED I mean, not close)

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

Well, hal-0.2.98.cvs20040927 should resolve this crasher - it will be
uploaded tomorrow. Please check if it works.

The 'fix' wasn't very elegant; basically hal_shutdown() doesn't unref
the DBusConnection since doing so may cause the process terminate
because a DBusConnection object is supposed to be tied to the lifetime
of the process. libhal could invoke
dbus_connection_set_exit_on_disconnect(conn, FALSE) but that is not a
nice thing for a library to do.

I've posted a patch some time ago to fix this

 http://freedesktop.org/pipermail/dbus/2004-August/001418.html

although I acknowledge there may be better approaches.

Created attachment 104486 [details]
backtrace

Not directly related to USB devices but, eggcups is now crashing after
login. This is with eggcups 0.14.1 and hal-0.2.98.cvs20040927-1, check
the attachment in comment #31. Might be a different bug.

I updated hal to hal-0.2.98.cvs20040927-1 and it fixed the
eggcups crash when I plug my MP3 USB player.
This looks fixed to me

Daniel

Ricardo Veguilla,

Please update to the new eggcups and try again.  If the crash on start
keeps happening please open a new bug on it.  I am closing this one as
it looks to be fixed.