[llvm-bugs] [Bug 46515] New: Call abort() instead of exit() on runtime error
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Jun 30 01:45:31 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=46515
Bug ID: 46515
Summary: Call abort() instead of exit() on runtime error
Product: OpenMP
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Runtime Library
Assignee: unassignedbugs at nondot.org
Reporter: gcc.j.kelling at hzdr.de
CC: llvm-bugs at lists.llvm.org
While debugging a openmp target usage inside a complex program, I found, that
libomptarget calls exit() when it encounters a runtime error, which in my case
causes a deadlock instead of program termination.
Specifically, I am seeing the error message:
"Libomptarget fatal error 1: failure of target construct while offloading is
mandatory"
after which the program is hangs in a deadlock instead of terminating.
I suggest to change this to call abort() instead of exit(). The rationale is
the situation in the program I an working on.
# Rationale
The program implements a queue to run kernels on backends, one of which is
based on OpenMP target offload. In my case I am using a synchronous queue, in
which case, a function A() calling a function B() containing an omp target
region holds a mutex lock on the queue within its scope (std::lock_guard)
(effectively while B() is executing).
Another component of the program registers the same queue in a global object.
That objects destructor is responsible for clearing destructing the queue
before program termination. Part of this is synchronizing the queue, which
requires the mutex held by A() to be locked.
When exit() is called inside B(), the stack is not unwound, i.e. the lock held
by A() is not released, but the destructors of global objects like that queue
wrapper are called, which causes a dead lock. This could be avoided by calling
abort() on runtime errors instead.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200630/669fd71d/attachment.html>
More information about the llvm-bugs
mailing list