Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV

From: Eli Zaretskii <[email-masked]>
Date: Sat, 02 Aug 2025 20:13:41 +0300

> Date: Sat, 02 Aug 2025 17:07:35 +0000
> From: Pip Cet <[email-masked]>
> Cc: Eli Zaretskii <[email-masked]>, [email-masked], [email-masked]
> 
> Gerd Möllmann <[email-masked]> writes:
> 
> > Eli Zaretskii <[email-masked]> writes:
> >
> >>> Ouch. That seems to me to be a bug in how charset.c calls xpalloc, but
> >>> I'm not sure whether there are other callers that rely on this behavior,
> >>> so it's safest to work around it.
> >>
> >> xpalloc handles this case:
> >>
> >>   if (! pa)
> >>     *nitems = 0;
> >
> > Yeah, I'd rather check the other igc variants of xpalloc, to make sure
> > they are compatible with the original, even if no one else uses that
> > particular feature.
> 
> That's what I did, I think?
> 
> The code above doesn't have any effect unless we run out of memory (even
> then, it won't have an effect if NITEMS is a stack variable in a frame
> that's unwound by memory_full).

The code above in xpalloc doesn't have anything to do with running out
of memory, because it tests the value of the argument passed to
xpalloc before calling xrealloc.

> The FIXME comment in charset.c should be amended to point out that
> charset_table usually lives in the pdump, and xpalloc does not like
> pdumper object pointers, so we'd have to check that before freeing
> charset_table.

If this is the reason, then there's no reason to call xpalloc in the
first place, right?  We could call xmalloc instead, since we already
memcpy the old table to the newly-allocated memory.