bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

In GNU Emacs 29.0.50 (build 1, aarch64-apple-darwin21.5.0, NS appkit-2113.50 Version 12.4 (Build 21F79))
 of 2022-07-12 built on Mini.fritz.box
Repository revision: f209650e41d59356a90b5a602abc60c6783bc7b1

This is a Spacemacs profile, with a lot of fringe bitmaps.  The error
happens right after hitting 'q' on the startup screen, when the first
fringe bitmap is displayed.

thread #1: tid = 0x3d47c, 0x0000000103dc4870 libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie(), queue = 'com.apple.main-thread', stop reason = Heap buffer overflow

{
  "access_size": 2,
  "access_type": 0,
  "address": 4402845816,
  "description": "heap-buffer-overflow",
  "instrumentation_class": "AddressSanitizer",
  "pc": 4313240244,
  "stop_type": "fatal_error"
}

frame #5: 0x000000010116d2b4 emacs`ns_define_fringe_bitmap(which=27, bits=0x00000001066e1860, h=12, w=16) at nsterm.m:2906:20
   2903	        /* XBM rows are always round numbers of bytes, with any unused
   2904	           bits ignored.  */
   2905	        int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
-> 2906	        bool bit = bits[byte] & (0x80 >> x%8);
   2907	        if (bit)
   2908	          [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
   2909	      }
(lldb) p byte
(int) $22 = 12

frame #6: 0x0000000101079128 emacs`init_fringe_bitmap(which=27, fb=0x00000001066e1850, once_p=0) at fringe.c:1520:2
   1517	      destroy_fringe_bitmap (which);
   1518	
   1519	      if (rif && rif->define_fringe_bitmap)
-> 1520		rif->define_fringe_bitmap (which, fb->bits, fb->height, fb->width);
   1521	
   1522	      fringe_bitmaps[which] = fb;
   1523	      if (which >= max_used_fringe_bitmap)
(lldb) p *fb
(fringe_bitmap) $21 = {
  bits = 0x00000001066e1860
  height = 12
  width = 16
  period = 0
  align = 0
  dynamic = true
}

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 14 Jul 2022 15:03:36 +0200
> 
> This is a Spacemacs profile, with a lot of fringe bitmaps.  The error
> happens right after hitting 'q' on the startup screen, when the first
> fringe bitmap is displayed.
> 
> thread #1: tid = 0x3d47c, 0x0000000103dc4870 libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie(), queue = 'com.apple.main-thread', stop reason = Heap buffer overflow
> 
> {
>   "access_size": 2,
>   "access_type": 0,
>   "address": 4402845816,
>   "description": "heap-buffer-overflow",
>   "instrumentation_class": "AddressSanitizer",
>   "pc": 4313240244,
>   "stop_type": "fatal_error"
> }
> 
> frame #5: 0x000000010116d2b4 emacs`ns_define_fringe_bitmap(which=27, bits=0x00000001066e1860, h=12, w=16) at nsterm.m:2906:20
>    2903	        /* XBM rows are always round numbers of bytes, with any unused
>    2904	           bits ignored.  */
>    2905	        int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
> -> 2906	        bool bit = bits[byte] & (0x80 >> x%8);
>    2907	        if (bit)
>    2908	          [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
>    2909	      }
> (lldb) p byte
> (int) $22 = 12
> 
> frame #6: 0x0000000101079128 emacs`init_fringe_bitmap(which=27, fb=0x00000001066e1850, once_p=0) at fringe.c:1520:2
>    1517	      destroy_fringe_bitmap (which);
>    1518	
>    1519	      if (rif && rif->define_fringe_bitmap)
> -> 1520		rif->define_fringe_bitmap (which, fb->bits, fb->height, fb->width);
>    1521	
>    1522	      fringe_bitmaps[which] = fb;
>    1523	      if (which >= max_used_fringe_bitmap)
> (lldb) p *fb
> (fringe_bitmap) $21 = {
>   bits = 0x00000001066e1860
>   height = 12
>   width = 16
>   period = 0
>   align = 0
>   dynamic = true
> }

