Bug 68832 - gnome-moz-remote segv's or works forever
Summary: gnome-moz-remote segv's or works forever
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: gnome-libs
Version: limbo
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
: 70674 (view as bug list)
Depends On:
Blocks: 67218
TreeView+ depends on / blocked
Reported: 2002-07-14 23:43 UTC by Gordon Messmer
Modified: 2008-05-01 15:38 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2002-08-28 16:58:36 UTC

Attachments (Terms of Use)
strace output of gnome-moz-remote http://www.redhat.com (1.86 MB, text/plain)
2002-08-16 22:44 UTC, tom georgoulias
no flags Details

Description Gordon Messmer 2002-07-14 23:43:04 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/20020625

Description of problem:
gnome-moz-remote will either SEGV immediately (sometimes from Evolution) or it
will continue using all spare CPU time until killed.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Run 'gnome-moz-remote http://www.redhat.com/' from the command line. 

Actual Results:  gnome-moz-remote does not return.  No new browser window opens.

Expected Results:  A new browser window should open displaying the URL given.

Comment 1 Havoc Pennington 2002-07-15 00:04:11 UTC
Chris, gnome-libs hasn't changed in ages - has moz changed in this area?

Comment 2 Christopher Blizzard 2002-07-15 03:17:47 UTC
gnome-moz-remote just talks to mozilla through x properties.  I haven't made any
signifigant changes to the xremote server code in a while.

Comment 3 Gordon Messmer 2002-07-15 06:00:37 UTC
gdb indicates that the program is looping in the "for" loop (the only one) in
VirtualRootWindowOfScreen defined in vroot.h.  

ltrace's output shows the XGetWindowProperty function there called hundreds of
times, but I can't get gdb to tell me what the value of numClients is.  All of
the  values of the second argument (children[i]) are unique in the output of ltrace.

If someone can get the debugger working and examine the results of the call to
XQueryTree in this function, the problem should be more clear.

Comment 4 Havoc Pennington 2002-07-29 16:25:59 UTC
Marking the head of the priority queue with priority high

Comment 5 Havoc Pennington 2002-08-02 21:24:51 UTC
gnome-libs has a fix that works for me. I never saw the infinite
loop thing though, just the segfault. So let us know if it still loops.

Comment 6 Jeremy Katz 2002-08-03 19:04:11 UTC
*** Bug 70674 has been marked as a duplicate of this bug. ***

Comment 7 Gordon Messmer 2002-08-07 02:09:40 UTC
Works now with gnome-libs- from up2date.

Comment 8 tom georgoulias 2002-08-16 03:23:23 UTC
I upgraded to the latest gnome-libs from up2date and evolution from rawhide:
[tomg@gemini tomg]$ rpm -q gnome-libs
[tomg@gemini tomg]$ rpm -q evolution

Seems like the problem of 100% CPU usage by gnome-moz-remote was fixed with the
latest set of RPMs, which is good, but clicking on a URL still doesn't open the
page in Mozilla.  Here's what I see when I run evolution with --debug:

evolution-executive-summary-WARNING **: Opening http://boingboing.net/rss.xml

evolution-executive-summary-WARNING **: Opening
Gnome-Message: res is 0 instead of 4
Gnome-Message: gnome_execute_async_with_env_fds: returning -1
Gnome-Message: res is 0 instead of 4
Gnome-Message: gnome_execute_async_with_env_fds: returning -1

Comment 9 Jay Turner 2002-08-16 03:44:01 UTC
Fix confirmed with gnome-libs-

Comment 10 Havoc Pennington 2002-08-16 03:47:50 UTC
Can you run something like "strace -f -o output gnome-moz-remote
http://www.redhat.com" and attach "output"?

Code creating the error message:

 res = read (parent_comm_pipes[0], &child_pid, sizeof(child_pid));
  if (res != sizeof(child_pid))
      g_message("res is %d instead of %d", res, sizeof(child_pid));
      child_pid = -1; /* really weird things happened */

Comment 11 tom georgoulias 2002-08-16 22:44:52 UTC
Created attachment 71264 [details]
strace output of gnome-moz-remote http://www.redhat.com

Comment 12 Tim Waugh 2002-08-19 10:42:06 UTC
But that time, did it work? 
1554  write(7, "\22\6\0\0", 4)          = 4 
1553  <... read resumed> "\22\6\0\0", 16) = 4 
1554  getrlimit(0x7, 0xbffff7f8 <unfinished ...> 
1553  write(5, "\22\6\0\0", 4 <unfinished ...> 
1554  <... getrlimit resumed> )         = 0 
1553  <... write resumed> )             = 4 
1552  <... read resumed> "\22\6\0\0", 4) = 4 

