[gentoo-amd64] Problem with Firefox 2

[gentoo-amd64] Problem with Firefox 2

[Joaquim Quinteiro Uchoa]

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.

The title of the message is "Malformed file".

I click in a "Ok" button and the browser starts. So, it 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:

{972ce4c6-7e08-4474-a285-3208198ce6fd}
inspector@mozilla.org
langpack-pt-BR@firefox.mozilla.org
langpack-pt-PT@firefox.mozilla.org

All I need is a way to see what file is being mentioned by Firefox.
The message is not clear, I have no reference about which extension
is causing the problem.

So, how I can find the origin of this?



-- 
[]s
Joaquim
------------------------------------------
  (o_    Joaquim Quinteiro Uchoa
 //\        Consultor Linux e EaD
 U_/_    Linux User # 100534
------------------------------------------
-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] Re: Problem with Firefox 2

[Duncan]

"Joaquim Quinteiro Uchoa" <joaquim.uchoa@gmail.com> 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