I don't understand this.  What is the dimension of the bits[] array?
It is supposed to be 12 * 2, so how come the index 12 causes access
violation?

Who is the caller of init_fringe_bitmap in this case?

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

> On 2022-07-14,, at 15:56 , Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Thu, 14 Jul 2022 15:03:36 +0200
>> 
>> This is a Spacemacs profile, with a lot of fringe bitmaps.  The error
>> happens right after hitting 'q' on the startup screen, when the first
>> fringe bitmap is displayed.
>> 
>> thread #1: tid = 0x3d47c, 0x0000000103dc4870 libclang_rt.asan_osx_dynamic.dylib`__asan::AsanDie(), queue = 'com.apple.main-thread', stop reason = Heap buffer overflow
>> 
>> {
>>  "access_size": 2,
>>  "access_type": 0,
>>  "address": 4402845816,
>>  "description": "heap-buffer-overflow",
>>  "instrumentation_class": "AddressSanitizer",
>>  "pc": 4313240244,
>>  "stop_type": "fatal_error"
>> }
>> 
>> frame #5: 0x000000010116d2b4 emacs`ns_define_fringe_bitmap(which=27, bits=0x00000001066e1860, h=12, w=16) at nsterm.m:2906:20
>>   2903	        /* XBM rows are always round numbers of bytes, with any unused
>>   2904	           bits ignored.  */
>>   2905	        int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
>> -> 2906	        bool bit = bits[byte] & (0x80 >> x%8);
>>   2907	        if (bit)
>>   2908	          [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
>>   2909	      }
>> (lldb) p byte
>> (int) $22 = 12
>> 
>> frame #6: 0x0000000101079128 emacs`init_fringe_bitmap(which=27, fb=0x00000001066e1850, once_p=0) at fringe.c:1520:2
>>   1517	      destroy_fringe_bitmap (which);
>>   1518	
>>   1519	      if (rif && rif->define_fringe_bitmap)
>> -> 1520		rif->define_fringe_bitmap (which, fb->bits, fb->height, fb->width);
>>   1521	
>>   1522	      fringe_bitmaps[which] = fb;
>>   1523	      if (which >= max_used_fringe_bitmap)
>> (lldb) p *fb
>> (fringe_bitmap) $21 = {
>>  bits = 0x00000001066e1860
>>  height = 12
>>  width = 16
>>  period = 0
>>  align = 0
>>  dynamic = true
>> }
> 
> I don't understand this.  What is the dimension of the bits[] array?
> It is supposed to be 12 * 2, so how come the index 12 causes access
> violation?

I don't understand this either, but it's not an access violation, it's an out-of-bounds access of an allocated memory object, AFAIU.

How do you come to the 12 * 2?  Is that in bytes?  I'm asking because, confusingly for me, the bits in frame #5 is unsigned short *.  (height * width) / sizeof(char) would be 12*2...

> 
> Who is the caller of init_fringe_bitmap in this case?

frame #7: 0x0000000101078558 emacs`Fdefine_fringe_bitmap(bitmap=-> (struct Lisp_Symbol *) $33 = 0x00000001232c81a0, bits=-> (struct Lisp_Vector *) $37 = 0x000000014efefc70, height=-> (struct Lisp_Symbol *) $40 = 0x0000000101b04020, width=-> (EMACS_INT) $42 = 16, align=-> (struct Lisp_Symbol *) $45 = 0x0000000101b04020) at fringe.c:1660:3
   1657	
   1658	  *xfb = fb;
   1659	
-> 1660	  init_fringe_bitmap (n, xfb, 0);
   1661	
   1662	  return bitmap;
   1663	}

