[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Cause of XRender/LD_BIND_NOW interaction found
From:       Kevin Puetz <puetzk () iastate ! edu>
Date:       2002-02-25 22:41:13
[Download RAW message or body]


> > Can't we add such a dirty hack to kdeinit then? It's ugly but clearing a
> > few bytes once when KDE starts is not something that anyone will notice.
> AFAI understood puetzk, this hack has to go between the two XRENDER calls 
> made by QApplication.

Well... it might be possible to do it from kdeinit (just have to poison *lots* 
more stack, since qt is gonna use quite a bit). I have no great ideas on how 
to guess how much it will take. Doing it right before the offending call 
makes it pretty easy to guess at the stack depth required (and I just went 
for a bunch of overkill anyway). There's also a chance that something in qt 
will go deeper and put zero's back under us with this approach, which is why 
doing it right before it's needed is more effective.

If we want to be underhanded about this, another fix is for qt to not call the 
XRenderQueryExtension() first. :-). It's uneeded (we will safely get NULL for 
supported visuals on displays that don't support RENDER in all versions of 
libXrender) and not calling it makes XRenderFindVisualFormat work enough 
harder that it poisons its own stack :-).

Another arguably more sane solution is for qt to statically link the contents 
of libXrender from X4.2 (iirc, about 17k of code). Then it would just another 
lib where qt has -system-xrender or -qt-xrender linked, at ./configure time. 
Distros not shipping X4.2 would have to build with -qt-xrender. This would 
also give non-xfree86 qt's RENDER support, just in case they ever connected 
to an xfree86 display :-).

I really have no idea what course we want to take here, from a warning for 
XF86 <4.2, to something like the above, or even using my stack-poisoning hack 
(which, as others have pointed out, is a noop unless followed by broken code, 
so it should be perfectly safe). Presumable QT's commercial customers (Opera, 
Hancom, etc) are also suffering this bug, so at some point (ASAP!) we need to 
present them with options and see what they want to do about it.

not using LD_BIND_NOW avoids it pretty much incidentally, in fact in basically 
the same way my stack-poisoning hack does, before anybody calls that a 
cleaner solution :-).

-- 
Kevin Alan Puetz
(515)572-0927
puetzk@iastate.edu
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]