Horton

Thread

Commits

  1. Fix leak of LLVM "fatal-on-oom" section counter.

  1. Missing llvm_leave_fatal_on_oom() call

    Heikki Linnakangas <hlinnaka@iki.fi> — 2023-02-21T14:50:53Z

    llvm_release_context() calls llvm_enter_fatal_on_oom(), but it never 
calls llvm_leave_fatal_on_oom(). Isn't that a clear leak?

(spotted this while investigating 
https://www.postgresql.org/message-id/a53cacb0-8835-57d6-31e4-4c5ef196de1a@deepbluecap.com, 
but it seems unrelated)

- Heikki

  2. Re: Missing llvm_leave_fatal_on_oom() call

    Daniel Gustafsson <daniel@yesql.se> — 2023-07-04T16:33:10Z

    > On 21 Feb 2023, at 15:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> 
> llvm_release_context() calls llvm_enter_fatal_on_oom(), but it never calls llvm_leave_fatal_on_oom(). Isn't that a clear leak?

Not sure how much of a leak it is since IIUC LLVM just stores a function
pointer to our error handler, but I can't see a reason not clean it up here.
The attached fix LGTM and passes make check with jit_above_cost set to zero.

--
Daniel Gustafsson

  3. Re: Missing llvm_leave_fatal_on_oom() call

    Heikki Linnakangas <hlinnaka@iki.fi> — 2023-07-05T10:34:38Z

    On 04/07/2023 19:33, Daniel Gustafsson wrote:
>> On 21 Feb 2023, at 15:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>
>> llvm_release_context() calls llvm_enter_fatal_on_oom(), but it never calls llvm_leave_fatal_on_oom(). Isn't that a clear leak?
> 
> Not sure how much of a leak it is since IIUC LLVM just stores a function
> pointer to our error handler, but I can't see a reason not clean it up here.
> The attached fix LGTM and passes make check with jit_above_cost set to zero.

Pushed to all live branches, thanks for the review!

-- 
Heikki Linnakangas
Neon (https://neon.tech)