Red Hat Bugzilla – Bug 68832
gnome-moz-remote segv's or works forever
Last modified: 2008-05-01 11:38:02 EDT
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: Always 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.
Chris, gnome-libs hasn't changed in ages - has moz changed in this area?
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.
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.
Marking the head of the priority queue with priority high
gnome-libs 1.4.1.2.90-19 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.
*** Bug 70674 has been marked as a duplicate of this bug. ***
Works now with gnome-libs-1.4.1.2.90-20 from up2date.
I upgraded to the latest gnome-libs from up2date and evolution from rawhide: [tomg@gemini tomg]$ rpm -q gnome-libs gnome-libs-1.4.1.2.90-20 [tomg@gemini tomg]$ rpm -q evolution evolution-1.0.8-6 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 http://linuxtoday.com/backend/my-netscape.rdf Image 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
Fix confirmed with gnome-libs-1.4.1.2.90-20.
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 */ }
Created attachment 71264 [details] strace output of gnome-moz-remote http://www.redhat.com
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 ...
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.
Does it always work when you strace it, or can you get a strace log of it failing?
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]$
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 6c6,10 < 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.
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?
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 /home/tomg/.gnome.bak [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.
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.
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 myself.