Firefox won't start (again!)

2005-07-11 Thread cpghost
On a RELENG_5 system from June 30th (source and ports),
firefox-1.0.4 won't start. It just hangs in the kserel state.
This is on a diskless system using NFS.

Running truss(1) on the hanging firefox-bin process shows:

kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 0 (0x0)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 0 (0x0)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 0 (0x0)
...

When starting, firefox generates a GNOME Warning:

Gdk-WARNING **: gdk_property_get(): length value has wrapped in
calculation (did you pass G_MAXLONG?)

But thunderbird does the same, though it doesn't hang.

/etc/libmap.conf is empty.

Any idea?

Thanks,
-cpghost.

-- 
Cordula's Web. http:/www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Firefox won't start (again!)

2005-07-11 Thread Chris

On Mon, 11 Jul 2005, cpghost wrote:


On a RELENG_5 system from June 30th (source and ports),
firefox-1.0.4 won't start. It just hangs in the kserel state.
This is on a diskless system using NFS.

Running truss(1) on the hanging firefox-bin process shows:

kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 0 (0x0)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 0 (0x0)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 383 (0x17f)
kse_release(0x8065fa4) = 0 (0x0)
...

When starting, firefox generates a GNOME Warning:

Gdk-WARNING **: gdk_property_get(): length value has wrapped in
calculation (did you pass G_MAXLONG?)

But thunderbird does the same, though it doesn't hang.

/etc/libmap.conf is empty.

Any idea?

Thanks,
-cpghost.



C'mon - we two can't be the only ones with this issue...

-
# firefox
(firefox-bin:80350): Gdk-WARNING **: gdk_property_get(): length value has 
wrappe

d in calculation (did you pass G_MAXLONG?)
The program 'Gecko' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadDrawable (invalid Pixmap or Window parameter)'.
  (Details: serial 1338 error_code 9 request_code 150 minor_code 4)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() 
function.)

#

--
Best regards,
Chris

When a broken appliance is demonstrated for the repairman,
it will work perfectly.
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Firefox won't start (again!)

2005-07-11 Thread cpghost
On Mon, Jul 11, 2005 at 05:50:37PM -0500, Chris wrote:
 On a RELENG_5 system from June 30th (source and ports),
 firefox-1.0.4 won't start. It just hangs in the kserel state.
 This is on a diskless system using NFS.
 
 Running truss(1) on the hanging firefox-bin process shows:
 
 kse_release(0x8065fa4) = 383 (0x17f)
 kse_release(0x8065fa4) = 0 (0x0)
 kse_release(0x8065fa4) = 383 (0x17f)
 kse_release(0x8065fa4) = 383 (0x17f)
 kse_release(0x8065fa4) = 0 (0x0)
 kse_release(0x8065fa4) = 383 (0x17f)
 kse_release(0x8065fa4) = 383 (0x17f)
 kse_release(0x8065fa4) = 0 (0x0)
 ...
 
 When starting, firefox generates a GNOME Warning:
 
 Gdk-WARNING **: gdk_property_get(): length value has wrapped in
 calculation (did you pass G_MAXLONG?)
 
 
 C'mon - we two can't be the only ones with this issue...

It's actually quite strange; and seems to be gconfd-2 related
somehow.

If the file system hosting /var/tmp is a nearly empty memory file
system (created by /etc/rc.d/var); everything runs just fine.

But if it is NFS mounted; gconfd-2 start before firefox-bin
reaches this kselrel state. This gconfd-2 then start polluting
/var/tmp with huge amounts of orbit-${USER}-* files.

In this case, killing gconfd-2, cleaning up the mess and disabling
gconfd-2 like this (I didn't yet find a more sensible way to do it;
this is just from memory):

  $ rm -rf ~/.gconf ~/.gconfd
  $ rm -rf /var/tmp/orbit-${USER}*
  $ rm -rf /var/tmp/gconfd-${USER}
  $ rm -rf /var/tmp/orbit-${USER}
  $ mkdir /var/tmp/gconfd-${USER}

results in firefox-bin starting. It complains that it can't connect
to gconfd-2 (which doesn't start), because some file is missing
(IIRC something like /var/tmp/gconfd-${USER}/lock/ior), but that
doesn't seem to prevent firefox from running without any further
problems. 

I've noticed this by chance, because gconfd-2 kept complaining
about permissions of orbit-${USER} files to syslog, generating
even more network traffic from the diskless workstation.

So, to sumarize: on a clean (memory) /var/tmp file system, gconfd-2
works as it should and firefox starts without problems. On an NFS
mounted /var/tmp file system that contains orbit-* files, gconfd-2
starts polluting the directory (and syslog) with huge amounts of
orbit-* files (and messages), thus prevening firefox from starting.
Preventing gconfd-2 from starting (somehow), lets firefox complaining
about it, but it enables firefox to start nonetheless.

Very strange indeed.

Regards,
-cpghost.

-- 
Cordula's Web. http://www.cordula.ws/
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]