(lldb) frame variable
(Lisp_Object) bitmap = -> (struct Lisp_Symbol *) $18 = 0x00000001232c81a0 {
  i = 0x00000000217c4180
}
(Lisp_Object) bits = -> (struct Lisp_Vector *) $22 = 0x000000014efefc70 {
  i = 0x000000014efefc75
}
(Lisp_Object) height = -> (struct Lisp_Symbol *) $25 = 0x0000000101b04020 {
  i = NULL
}
(Lisp_Object) width = -> (EMACS_INT) $27 = 16 {
  i = 0x0000000000000042
}
(Lisp_Object) align = -> (struct Lisp_Symbol *) $30 = 0x0000000101b04020 {
  i = NULL
}
(int) n = 27
(int) h = 12
(int) i = 0
(int) j = 12
(unsigned short *) b = 0x00000001066e6320
(fringe_bitmap) fb = {
  bits = 0x00000001066e6320
  height = 12
  width = 16
  period = 0
  align = 0
  dynamic = true
}
(fringe_bitmap *) xfb = 0x00000001066e6310
(int) fill1 = 0
(int) fill2 = 0

(lldb) p $18->u.s.name 
(Lisp_Object) $58 = -> (struct Lisp_String *) $60 = 0x000000012279d880 {
  i = 0x000000012279d884
}

(lldb) p $60->u.s
(Lisp_String::(unnamed struct)) $61 = {
  size = 42
  size_byte = 42
  intervals = NULL
  data = 0x0000000150832190 "flycheck-fringe-bitmap-double-arrow-hi-res"
}

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

