Friday, July 01, 2022

Re: rawtherapee free(): chunk is already free 0x907fb48e800 when not in gdb

Omar Polo wrote (2022-06-30 10:26 CEST):
> Stefan Hagen <sh+openbsd-ports@codevoid.de> wrote:
> > Omar Polo wrote (2022-06-29 10:12 CEST):
> > > +cc kirby@ (maintainer)
> > >
> > > Stefan Hagen <sh+openbsd-ports@codevoid.de> wrote:
> > > > Abel Abraham Camarillo Ojeda wrote (2022-06-20 08:24 CEST):
> > > > > [...]
> > > > >
> > > > > I now applied the patch correctly, I can no longer reproduce the issue.
> > > > >
> > > > > upstream seems unresponsive about this, any chance of getting it on ports?
> > > >
> > > > The one that rips out all setlocale calls? No.
> > > >
> > > > Here is a better diff, which replaces the setlocale(3) calls with thread
> > > > local (and therefore thread-safe) uselocale(3) calls.
> > > >
> > > > I'm still testing this, because it is not exactly the same as the original.
> > > >
> > > > If it improves the situation on OpenBSD, I'm not opposed to commit these
> > > > patches. Please test and report back.
> > >
> > > I don't use rawtherapee, and my understanding of the locale api is
> > > (voluntarely) scarse, but I'm not sure the patch is right.
> > >
> > > On OpenBSD there shouldn't be issue, because freelocale (AFAIU) is a
> > > no-op, but on other OSes you need to free the locale returned by
> > > newlocale or duplocale.
> >
> > In expanded form we have:
> >
> > locale_t oldloc = duplocale(LC_GLOBAL_LOCALE);
> > locale_t modloc = newlocale(LC_NUMERIC_MASK, "C", oldloc);
> > locale_t newloc = uselocale(modloc);
> >
> > I think we could:
> >
> > locale_t oldloc = duplocale(LC_GLOBAL_LOCALE);
> > locale_t modloc = newlocale(LC_NUMERIC_MASK, "C", oldloc);
> > freelocale(oldloc);
> > locale_t newloc = uselocale(modloc);
> > freelocale(modloc);
> ^^^^^^
> you mean newloc here

No, from my understanding newloc is the resource that's being used.
So oldloc and modloc could be freed.

> > From our uselocale(3) manpage:
> >
> > The current thread uses newloc until uselocale() is called again
> > successfully with a non-null argument in the same thread, and
> > passing newloc to freelocale(3) or newlocale(3) before that results
> > in undefined behaviour.
> >
> > I think calling freelocale(newloc) at this point would result in
> ^^^^^^
> and modloc here, right?

No, newloc. modloc is only read and based on the information in modloc
the thread locale is set. modloc is not copied into the thread locale.

> modloc is in use after uselocale and freelocale(3) it would cause UB,
> while "newloc" is the one used up to that point and _i think_ can be
> free'd. No idea what' the default locale for a thread and if that can
> be passed to uselocale tho.

Read /usr/src/lib/libc/locale/uselocale.c

It uses the passed locale for informational purpose only. It is not
used afterwards. It's really the returned locale that's tricky.

> > undefined behavior.
>
> yes, as it's in use and it's not a good idea to free a resource that's
> being used by something else.
>
> > Best Regards,
> > Stefan
> >
> >
> > > See (but not too closely!) the example from the GNU man page for
> > > newlocale:
> > >
> > > https://man.voidlinux.org/newlocale
> > >
> > > so the patch may be OK for us, but not to fed it to upstream.
>
>

No comments:

Post a Comment