---- On Tue, 27 Jul 2021 17:47:12 +0200 Seebs <se...@seebs.net> wrote ----
> On Tue, 27 Jul 2021 13:49:06 +0200
> "Damian Wrobel" <dwro...@ertelnet.rybnik.pl> wrote:
>
> > Fixes the following warning:
> > pseudo_client.c: In function ‘pseudo_client_op’:
> > cc1: warning: function may return address of local variable
> > [-Wreturn-local-addr] pseudo_client.c:1592:22: note: declared here
> > 1592 | pseudo_msg_t msg = { .type = PSEUDO_MSG_OP };
> > | ^~~
> >
> > Signed-off-by: Damian Wrobel <dwro...@ertelnet.rybnik.pl>
> > ---
> > pseudo_client.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/pseudo_client.c b/pseudo_client.c
> > index 2583bca..f1d09ff 100644
> > --- a/pseudo_client.c
> > +++ b/pseudo_client.c
> > @@ -1889,7 +1889,7 @@ pseudo_client_op(pseudo_op_t op, int access,
> > int fd, int dirfd, const char *path case OP_CHROOT:
> > if (pseudo_client_chroot(path) == 0) {
> > /* return a non-zero value to show
> > non-failure */
> > - result = &msg;
> > + result = pseudo_msg_dup(&msg);
>
> This is a memory leak.
If the function needs to return "pseudo_msg_t *", then it has to return a valid
pointer.
Returning a pointer to a local non static variable is an error as this address
becomes invalid immediately after this function returns.
The returned pointer has to be freed by the caller not by the callee function
itself.
I didn't mention that in the commit message but with this fix I stopped to
observing mysterious pseudo abort build failures (at least so far).
So I'm curious about your experience with it. In other words the revert made
here[1] didn't help for our cases.
[1]
http://git.yoctoproject.org/cgit/cgit.cgi/pseudo/commit/?h=oe-core&id=b988b0a6b8afd8d459bc9a2528e834f63a3d59b2
--
Regards,
Damian
>
> That said, I have no idea how the underlying bug escaped notice all
> this time, it's definitely a bug. I think it is actually safe to just
> make msg be static, because pseudo_client_op is protected by a lock
> and is never executed more than once at a time.
>
> On reflection: I think the way it worked is that in that case, the
> actual message isn't looked at, just checked for nullness, but this
> is still undefined behavior because the result is a pointer to storage
> after the storage's lifetime, and formally you can't even check those
> for "is or isn't null".
>
> -s
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#154174):
https://lists.openembedded.org/g/openembedded-core/message/154174
Mute This Topic: https://lists.openembedded.org/mt/84479678/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