Comment 13 tom georgoulias 2002-08-20 02:31:34 UTC
Yes, it did work that time.  I entered the command, Mozilla started up and the
RH homepage loaded w/o a hitch. Sorry about not mentioning that in my last
update, I have no idea why I forgot to do so.  :(

FYI:  I installed the new Null beta today by wiping my disk clean, except for
/home.  The bug/problem is still there, but gnome-libs and evolution versions
that I had just upgraded to so I'm not too surprised about that.  My evolution
and .mozilla dirs are the same as before.

Comment 14 Tim Waugh 2002-08-21 08:33:31 UTC
Does it always work when you strace it, or can you get a strace log of it 

Comment 15 tom georgoulias 2002-08-22 01:48:57 UTC
Everytime I invoke a URL with the gnome-moz-remote command, it loads the page. 
That includes instances where I strace.  Some observations:

1. It honestly looks as if gnome-moz-remote isn't even started by clicking on
links in evolution.  I've yet to catch a single instance where a
gnome-moz-remote process is started by evolution.  

2. If Mozilla is already running and I strace gnome-moz-remote from the command
line, it loads the page fine.  WHen I quit Mozilla, there aren't any lingering
processes from the strace or mozilla hanging around.

3.  If Mozilla isn't running and I strace gnome-moz-remote from the command
line, it loads the page fine but Mozilla *doesn't* cleanly exit after I quit. 
Mozilla becomes defunct and I have to kill -9 all of the PIDs created by the
gnome-moz-remote and strace itself.

If you have any suggestions about local configs I can check to be sure this
isn't a problem with some boneheaded thing I've done on my end, I'd love to hear
them.  Also, let me know if there any other logs/traces/tests you want results
from.  I'd be glad to provide.

The RPMs seem to be OK:
[tomg@gemini evolution]$ rpm -V evolution
[tomg@gemini evolution]$ rpm -V gnome-libs
[tomg@gemini evolution]$

Comment 16 tom georgoulias 2002-08-28 03:35:24 UTC
OK, I got it to work after I moved ~/.gnome to ~/.gnome.bak and logged out of my
Gnome session.  Now every URL I click on in Evolution or pass to
gnome-moz-remote in the shell opens up properly.  I grepped the .gnome dirs for
"moz" and this is the only match that I found:

Gnome:default-show=gnome-moz-remote --newwin "%s"

It was the same in both, so I diffed them:

[tomg@gemini tomg]$ diff .gnome .gnome.bak
Common subdirectories: .gnome/accels and .gnome.bak/accels
Common subdirectories: .gnome/application-info and .gnome.bak/application-info
Only in .gnome.bak/: apps
Only in .gnome.bak/: galeon
diff .gnome/Gnome .gnome.bak/Gnome
< ghelp-show=nautilus "%s"
> ghelp-show=galeon "%s"
> http-show=galeon "%s"
> https-show=galeon "%s"
> ftp-show=galeon "%s"
> file-show=galeon "%s"
Only in .gnome.bak/: gnome-pilot.d
Common subdirectories: .gnome/gnome-vfs and .gnome.bak/gnome-vfs
Only in .gnome.bak/: GnuCash
Only in .gnome.bak/: Gnumeric
Only in .gnome.bak/: gtkhtml
Common subdirectories: .gnome/mime-info and .gnome.bak/mime-info

I've been carrying around this .gnome dir for a long time, so the possibilities
for cruftiness are high.  I guess you can consider this bug fixed, unless it
needs to be addressed in the cases where someone upgrades a system and finds
themselves in the same predictament I was in.

Comment 17 Havoc Pennington 2002-08-28 04:19:29 UTC
If I'm interpreting that correctly, your old .gnome had Galeon set up to handle
all the URLs? Then on upgrade Galeon wasn't installed?

Comment 18 tom georgoulias 2002-08-28 16:37:54 UTC
I'm not sure why those settings are in there either b/c I never set up Galeon to
open my URLs.  IIRC, Galeon was selected when I installed Null, I fired Galeon
up once, then manually removed it shortly thereafter.  Before I started running
limbo/null, I was using 7.3 with the same .gnome dir and evolution opened URLs
in Mozilla while nautilus opened them in the file manager window.

Here are both of the Gnome files:

[tomg@gemini .gnome.bak]$ pwd
[tomg@gemini .gnome.bak]$ cat Gnome

[URL Handlers]
default-show=gnome-moz-remote --newwin "%s"
info-show=nautilus "%s"
man-show=nautilus "%s"
ghelp-show=galeon "%s"
http-show=galeon "%s"
https-show=galeon "%s"
ftp-show=galeon "%s"
file-show=galeon "%s"
[tomg@gemini .gnome.bak]$ cd ../.gnome
[tomg@gemini .gnome]$ cat Gnome

[URL Handlers]
default-show=gnome-moz-remote --newwin "%s"
info-show=nautilus "%s"
man-show=nautilus "%s"
ghelp-show=nautilus "%s"
[tomg@gemini .gnome]$

What I will do is reinstall Galeon and see if it makes those changes to
~/.gnome/Gnome when I start it up.

Comment 19 Gordon Messmer 2002-08-28 16:49:37 UTC
It will if you tell it to.  The first time you run Galeon, it asks you what
protocols you would like to associate with Galeon.  If you just click next, it
will grab the associations listed in your Gnome config.

Comment 20 tom georgoulias 2002-08-28 16:58:31 UTC
Yup, I just ran through the process and allowing it to created those settings is
the default behavior, which is probably what I did.

Sorry for wasting everyone's time and bandwidth on something I should've caught

Note You need to log in before you can comment on or make changes to this bug.