On Mon, Feb 17, 2014 at 11:03 PM, Ian Romanick <i...@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.
/Juha-Pekka
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/mesa-dev
