[Mesa-dev] Truncated extensions string

José Fonseca jfonseca at vmware.com
Tue Mar 15 13:38:53 PDT 2011

On Tue, 2011-03-15 at 13:26 -0700, Ian Romanick wrote:
> Hash: SHA1
> On 03/15/2011 08:29 AM, José Fonseca wrote:
> > Attached is a new version of the patch that keeps the extensions sorted
> > alphabetically in the source code, and sorts chronologically in runtime.
> > (Note the patch doesn't apply against the tip of master, but a version a
> > few weeks old -- I'll update before committing to master.) 
> I don't see how this fixes the problem, so perhaps I'm misunderstanding
> the problem.  Don't these buggy apps still get an extension string
> that's longer than they know how to handle?  That's why Ken mentioned
> the use of an environment variable so that the app only ever sees, for
> example, the extensions that existed before 2003.
> After all, the apps that aren't smart enough to dynamically allocate a
> buffer probably also aren't smart enough to use strncmp *and* add a NUL
> terminator to the string.
> Right?

Not really: the app actually appears to truncate (i.e., strncpy & zero
last char).  One can even see the truncated extension string in the
quake console.   

I didn't went to the trouble of disassembling the code, but putting the
old extensions first has always fixed the issue, avoid the bad
performance and crashes.

The crash that happens due to no sorting is probably because the
truncated extension string is inconsistent, or a very basic extension is
missing, causing the app to trip on itself.


More information about the mesa-dev mailing list