SEGV found by address sanitizer #104
Labels
severity: medium
This issue is of MEDIUM severity.
status: fixed
This issue is a now-fixed bug.
subsystem: core
The issue is within the core of haproxy.
type: bug
This issue describes a bug.
Comments
chipitsine
added
status: needs-triage
|
Hi Ilya,
Thank you, this one is interesting. It's a link-time race between the
init calls. When switching away from constructors to initcalls, I
suspected I'd need multiple stages after thread creation but didn't
have a compelling example to confirm my estimation. Now we have a pretty
good case :
- fd.c registers init_poller_per_thread() to re-allocate a local fd_updt ;
- mworker.c registers mworker_pipe_register_per_thread() to register
its pipe via the struct allocated above.
If you're lucky, the fd thing is done first. If you're unlucky it's the
other way around and it dies. This was triggered by the fact that I got
rid of the specific call (and the startup lock) in run_thread_poll_loop()
recently.
I'm going to modify this so that we have a level corresponding to thread
early allocation (which is needed about everywhere), or we'll get trapped
again.
Willy
|
haproxy-mirror
pushed a commit
that referenced
this issue
May 22, 2019
…backs We currently have the ability to register functions to be called early on thread creation and at thread deinitialization. It turns out this is not sufficient because certain such functions may use resources that are being allocated by the other ones, thus creating a race condition depending only on the linking order. For example the mworker needs to register a file descriptor while the pollers will reallocate the fd_updt[] array. Similarly logs and trashes may be used by some init functions while it's unclear whether they have been deduplicated. The same issue happens on deinit, if the fd_updt[] or trash is released before some functions finish to use them, we'll get into trouble. This patch creates a couple of early and late callbacks for per-thread allocation/freeing of resources. A few init functions were moved there, and the fd init code was split between the two (since it used to both allocate and initialize at once). This way the init/deinit sequence is expected to be safe now. This patch should be backported to 1.9 as at least the trash/log issue seems to be present. The run_thread_poll_loop() code is a bit different there as the mworker is not a callback, but it will have no effect and it's enough to drop the mworker changes. This bug was reported by Ilya Shipitsin in github issue #104.
|
fixed |
TimWolla
added
severity: medium
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
full log: https://travis-ci.org/chipitsine/haproxy-1/jobs/535709949#L1938-L1948
The text was updated successfully, but these errors were encountered: