[Mesa-dev] [PATCH 12/17] i965: Replace exit(1) with abort() when command submission fails.
Eero Tamminen
eero.t.tamminen at intel.com
Wed Sep 6 14:28:40 UTC 2017
Hi,
On 06.09.2017 03:09, Kenneth Graunke wrote:
> Calling exit(1) when execbuffer fails is not necessarily safe.
> When running Piglit tests with a Mesa that submitted invalid commands
> to the GPU, I discovered the following problem:
>
> 1. do_flush_locked fails and calls exit(1)...invoking atexit handlers.
> 2. Piglit tries to clean up after itself, and does eglMakeCurrent to
> release the current context.
> 3. MakeCurrent calls glFlush (or the internal hook for that)
> 4. glFlush calls intel_batchbuffer_flush
>
> So we end up trying to flush the batch...in the middle of flushing the
> batch...with code that isn't designed to be reentrant. So it breaks
> even worse than before. In my case, it just outright crashed.
>
> Calling abort() is probably not what we want either, but it at least
> bypasses atexit() handlers, so it won't hit this ugly reentrancy
> problem.
If you just want to avoid atexit() handlers, you can use _exit().
That one doesn't trigger ABORT handler.
(Which may be good or bad depending on what you want. I think SDL by
default traps ABORT among many other things, to restore screen mode on
emergency exits.)
- Eero
> ---
> src/mesa/drivers/dri/i965/intel_batchbuffer.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/mesa/drivers/dri/i965/intel_batchbuffer.c b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> index 491aa12dd63..637705226f0 100644
> --- a/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> +++ b/src/mesa/drivers/dri/i965/intel_batchbuffer.c
> @@ -679,7 +679,7 @@ do_flush_locked(struct brw_context *brw, int in_fence_fd, int *out_fence_fd)
>
> if (ret != 0) {
> fprintf(stderr, "intel_do_flush_locked failed: %s\n", strerror(-ret));
> - exit(1);
> + abort();
> }
>
> return ret;
>
More information about the mesa-dev
mailing list