Thread (5 messages) 5 messages, 5 authors, 2023-12-04

Re: [PATCH 2/2] checkout: forbid "-B <branch>" from touching a branch used elsewhere

From: Willem Verstraeten <hidden>
Date: 2023-12-04 12:21:06

Hi everyone,

It's not clear for me from the email thread what the status is of this
bug report, and whether there is still something expected from me.

Is the current consensus that this is a real issue that needs fixing?
If so, does the current patch-set fix the issue, and how does the fix
get into (one of) the next release(s)?

Do I still need to do something?

Kind regards,
Willem

On Thu, 30 Nov 2023 at 16:22, Phillip Wood [off-list ref] wrote:
Hi Junio

On 27/11/2023 01:51, Junio C Hamano wrote:
quoted
Phillip Wood [off-list ref] writes:
quoted
At the moment this is academic as neither of the test scripts changed
by this patch are leak free and so I don't think we need to worry
about it but it raises an interesting question about how we should
handle memory leaks when dying. Leaving the leak when dying means that
a test script that tests an expected failure will never be leak free
but using UNLEAK() would mean we miss a leak being introduced in the
successful case should the call to "free()" ever be removed.
Is there a leak here?  The piece of memory is pointed at by an on-stack
variable full_ref when leak sanitizer starts scanning the heap and
the stack just before the process exits due to die, so I do not see
a reason to worry about this particular variable over all the other
on stack variables we accumulated before the control reached this
point of the code.
Oh, good point. I was thinking "we exit without calling free() so it is
leaked" but as you say the leak checker (thankfully) does not consider
it a leak as there is still a reference to the allocation on the stack.

Sorry for the noise

Phillip
quoted
Are you worried about optimizing compilers that behave more cleverly
than their own good to somehow lose the on-stack reference to
full_ref while calling die_if_switching_to_a_branch_in_use()?  We
might need to squelch them with UNLEAK() but that does not mean we
have to remove the free() we see above, and I suspect a more
productive use of our time to solve that issue is ensure that our
leak-sanitizing build will not triger such an unwanted optimization
anyway.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help