GNU bug report logs - #79156
igc: igc_xpalloc_ambig SEGV

Previous Next

To reply to this bug, email your comments to 79156 AT debbugs.gnu.org.
There is no need to reopen the bug first.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Pip Cet <pipcet <at> protonmail.com>, Helmut Eller <eller.helmut <at> gmail.com>
Subject: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 17:26:59 +0200

We have

igc.c:
 3465 void *
 3466 igc_xpalloc_ambig (void *old_pa, ptrdiff_t *nitems, ptrdiff_t nitems_incr_min,
 3467                    ptrdiff_t nitems_max, ptrdiff_t item_size)
 3468 {
 3469   ptrdiff_t old_nitems = *nitems;

and igc_xpalloc_ambig is called here with a NULL old_pa, and non-zero
new_size:

charset.c:
 1135           struct charset *new_table =
 1136 #ifdef HAVE_MPS
 1137             igc_xpalloc_ambig
 1138 #else
 1139             xpalloc
 1140 #endif
 1141             (0, &new_size, 1,
 1142              min (INT_MAX, MOST_POSITIVE_FIXNUM),
 1143              sizeof *charset_table);

In this case, this loop deferences a null pointer. 

igc.c:
 3477   mps_word_t *new_word = new_pa;
 3478   for (ptrdiff_t i = 0; i < (old_nitems * item_size) / sizeof (mps_word_t); i++)
 3479     new_word[i] = old_word[i];

This apparently currently never happens in feature/igc, but it could,
and it does when using igc with emacs-mac's mac-win.el which defines
charsets.

Quick workaround is something like

modified   src/igc.c
@@ -3466,7 +3466,7 @@ igc_xfree (void *p)
 igc_xpalloc_ambig (void *old_pa, ptrdiff_t *nitems, ptrdiff_t nitems_incr_min,
 		   ptrdiff_t nitems_max, ptrdiff_t item_size)
 {
-  ptrdiff_t old_nitems = *nitems;
+  ptrdiff_t old_nitems = old_pa == NULL ? 0 : *nitems;
   ptrdiff_t new_nitems = *nitems;
   ptrdiff_t nbytes = xpalloc_nbytes (old_pa, &new_nitems, nitems_incr_min,
 				     nitems_max, item_size);

Likewise in other igc_xpalloc variants, and one could exploit old_pa ==
NULL, and so on.

If someone else has the time to fix this, that would be nice because I'm
doing something else ATM.

Message #8 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Helmut Eller <eller.helmut <at> gmail.com>, 79156 <at> debbugs.gnu.org
Subject: Re: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 16:00:23 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> We have
>
> igc.c:
>  3465 void *
>  3466 igc_xpalloc_ambig (void *old_pa, ptrdiff_t *nitems, ptrdiff_t nitems_incr_min,
>  3467                    ptrdiff_t nitems_max, ptrdiff_t item_size)
>  3468 {
>  3469   ptrdiff_t old_nitems = *nitems;
>
> and igc_xpalloc_ambig is called here with a NULL old_pa, and non-zero
> new_size:
>
> charset.c:
>  1135           struct charset *new_table =
>  1136 #ifdef HAVE_MPS
>  1137             igc_xpalloc_ambig
>  1138 #else
>  1139             xpalloc
>  1140 #endif
>  1141             (0, &new_size, 1,
>  1142              min (INT_MAX, MOST_POSITIVE_FIXNUM),
>  1143              sizeof *charset_table);
>
> In this case, this loop deferences a null pointer.
>
> igc.c:
>  3477   mps_word_t *new_word = new_pa;
>  3478   for (ptrdiff_t i = 0; i < (old_nitems * item_size) / sizeof (mps_word_t); i++)
>  3479     new_word[i] = old_word[i];
>
> This apparently currently never happens in feature/igc, but it could,
> and it does when using igc with emacs-mac's mac-win.el which defines
> charsets.

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.

(Of course, the reason for the static charset_table_init variable was
unexec, and now that reason is gone we should just remove it and use
plain xpalloc)

> Quick workaround is something like
>
> modified   src/igc.c
> @@ -3466,7 +3466,7 @@ igc_xfree (void *p)
>  igc_xpalloc_ambig (void *old_pa, ptrdiff_t *nitems, ptrdiff_t nitems_incr_min,
>  		   ptrdiff_t nitems_max, ptrdiff_t item_size)
>  {
> -  ptrdiff_t old_nitems = *nitems;
> +  ptrdiff_t old_nitems = old_pa == NULL ? 0 : *nitems;
>    ptrdiff_t new_nitems = *nitems;
>    ptrdiff_t nbytes = xpalloc_nbytes (old_pa, &new_nitems, nitems_incr_min,
>  				     nitems_max, item_size);

LGTM.

> Likewise in other igc_xpalloc variants, and one could exploit old_pa ==
> NULL, and so on.

Do we need it for those?

> If someone else has the time to fix this, that would be nice because I'm
> doing something else ATM.

I'll push this if there are no objections.

commit 962e9be111402e1c83c418bea9e75f23a423ccc6 (HEAD)
Author: Pip Cet <pipcet <at> protonmail.com>
Date:   Sat Aug 2 15:51:13 2025 +0000

    [MPS] Avoid segfaults for some inconsistent arguments in igc_xpalloc
    
    Fdefine_charset_internal calls igc_xpalloc with a NULL pointer as
    OLD_PA and a non-zero *NITEMS value.
    
    * src/igc.c (igc_xpalloc_ambig):
    (igc_xpalloc_exact):
    (igc_xpalloc_lisp_objs_exact): Handle OLD_PA == NULL, *NITEMS != 0.

diff --git a/src/igc.c b/src/igc.c
index f3c98fbe49c..4eb57a3072b 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -3473,7 +3473,7 @@ igc_xfree (void *p)
 igc_xpalloc_ambig (void *old_pa, ptrdiff_t *nitems, ptrdiff_t nitems_incr_min,
 		   ptrdiff_t nitems_max, ptrdiff_t item_size)
 {
-  ptrdiff_t old_nitems = *nitems;
+  ptrdiff_t old_nitems = old_pa ? *nitems : 0;
   ptrdiff_t new_nitems = *nitems;
   ptrdiff_t nbytes = xpalloc_nbytes (old_pa, &new_nitems, nitems_incr_min,
 				     nitems_max, item_size);
@@ -3496,7 +3496,7 @@ igc_xpalloc_exact (void **pa_cell, ptrdiff_t *nitems,
 		   void *closure)
 {
   void *old_pa = *pa_cell;
-  ptrdiff_t old_nitems = *nitems;
+  ptrdiff_t old_nitems = old_pa ? *nitems : 0;
   ptrdiff_t new_nitems = *nitems;
   ptrdiff_t nbytes = xpalloc_nbytes (old_pa, &new_nitems, nitems_incr_min,
 				     nitems_max, item_size);
@@ -3556,7 +3556,7 @@ igc_xpalloc_lisp_objs_exact (Lisp_Object *pa, ptrdiff_t *nitems,
 			     ptrdiff_t nitems_incr_min, ptrdiff_t nitems_max,
 			     const char *label)
 {
-  ptrdiff_t nitems_old = *nitems;
+  ptrdiff_t nitems_old = pa ? *nitems : 0;
   ptrdiff_t nitems_new = nitems_old;
   ptrdiff_t nbytes
     = xpalloc_nbytes (pa, &nitems_new, nitems_incr_min, nitems_max, word_size);

Pip

Message #11 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: gerd.moellmann <at> gmail.com, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 19:27:27 +0300

> Cc: Helmut Eller <eller.helmut <at> gmail.com>, 79156 <at> debbugs.gnu.org
> Date: Sat, 02 Aug 2025 16:00:23 +0000
> From:  Pip Cet via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> > We have
> >
> > igc.c:
> >  3465 void *
> >  3466 igc_xpalloc_ambig (void *old_pa, ptrdiff_t *nitems, ptrdiff_t nitems_incr_min,
> >  3467                    ptrdiff_t nitems_max, ptrdiff_t item_size)
> >  3468 {
> >  3469   ptrdiff_t old_nitems = *nitems;
> >
> > and igc_xpalloc_ambig is called here with a NULL old_pa, and non-zero
> > new_size:
> >
> > charset.c:
> >  1135           struct charset *new_table =
> >  1136 #ifdef HAVE_MPS
> >  1137             igc_xpalloc_ambig
> >  1138 #else
> >  1139             xpalloc
> >  1140 #endif
> >  1141             (0, &new_size, 1,
> >  1142              min (INT_MAX, MOST_POSITIVE_FIXNUM),
> >  1143              sizeof *charset_table);
> >
> > In this case, this loop deferences a null pointer.
> >
> > igc.c:
> >  3477   mps_word_t *new_word = new_pa;
> >  3478   for (ptrdiff_t i = 0; i < (old_nitems * item_size) / sizeof (mps_word_t); i++)
> >  3479     new_word[i] = old_word[i];
> >
> > This apparently currently never happens in feature/igc, but it could,
> > and it does when using igc with emacs-mac's mac-win.el which defines
> > charsets.
> 
> 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;

Regarding the code in charset.c, it happened when xpalloc was added
there, see commit 0065d05491ce.  The original code called xmalloc and
then copied the table.  The FIXME comment at the end of the block
tries to explain why the obvious solution of passing &charset_table as
the first argument to xpalloc was not taken: we were not sure this is
not on purpose.

Message #14 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Pip Cet <pipcet <at> protonmail.com>, eller.helmut <at> gmail.com,
 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 18:41:19 +0200

Eli Zaretskii <eliz <at> gnu.org> 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.

Message #17 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 17:07:35 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> 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).

However, xrealloc does handle the case, and evxprintf relies on that, so
we shouldn't change anything further at this point.

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.

Pip

Message #20 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: gerd.moellmann <at> gmail.com, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 20:13:41 +0300

> Date: Sat, 02 Aug 2025 17:07:35 +0000
> From: Pip Cet <pipcet <at> protonmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> 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.

Message #23 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 17:24:35 +0000

"Eli Zaretskii" <eliz <at> gnu.org> writes:

>> Date: Sat, 02 Aug 2025 17:07:35 +0000
>> From: Pip Cet <pipcet <at> protonmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
>>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>> > Eli Zaretskii <eliz <at> gnu.org> 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.

Here's the code:

  if (! pa)
    *nitems = 0;
  if (n - n0 < nitems_incr_min
      && (ckd_add (&n, n0, nitems_incr_min)
	  || (0 <= nitems_max && nitems_max < n)
	  || ckd_mul (&nbytes, n, item_size)))
    memory_full (SIZE_MAX);
  pa = xrealloc (pa, nbytes);
  *nitems = n;

Since the final line sets *NITEMS unconditionally, the first two lines
have no effect unless we either call memory_full or xrealloc exits
nonlocally, which it does only if we run out of memory.

So to say the code you quoted "doesn't have anything to do with running
out of memory" seems incorrect to me; it has an effect only if we run
out of memory.

>> 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.

I think the point is only to reuse the larger-buffer-size calculation
xpalloc performs. There are probably cleaner ways of doing that.

Pip

Message #26 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sat, 02 Aug 2025 19:30:40 +0200

Pip Cet <pipcet <at> protonmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> 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).

Sorry, I'm currently to unconcentrated to follow. I just wanted to say
that it would be good to make the functions are compatible with xpalloc,
whatever that means.

Message #29 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sun, 03 Aug 2025 14:52:45 +0200

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Pip Cet <pipcet <at> protonmail.com> writes:
>
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>
>>> Eli Zaretskii <eliz <at> gnu.org> 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).
>
> Sorry, I'm currently to unconcentrated to follow. I just wanted to say
> that it would be good to make the functions are compatible with xpalloc,
> whatever that means.

Do you want me to look at your patch? I'd rather just rely on you,
though :-).

And while everyone is on board: I was making emacs-mac use igc
in my Emacs. Seems to have worked, I'm writing this from

  ELISP> (and (featurep 'mac) (featurep 'mps))
  t

Only minimal additions to igc.[ch] were necessary because mac uses a
Lisp and a GUI thread, and so on, so I couldn't use init_igc for mac.
Two new functions in äifdef HAVE_MAC_GUI instead, igc_init_mac_early and
_late.

Message #32 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Pip Cet <pipcet <at> protonmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sun, 03 Aug 2025 13:13:45 +0000

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
>> Pip Cet <pipcet <at> protonmail.com> writes:
>>
>>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>>>
>>>> Eli Zaretskii <eliz <at> gnu.org> 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).
>>
>> Sorry, I'm currently to unconcentrated to follow. I just wanted to say
>> that it would be good to make the functions are compatible with xpalloc,
>> whatever that means.
>
> Do you want me to look at your patch? I'd rather just rely on you,
> though :-).

Pushed now. Can you confirm it works and close this bug?

> And while everyone is on board: I was making emacs-mac use igc
> in my Emacs. Seems to have worked, I'm writing this from
>
>   ELISP> (and (featurep 'mac) (featurep 'mps))
>   t
>
> Only minimal additions to igc.[ch] were necessary because mac uses a
> Lisp and a GUI thread, and so on, so I couldn't use init_igc for mac.
> Two new functions in äifdef HAVE_MAC_GUI instead, igc_init_mac_early and
> _late.

That sounds like an acceptable price to support macOS better. I don't
use macOS, though, so I can't really say anything about the two ports
and their differences.

Pip

Message #35 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Pip Cet <pipcet <at> protonmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, eller.helmut <at> gmail.com, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sun, 03 Aug 2025 15:34:40 +0200

Pip Cet <pipcet <at> protonmail.com> writes:

> Pushed now. Can you confirm it works and close this bug?

Cherry-picked, built, and verified. Thanks!

>> And while everyone is on board: I was making emacs-mac use igc
>> in my Emacs. Seems to have worked, I'm writing this from
>>
>>   ELISP> (and (featurep 'mac) (featurep 'mps))
>>   t
>>
>> Only minimal additions to igc.[ch] were necessary because mac uses a
>> Lisp and a GUI thread, and so on, so I couldn't use init_igc for mac.
>> Two new functions in äifdef HAVE_MAC_GUI instead, igc_init_mac_early and
>> _late.
>
> That sounds like an acceptable price to support macOS better. I don't
> use macOS, though, so I can't really say anything about the two ports
> and their differences.

Yes, I think so too. Let's see how that all plays out. I've old JD that
it's available. And I'm rubbing my hands together that I have a stable
GUI, and it doesn't stutter :-)

Closing.

Message #40 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Stéphane Marks <shipmints <at> gmail.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Pip Cet <pipcet <at> protonmail.com>, eller.helmut <at> gmail.com,
 Eli Zaretskii <eliz <at> gnu.org>, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sun, 3 Aug 2025 10:05:28 -0400

[Message part 1 (text/plain, inline)]

On Sun, Aug 3, 2025 at 8:53 AM Gerd Möllmann <gerd.moellmann <at> gmail.com>
wrote:

> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>
> > Pip Cet <pipcet <at> protonmail.com> writes:
> >
> >> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> >>
> >>> Eli Zaretskii <eliz <at> gnu.org> 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).
> >
> > Sorry, I'm currently to unconcentrated to follow. I just wanted to say
> > that it would be good to make the functions are compatible with xpalloc,
> > whatever that means.
>
> Do you want me to look at your patch? I'd rather just rely on you,
> though :-).
>
> And while everyone is on board: I was making emacs-mac use igc
> in my Emacs. Seems to have worked, I'm writing this from
>
>   ELISP> (and (featurep 'mac) (featurep 'mps))
>   t
>
> Only minimal additions to igc.[ch] were necessary because mac uses a
> Lisp and a GUI thread, and so on, so I couldn't use init_igc for mac.
> Two new functions in äifdef HAVE_MAC_GUI instead, igc_init_mac_early and
> _late.
>

Do you think you'll push that igc merged branch up to JD's git repo?

[Message part 2 (text/html, inline)]

Message #43 received at 79156 <at> debbugs.gnu.org (full text, mbox):

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Stéphane Marks <shipmints <at> gmail.com>
Cc: Pip Cet <pipcet <at> protonmail.com>, eller.helmut <at> gmail.com,
 Eli Zaretskii <eliz <at> gnu.org>, 79156 <at> debbugs.gnu.org
Subject: Re: bug#79156: igc: igc_xpalloc_ambig SEGV
Date: Sun, 03 Aug 2025 16:18:47 +0200

Stéphane Marks <shipmints <at> gmail.com> writes:

> Do you think you'll push that igc merged branch up to JD's git repo?

What I currently have is in my fork, which contains a lot of other
stuff, like CL packages and so on. I've told JD that I have something,
and the rest I just let happen :-).

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.