unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
@ 2022-07-14 13:03 Gerd Möllmann
  2022-07-14 13:56 ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-14 13:03 UTC (permalink / raw)
  To: 56553

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
}






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-14 13:03 bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS Gerd Möllmann
@ 2022-07-14 13:56 ` Eli Zaretskii
  2022-07-14 14:18   ` Gerd Möllmann
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-07-14 13:56 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56553

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-14 13:56 ` Eli Zaretskii
@ 2022-07-14 14:18   ` Gerd Möllmann
  2022-07-14 14:34     ` Gerd Möllmann
  0 siblings, 1 reply; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-14 14:18 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 56553



> 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"
}







^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-14 14:18   ` Gerd Möllmann
@ 2022-07-14 14:34     ` Gerd Möllmann
  2022-07-14 16:55       ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-14 14:34 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 56553

[-- 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 --]

^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-14 14:34     ` Gerd Möllmann
@ 2022-07-14 16:55       ` Eli Zaretskii
  2022-07-14 18:25         ` Gerd Möllmann
  0 siblings, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-07-14 16:55 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56553

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-14 16:55       ` Eli Zaretskii
@ 2022-07-14 18:25         ` Gerd Möllmann
  2022-07-15  8:23           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-14 18:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 56553



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







^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-14 18:25         ` Gerd Möllmann
@ 2022-07-15  8:23           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-15  9:14             ` Gerd Möllmann
  2022-07-15 10:35             ` Eli Zaretskii
  0 siblings, 2 replies; 19+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-07-15  8:23 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: 56553, Eli Zaretskii

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.





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15  8:23           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-07-15  9:14             ` Gerd Möllmann
  2022-07-15 10:37               ` Eli Zaretskii
  2022-07-15 14:46               ` Andreas Schwab
  2022-07-15 10:35             ` Eli Zaretskii
  1 sibling, 2 replies; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-15  9:14 UTC (permalink / raw)
  To: Po Lu; +Cc: 56553, Eli Zaretskii


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




^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15  8:23           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-07-15  9:14             ` Gerd Möllmann
@ 2022-07-15 10:35             ` Eli Zaretskii
  2022-07-15 10:37               ` Gerd Möllmann
  1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-07-15 10:35 UTC (permalink / raw)
  To: Po Lu; +Cc: gerd.moellmann, 56553

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15  9:14             ` Gerd Möllmann
@ 2022-07-15 10:37               ` Eli Zaretskii
  2022-07-15 13:55                 ` Gerd Möllmann
  2022-07-15 14:46               ` Andreas Schwab
  1 sibling, 1 reply; 19+ messages in thread
From: Eli Zaretskii @ 2022-07-15 10:37 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: luangruo, 56553

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 10:35             ` Eli Zaretskii
@ 2022-07-15 10:37               ` Gerd Möllmann
  0 siblings, 0 replies; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-15 10:37 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, 56553

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?





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 10:37               ` Eli Zaretskii
@ 2022-07-15 13:55                 ` Gerd Möllmann
  2022-07-15 13:57                   ` Robert Pluim
  0 siblings, 1 reply; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-15 13:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Po Lu, 56553



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







^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 13:55                 ` Gerd Möllmann
@ 2022-07-15 13:57                   ` Robert Pluim
  2022-07-15 14:26                     ` Eli Zaretskii
  0 siblings, 1 reply; 19+ messages in thread
From: Robert Pluim @ 2022-07-15 13:57 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Po Lu, 56553, Eli Zaretskii

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 13:57                   ` Robert Pluim
@ 2022-07-15 14:26                     ` Eli Zaretskii
  0 siblings, 0 replies; 19+ messages in thread
From: Eli Zaretskii @ 2022-07-15 14:26 UTC (permalink / raw)
  To: Robert Pluim; +Cc: gerd.moellmann, luangruo, 56553

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15  9:14             ` Gerd Möllmann
  2022-07-15 10:37               ` Eli Zaretskii
@ 2022-07-15 14:46               ` Andreas Schwab
  2022-07-15 15:10                 ` Gerd Möllmann
  1 sibling, 1 reply; 19+ messages in thread
From: Andreas Schwab @ 2022-07-15 14:46 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Po Lu, 56553, Eli Zaretskii

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





^ permalink raw reply related	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 14:46               ` Andreas Schwab
@ 2022-07-15 15:10                 ` Gerd Möllmann
  2022-07-15 15:16                   ` Gerd Möllmann
  2022-07-15 15:32                   ` Andreas Schwab
  0 siblings, 2 replies; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-15 15:10 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Po Lu, 56553, Eli Zaretskii



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






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 15:10                 ` Gerd Möllmann
@ 2022-07-15 15:16                   ` Gerd Möllmann
  2022-07-16  7:16                     ` Gerd Möllmann
  2022-07-15 15:32                   ` Andreas Schwab
  1 sibling, 1 reply; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-15 15:16 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Po Lu, 56553, Eli Zaretskii



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






^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 15:10                 ` Gerd Möllmann
  2022-07-15 15:16                   ` Gerd Möllmann
@ 2022-07-15 15:32                   ` Andreas Schwab
  1 sibling, 0 replies; 19+ messages in thread
From: Andreas Schwab @ 2022-07-15 15:32 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Po Lu, Eli Zaretskii, 56553-done

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





^ permalink raw reply	[flat|nested] 19+ messages in thread

* bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS
  2022-07-15 15:16                   ` Gerd Möllmann
@ 2022-07-16  7:16                     ` Gerd Möllmann
  0 siblings, 0 replies; 19+ messages in thread
From: Gerd Möllmann @ 2022-07-16  7:16 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: Po Lu, 56553, Eli Zaretskii


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.






^ permalink raw reply	[flat|nested] 19+ messages in thread

end of thread, other threads:[~2022-07-16  7:16 UTC | newest]

Thread overview: 19+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-07-14 13:03 bug#56553: 29.0.50; ASAN error with fringe bitmaps on NS Gerd Möllmann
2022-07-14 13:56 ` Eli Zaretskii
2022-07-14 14:18   ` Gerd Möllmann
2022-07-14 14:34     ` Gerd Möllmann
2022-07-14 16:55       ` Eli Zaretskii
2022-07-14 18:25         ` Gerd Möllmann
2022-07-15  8:23           ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-07-15  9:14             ` Gerd Möllmann
2022-07-15 10:37               ` Eli Zaretskii
2022-07-15 13:55                 ` Gerd Möllmann
2022-07-15 13:57                   ` Robert Pluim
2022-07-15 14:26                     ` Eli Zaretskii
2022-07-15 14:46               ` Andreas Schwab
2022-07-15 15:10                 ` Gerd Möllmann
2022-07-15 15:16                   ` Gerd Möllmann
2022-07-16  7:16                     ` Gerd Möllmann
2022-07-15 15:32                   ` Andreas Schwab
2022-07-15 10:35             ` Eli Zaretskii
2022-07-15 10:37               ` Gerd Möllmann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).