[Mesa-dev] [PATCH 00/10] Klocwork related pathes
Ian Romanick
idr at freedesktop.org
Fri Feb 21 17:17:54 PST 2014
On 02/21/2014 05:47 AM, Juha-Pekka Heikkilä wrote:
> On Mon, Feb 17, 2014 at 11:03 PM, Ian Romanick <idr at freedesktop.org> wrote:
>> On 02/17/2014 08:21 AM, Juha-Pekka Heikkila wrote:
>>> Resend of the earlier glx patches with the issue pointed out by Petri fixed.
>>>
>>> Patch number five is a bit special. hash_table_insert() and
>>> hash_table_replace() don't really have a way to report errors and I did not
>>> want to go changing the api since these are called from so many places thus
>>> the case of null (c)allocation is handled just inside the functions and
>>> relied low memory situation is handled outside the function properly.
>>
>> Right. I'm a bit skeptical about patches 5 and 9 for that reason. I
>> think if we add a function _mesa_error_no_memory(void) to
>> src/mesa/errors.c that can at least set GL_OUT_OF_MEMORY in the context,
>> I'd be a bit more happy. The GL spec allows us to leave things in an
>> indeterminate state when we're out of memory. We really do need to let
>> the application know what happend, though.
>>
>> Something like...
>>
>> void
>> _mesa_error_no_memory(void)
>> {
>> GET_CURRENT_CONTEXT(ctx);
>>
>> _mesa_error(ctx, GL_OUT_OF_MEMORY, "out of memory");
>> }
>>
>> ought to be enough. We do need to audit the various paths through
>> _mesa_error to make sure they can handle no memory situations.
>>
>
> These seem to be a bit more tricky as patches five and nine affect
> glsl compiler side also where I don't have the context. I guess I need
> to see a way to leak the error through some return values for whoever
> called here. Previous places where such errors were trying to be
> reported seem to be mostly returning -1 lacking any additional
> information why error was given.
That's why I was suggesting the helper function. The macro
GET_CURRENT_CONTEXT(ctx) gets the context. It's always available somewhere.
> /Juha-Pekka
More information about the mesa-dev
mailing list