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)

2005-11-05 08:23:05+0900

firefox

Both comments and pings are currently closed.