Subject: Re: galeon is failing on 1.6R
To: Nathan J. Williams <email@example.com>
From: Steven M. Bellovin <firstname.lastname@example.org>
Date: 04/22/2003 16:01:18
In message <email@example.com>, "Nathan J. Willia
>"Steven M. Bellovin" <firstname.lastname@example.org> writes:
>> My concern is not for any one easily-fixed bug, but whether there are
>> enough of them out there that we can't patch everything.
>That is possible. I could make them a compile-time option (I think a
>run-time option might hurt performance), and investigating that is on
>my to-do list. My fear with making such assertions optional, though,
>is that nobody but me would ever use them.
>One of the reasons I made this change was to try to nail down whether
>some of the things that have broken with native pthreads are tripping
>over pthreads bugs or just having their own bugs exposed; this makes
>the latter much more obvious when it happens.
Now is definitely not the time to do anything like that; let's first
find out how bad the problem really is. It may indeed be bad enough --
witness some of the bug compatibility in xterm and in X servers.
One easy way to make the assertions optional is to say something like
assert(_Disable_Thread_Bug_Checks || (realtest));
where _Disable_Thread_Bug_Checks is some initialized static variable.
It's a very easy source (or executable) patch to disable the assertion,
if someone has some application that (mostly) runs despite its inherent
Put another way, if I can't get some application fixed, my choice may
be to accept occasional crashes because the application's thread code
is broken, or to have it not run at all because of the assertion.
--Steve Bellovin, http://www.research.att.com/~smb (me)
http://www.wilyhacker.com (2nd edition of "Firewalls" book)