Dear Luiz,
Am 11.02.22 um 21:30 schrieb Luiz Augusto von Dentz:
On Fri, Feb 11, 2022 at 8:41 AM Paul Menzel <pmenzel@xxxxxxxxxxxxx> wrote:
Am 11.02.22 um 01:18 schrieb Tedd Ho-Jeong An:
From: Tedd Ho-Jeong An <tedd.an@xxxxxxxxx>
I had a hard time to understand, what the git commit message summary
meant. Maybe:
adapter: Use g_clear_error() to set gerr to NULL to fix segfault
When the GError variable is freeed with g_error_free(), it is not set to
NULL and reusing the same variable again can cause the seg_fault because
it is still pointing the old memory address which is freed.
Could you please include an example stack-/backtrace?
That is part of issue if you open the link:
https://github.com/bluez/bluez/issues/276#issue-1111278644
Yes, I know. I prefer commit messages to be self-contained, as it’s
never known if you are online or the Web service has problems or is shut
down. But of course, if BlueZ does it differently, that is fine.
This patch relaces the g_error_free() to g_clear_error() which frees the
variable and set it to NULL if the variable is used in the function
set*s*
again.
Fixes: 2287c517ca1bd ("adapter: Fix unchecked return value")
Fixes: https://github.com/bluez/bluez/issues/276
To make the tags unambiguous, at least in the Linux kernel world,
*Resolves* or *Closes* are used to refer to issues.
But this is on kernel space, and afaik github uses *Fixes* instead to
auto close the issues, so I don't really follow what you are trying to
suggest here, or do you want github to start following Linux kernel
tags?
GitHub already does. ;-) Resolves, Closes, Fixes all automatically close
the referenced issue.
[…]
Kind regards,
Paul