[-- Attachment #1: Type: text/plain, Size: 625 bytes --]



> On 2022-07-14,, at 16:18 , Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>>> 
>>> frame #5: 0x000000010116d2b4 emacs`ns_define_fringe_bitmap(which=27, bits=0x00000001066e1860, h=12, w=16) at nsterm.m:2906:20
>>> 2903	 /* XBM rows are always round numbers of bytes, with any unused
>>> 2904	 bits ignored. */
>>> 2905	 int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
>>> -> 2906	 bool bit = bits[byte] & (0x80 >> x%8);

I think the problem is indeed that bits is unsigned short*.  Otherwise, the /8 and %8 in line 2903 don't make sense to me.  I think "byte" computes an index in a byte (char) array.

WDYT?


[-- Attachment #2: Type: text/html, Size: 2035 bytes --]

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Thu, 14 Jul 2022 16:34:05 +0200
> Cc: 56553@debbugs.gnu.org
> 
> 
>  On 2022-07-14,, at 16:18 , Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> 
>  frame #5: 0x000000010116d2b4 emacs`ns_define_fringe_bitmap(which=27,
>  bits=0x00000001066e1860, h=12, w=16) at nsterm.m:2906:20
>  2903  /* XBM rows are always round numbers of bytes, with any unused
>  2904  bits ignored. */
>  2905  int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
>  -> 2906  bool bit = bits[byte] & (0x80 >> x%8);
> 
> I think the problem is indeed that bits is unsigned short*.  Otherwise, the /8 and %8 in line 2903 don't make
> sense to me.  I think "byte" computes an index in a byte (char) array.
> 
> WDYT?

Do you understand what that loop is trying to do?  What is this line
about:

        if (bit)
          [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];

Anyway, it sounds like you are saying that the code wants to access
the individual bytes of the 'short' elements?

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

> On 2022-07-14,, at 18:55 , Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Thu, 14 Jul 2022 16:34:05 +0200
>> Cc: 56553@debbugs.gnu.org
>> 
>> 
>> On 2022-07-14,, at 16:18 , Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>> 
>> frame #5: 0x000000010116d2b4 emacs`ns_define_fringe_bitmap(which=27,
>> bits=0x00000001066e1860, h=12, w=16) at nsterm.m:2906:20
>> 2903  /* XBM rows are always round numbers of bytes, with any unused
>> 2904  bits ignored. */
>> 2905  int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
>> -> 2906  bool bit = bits[byte] & (0x80 >> x%8);
>> 
>> I think the problem is indeed that bits is unsigned short*.  Otherwise, the /8 and %8 in line 2903 don't make
>> sense to me.  I think "byte" computes an index in a byte (char) array.
>> 
>> WDYT?
> 
> Do you understand what that loop is trying to do?  What is this line
> about:
> 
>        if (bit)
>          [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
> 
> Anyway, it sounds like you are saying that the code wants to access
> the individual bytes of the 'short' elements?

The loop is in full

  for (int y = 0 ; y < h ; y++)
    for (int x = 0 ; x < w ; x++)
      {
        /* XBM rows are always round numbers of bytes, with any unused
           bits ignored.  */
        int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
        bool bit = bits[byte] & (0x80 >> x % 8);
        if (bit)
          [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
      }

In pseudo-code, and with width and height replaced by actual values for the given case:

  for y from 0 to 12-1
    for x from ß to 16-1
      pixel = ...
      if pixel is set
        ...do some API stuff to remember how to draw it...

I think that is the intent.

If we insert the max values for x, y, w, h in the original, we have

   int byte = (12 - 1) * (16/8 + (16%8 != 0 ? 1 : 0) + (16 - 1)/8

which is 

                = 11 * (2 + (0 ? 1 : 0) + 15/8
                = 11 * 2 + 1
		= 23

which would be the right /byte/ to access in the bitmap.  But "bits[byte]" doesn't access the 23rd byte of the bitmap but the 23rd unsigned short, which is byte 46 and 47.  That cannot possibly be right, or?

The NSBezierPath stuff I don't know.  I gather, from a short look at the docs, that one can "record" stuff that should be drawn in such an object.  The path can then later be used to actually draw.  Looks a tad complicated to me to draw single pixels as a rectangle of size 1, but what do I know... 

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

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

> If we insert the max values for x, y, w, h in the original, we have
>
>    int byte = (12 - 1) * (16/8 + (16%8 != 0 ? 1 : 0) + (16 - 1)/8
>
> which is 
>
>                 = 11 * (2 + (0 ? 1 : 0) + 15/8
>                 = 11 * 2 + 1
> 		= 23
>
> which would be the right /byte/ to access in the bitmap.  But
> "bits[byte]" doesn't access the 23rd byte of the bitmap but the 23rd
> unsigned short, which is byte 46 and 47.  That cannot possibly be
> right, or?

Yes, you're right here.  I think that code does want to access the
individual bytes.

> The NSBezierPath stuff I don't know.  I gather, from a short look at
> the docs, that one can "record" stuff that should be drawn in such an
> object.  The path can then later be used to actually draw.  Looks a
> tad complicated to me to draw single pixels as a rectangle of size 1,
> but what do I know...

Believe it or not, it's the only way to record such a pixel without
resulting in annoying scaling artifacts from the OS trying to scale the
image up to monitor resolution.

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

> On 2022-07-15,, at 10:23 , Po Lu <luangruo@yahoo.com> wrote:

> Yes, you're right here.  I think that code does want to access the
> individual bytes.

Interestingly, just doing

        const char *bitmap_bytes = (const char *) bits;
        bool bit = bitmap_bytes[byte] & (0x80 >> x % 8);

here results in garbage fringe bitmaps beign displayed.  I'm stumped.

> 
>> The NSBezierPath stuff I don't know.  I gather, from a short look at
>> the docs, that one can "record" stuff that should be drawn in such an
>> object.  The path can then later be used to actually draw.  Looks a
>> tad complicated to me to draw single pixels as a rectangle of size 1,
>> but what do I know...
> 
> Believe it or not, it's the only way to record such a pixel without
> resulting in annoying scaling artifacts from the OS trying to scale the
> image up to monitor resolution.

Good to know.  I guess it's easier to display a PDF on the Mac than an XBM :-).

Thanks!

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Fri, 15 Jul 2022 11:14:02 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  56553@debbugs.gnu.org
> 
> 
> > On 2022-07-15,, at 10:23 , Po Lu <luangruo@yahoo.com> wrote:
> 
> > Yes, you're right here.  I think that code does want to access the
> > individual bytes.
> 
> Interestingly, just doing
> 
>         const char *bitmap_bytes = (const char *) bits;
>         bool bit = bitmap_bytes[byte] & (0x80 >> x % 8);
> 
> here results in garbage fringe bitmaps beign displayed.  I'm stumped.

Is the machine little-endian or big-endian?

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

> On 2022-07-15,, at 12:37 , Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Date: Fri, 15 Jul 2022 11:14:02 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> 56553@debbugs.gnu.org
>> 
>> 
>>> On 2022-07-15,, at 10:23 , Po Lu <luangruo@yahoo.com> wrote:
>> 
>>> Yes, you're right here.  I think that code does want to access the
>>> individual bytes.
>> 
>> Interestingly, just doing
>> 
>>        const char *bitmap_bytes = (const char *) bits;
>>        bool bit = bitmap_bytes[byte] & (0x80 >> x % 8);
>> 
>> here results in garbage fringe bitmaps beign displayed.  I'm stumped.
> 
> Is the machine little-endian or big-endian?

Good question!  I think it's little-endian, but I'm not 100% sure. 

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Robert Pluim]

>>>>> On Fri, 15 Jul 2022 15:55:40 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:

    >> On 2022-07-15,, at 12:37 , Eli Zaretskii <eliz@gnu.org> wrote:
    >> 
    >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
    >>> Date: Fri, 15 Jul 2022 11:14:02 +0200
    >>> Cc: Eli Zaretskii <eliz@gnu.org>,
    >>> 56553@debbugs.gnu.org
    >>> 
    >>> 
    >>>> On 2022-07-15,, at 10:23 , Po Lu <luangruo@yahoo.com> wrote:
    >>> 
    >>>> Yes, you're right here.  I think that code does want to access the
    >>>> individual bytes.
    >>> 
    >>> Interestingly, just doing
    >>> 
    >>> const char *bitmap_bytes = (const char *) bits;
    >>> bool bit = bitmap_bytes[byte] & (0x80 >> x % 8);
    >>> 
    >>> here results in garbage fringe bitmaps beign displayed.  I'm stumped.
    >> 
    >> Is the machine little-endian or big-endian?

    Gerd> Good question!  I think it's little-endian, but I'm not 100% sure. 

Both Intel and Arm based macs are little-endian

Robert
-- 

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Po Lu <luangruo@yahoo.com>,
>   56553@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 15:57:40 +0200
> 
> >>>>> On Fri, 15 Jul 2022 15:55:40 +0200, Gerd Möllmann <gerd.moellmann@gmail.com> said:
> 
>     >> On 2022-07-15,, at 12:37 , Eli Zaretskii <eliz@gnu.org> wrote:
>     >> 
>     >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>     >>> Date: Fri, 15 Jul 2022 11:14:02 +0200
>     >>> Cc: Eli Zaretskii <eliz@gnu.org>,
>     >>> 56553@debbugs.gnu.org
>     >>> 
>     >>> 
>     >>>> On 2022-07-15,, at 10:23 , Po Lu <luangruo@yahoo.com> wrote:
>     >>> 
>     >>>> Yes, you're right here.  I think that code does want to access the
>     >>>> individual bytes.
>     >>> 
>     >>> Interestingly, just doing
>     >>> 
>     >>> const char *bitmap_bytes = (const char *) bits;
>     >>> bool bit = bitmap_bytes[byte] & (0x80 >> x % 8);
>     >>> 
>     >>> here results in garbage fringe bitmaps beign displayed.  I'm stumped.
>     >> 
>     >> Is the machine little-endian or big-endian?
> 
>     Gerd> Good question!  I think it's little-endian, but I'm not 100% sure. 
> 
> Both Intel and Arm based macs are little-endian

Then I guess my theory doesn't hold water?

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Andreas Schwab]

Does this work?

diff --git a/src/nsterm.m b/src/nsterm.m
index 8e0c4b84f0..30768baced 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -2900,10 +2900,7 @@ Hide the window (X11 semantics)
   for (int y = 0 ; y < h ; y++)
     for (int x = 0 ; x < w ; x++)
       {
-        /* XBM rows are always round numbers of bytes, with any unused
-           bits ignored.  */
-        int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
-        bool bit = bits[byte] & (0x80 >> x%8);
+        bool bit = bits[y] & (1 << (w - x - 1));
         if (bit)
           [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
       }

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

> On 2022-07-15,, at 16:46 , Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> Does this work?
> 
> diff --git a/src/nsterm.m b/src/nsterm.m
> index 8e0c4b84f0..30768baced 100644
> --- a/src/nsterm.m
> +++ b/src/nsterm.m
> @@ -2900,10 +2900,7 @@ Hide the window (X11 semantics)
>   for (int y = 0 ; y < h ; y++)
>     for (int x = 0 ; x < w ; x++)
>       {
> -        /* XBM rows are always round numbers of bytes, with any unused
> -           bits ignored.  */
> -        int byte = y * (w/8 + (w%8 ? 1 : 0)) + x/8;
> -        bool bit = bits[byte] & (0x80 >> x%8);
> +        bool bit = bits[y] & (1 << (w - x - 1));
>         if (bit)
>           [p appendBezierPathWithRect:NSMakeRect (x, y, 1, 1)];
>       }
> 

It does indeed.  Thanks!

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

> On 2022-07-15,, at 17:10 , Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> 
> It does indeed.  Thanks!
> 

Just wanted to add, in case someone wonders what's going on -- a look at define-fringe-bitmap helps.

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

On 22-07-15 17:16 , Gerd Möllmann wrote:
> Just wanted to add, in case someone wonders what's going on -- a look 
> at define-fringe-bitmap helps.

That was a bit cryptic in hindsight, sorry.

Fact of the matter is, define-fringe-bitmap creates an array of unsigned 
short, with an element for each row of the bitmap.  The max width of 
fringe bitmaps is 16, the function checks that.  That has nothing to do 
with XBM (that was used 20 years ago...).

So, that's the reason why Andreas' fix works.

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Andreas Schwab]

Installed.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  56553@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 16:23:09 +0800
> 
> > The NSBezierPath stuff I don't know.  I gather, from a short look at
> > the docs, that one can "record" stuff that should be drawn in such an
> > object.  The path can then later be used to actually draw.  Looks a
> > tad complicated to me to draw single pixels as a rectangle of size 1,
> > but what do I know...
> 
> Believe it or not, it's the only way to record such a pixel without
> resulting in annoying scaling artifacts from the OS trying to scale the
> image up to monitor resolution.

How about some comment there explaining what it tries to do?

bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS

[Gerd Möllmann]

I’ll add a comment if I ever get it working…

> Am 15.07.2022 um 12:35 schrieb Eli Zaretskii <eliz@gnu.org>:
> 
> 
>> 
>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  56553@debbugs.gnu.org
>> Date: Fri, 15 Jul 2022 16:23:09 +0800
>> 
>>> The NSBezierPath stuff I don't know.  I gather, from a short look at
>>> the docs, that one can "record" stuff that should be drawn in such an
>>> object.  The path can then later be used to actually draw.  Looks a
>>> tad complicated to me to draw single pixels as a rectangle of size 1,
>>> but what do I know...
>> 
>> Believe it or not, it's the only way to record such a pixel without
>> resulting in annoying scaling artifacts from the OS trying to scale the
>> image up to monitor resolution.
> 
> How about some comment there explaining what it tries to do?