From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GmjNT-0003H6-99 for garchives@archives.gentoo.org; Wed, 22 Nov 2006 04:06:27 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.8) with SMTP id kAM44SUd027730; Wed, 22 Nov 2006 04:04:28 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.8) with ESMTP id kAM44R18024988 for ; Wed, 22 Nov 2006 04:04:27 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GmjLT-0007Y0-9e for gentoo-amd64@lists.gentoo.org; Wed, 22 Nov 2006 05:04:23 +0100 Received: from ip68-230-97-209.ph.ph.cox.net ([68.230.97.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Nov 2006 05:04:23 +0100 Received: from 1i5t5.duncan by ip68-230-97-209.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 22 Nov 2006 05:04:23 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: Problem with Firefox 2 Date: Wed, 22 Nov 2006 04:04:08 +0000 (UTC) Message-ID: References: <59541ff30611211041g40985a11q12c08018e9ac005a@mail.gmail.com> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-209.ph.ph.cox.net User-Agent: pan 0.120 (Plate of Shrimp) Sender: news X-Archives-Salt: bd4aae7c-78a4-48a0-8438-0fc7addbcef1 X-Archives-Hash: 74f51c33161b4d8412246111f389b7e0 "Joaquim Quinteiro Uchoa" posted 59541ff30611211041g40985a11q12c08018e9ac005a@mail.gmail.com, excerpted below, on Tue, 21 Nov 2006 16:41:56 -0200: > Hello, I'm having a problem with Firefox 2. Every time I start the > browser, I see the following message: > > Bon Echo could not install this item because "install.rdf" (provided by > the item) is not well-formed or does not exist. Please contact the author > about this problem. > [I]t works, but this sucks. > > Well, I've tried several things, including starting with -jsconsole and > using a new profile. I can see anything wrong in > /usr/lib64/mozilla-firefox/extensions: > All I need is a way to see what file is being mentioned by Firefox. I'm not a firefox user so won't attempt to address the issue from that angle. However, there's another way: emerge if necessary and use strace. strace basically hooks and reports on part or all of the system calls an application makes. Output can be WAY longer than you might expect, so you filter it down, first by using command line switches to only report on what you are after (in this case, all open-file calls will do), then by piping the output to grep for further filtering down to a manageable level. For commandline options you'll want -eopen, to trace only file-open calls. You /may/ need -f to trace forks as well. The trace actually goes to STDERR not STDOUT, so you have to redirect STDERR to STDOUT to pipe it to grep. Something like this: strace -f -efile 2>&1 | grep install.rdf Note that you may still get quite some output, if firefox is looking in multiple locations for the file, with ENOENT (error no entry) errors returned by the system (and reported by systrace) if the file doesn't exist, a filenumber returned if it was opened successfully, and permission errors and the like also possible. It's not so much of interest here, but one can also use strace to find just what sort of thing an application is looking for to open and where, even without knowing the filename exactly. I'll often use it to figure out where an app keeps its config files, for instance. In that case, you don't know the name of the file exactly so you can't grep for it, and as I said, the output can very quickly get overwhelming without any filtering at all. However, grep -v (return only lines that do NOT match) can be used in this case, to exclude whole categories that are known NOT to be of interest. For instance, many X apps will look for icon, font and cursor files, and if we are looking for config files those aren't of any interest at all, so we could use a | grep -v icons | grep -v fonts | grep -v cursors pipeline of greps to filter all those out. If we are looking for a user config, we can further grep for the user's home dir, avoiding everything in /usr including all the libraries opened and the like. Since every library open often involves several attempts at various standard locations before the library is actually found and opened, that's a HUGE filter. By this time, the output should actually be getting a bit more humanly manageable and one can look thru it manually. If not, add a few more greps to the pipeline to filter it further. Of course, using strace is quite educational in itself. Few users have any idea running a single application involves even 1% of the number of attempted opens it actually does, or that for every library actually loaded, the system often looks in multiple standard locations for that library before actually finding it. One VERY QUICKLY gains a new appreciation for how much actual work goes on behind the scenes, and is amazed that just opening even a simple app doesn't take a half-hour! =8^) Anyway, strace can be a very helpful troubleshooting tool, once one learns how to use it and cope with its often HUGE output level. I've certainly found it so, and it should prove quite helpful for you here, as well. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-amd64@gentoo.org mailing list