Author Archive

How surprised am I.

Well, seems I belong to the Shire.

To which race of Middle Earth do you belong?

... and for now, it's 1.5rc2 that got in experimental.

I made some changes to the firefox wrapper script so that it should be quicker to launch firefox in most cases. We don't try to find the JVM version, since the ones we wanted to set LD_ASSUME_KERNEL for have been ABI incompatible for a while, and we don't remove the XUL.mfasl and other problematic files since it is now correctly (I hope) by firefox itself. And if bugs arise again, we'll try to fix in upstream code, not in wrapper script...

I also fixed the dash bug and another one in xpidl.

For what it's worth, I did some testing with JVMs and firefox. I got success with

• Sun JRE 1.5update5,
• Sun 1.4.2_10,
• IBM 1.4.2SR3 (but not with java-package, see bug #338277),
• Blackdown 1.4.2-02 and 1.4.1-01.

On the other hand,

• IBM 1.3.1SR8 segfaults,
• Blackdown 1.3.1+02a and 1.3.0-FCS are built against libxpcom.so with older C++ ABI, so ld can't find __vt_17nsGetServiceByCID,
• Sun 1.3.1_10 can't load libstdc++-libc6.1-1.so.2.

I'm not sure I have to be proud of the fact that my name has a meaning in klingon.


mh@namakemono:/tmp$ wget "http://download.mozilla.org/?product=firefox-1.5b2&os=linux&lang=en-US"
(...)
mh@namakemono:/tmp$ tar -zxf firefox-1.5b2.tar.gz
mh@namakemono:/tmp$ cd firefox/
mh@namakemono:/tmp/firefox$ ./firefox
./run-mozilla.sh: line 131: 7540 Segmentation fault "$prog" ${1+"$@"}
mh@namakemono:/tmp/firefox$ ldd firefox-bin | grep c++
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb7610000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb67b3000)


Why on earth is upstream's firefox linked against BOTH libstdc++5 AND libstdc++6 ?!?

Update: Okay, now, with a little more thinking:

mh@namakemono:/tmp/firefox$ LD_LIBRARY_PATH=. ldd firefox-bin | grep c++
libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0xb75a0000)


And after a bit more investigation, it appears that the gtk module for scim is responsible for loading libstdc++.so.6...

I've been dealing with some open source projects in the past, submitting patches and stuff, but dealing with mozilla.org is really a hassle. You never really know what to do at what moment. They even admit that it's not easy... And I'm not even talking about how bugzilla is a pain in the ass.

But this is the first time I've been asked to actually find a submitter myself.

I already sent patches that actually did land in the CVS without me requesting anything. So what's the difference ? That it's a feature request instead of a bug ?

What about my other patches ?

Recently, I've been going through mozilla-firefox's list of bugs and took a look to some of them. I got interested in #336411, since I'm regularly hit by this one myself (remember ? I said I got strange crashes with 1.5beta1).

It appears that this strange crasher is in fact due to extensions using binary components. ColorZilla was the one killing my firefox. Why does it crash on debian's firefox and not on upstream's ? Simple : upstream's is built with gcc 3.4, debian's with gcc 4.0. Both C++ ABIs are incompatible. Now the question is : what can we do for that ?

A quick fix could be to check before loading the component, if it's linked to the incompatible libstdc++.so.5, but it's almost as nasty as the bug itself... I've not really investigated possible solutions yet, but if you have some better ideas, you're welcome.

Another bug I got interested in is #211010 and its dupe, #256384. This one was really nasty. One of the kind I hate : bad programming practices. The interesting thing with this bug, though, was that it's been revealed because of 3 other issues in 2 separate programs.

The first issue is that autoconf decides to use echo 'something\c' over echo -n something when both '\c' and -n are understood by echo.

The second issue is that when giving some options with spaces to configure (like in --enable-optimize="-pipe -w -O2"), the associated variable gets backslashed spaces (i.e. "-pipe\ -w\ -O2") (thus, being an autoconf feature)

The third issue is that the mozilla configure.in script tries to get rid of these backslashed spaces with echo $enableval | sed -e 's|\\\ | |g', triggering the nasty dash bug. A simple workaround, as stated in #256384 is to quote $enableval

Now, for the dash bug itself.

What happens with dash is that whenever you echo a '\c' escape sequence, all subsequent echo commands stop printing after the first argument containing a backslash. For example echo test1 'test2\ttest3' test4 outputs test1 test2<tab>test3.

In the case of our echo $enableval, since its value was -pipe\ -w\ -O2, it printed -pipe\ without any space after the backslash, so that it was not removed by the sed call. This value was then substitued in config/autoconf.mk.in to create config/autoconf.mk, where the ending backslash was interpreted as its shell meaning (continue on next line), thus breaking the variable, and build command lines.

And for the bad programming practice ?

The dash bug is due to a global variable that never got re-initialized, leaving the "terminate echo" (kinda) flag turned on (which is only checked when there is a backslash in the argument, since it is used to stop printing after, guess what... '\c').

No wonder why one of the first things you learn in programming classes is : never use global variables. (or at least, be very very very careful about what you do with them)

... and in experimental. RC2 is due soon and final a few days after... I'll definitely need to update my firefox extensions packaging kinda howto, so as to all my extensions packages, so that they actually work with latests releases of firefox.

The revenge.