Assertion failes in w32uniscribe.c

Assertion failes in w32uniscribe.c

[Juanma Barranquero]

emacs -q
C-h H

=>

w32uniscribe.c:671: Emacs fatal error: assertion failed: CONSP((rest))

Breakpoint 1, w32_abort () at w32fns.c:9380
9380      button = MessageBox (NULL,
(gdb) backtrace
#0  w32_abort () at w32fns.c:9380
#1  0x0101f3bb in die (msg=0x143b2d8 "assertion failed:
CONSP((rest))", file=0x143aab0 "w32uniscribe.c", line=671)
    at alloc.c:6210
#2  0x01219b7c in uniscribe_check_otf (font=0x82d39c,
otf_spec=19767685) at w32uniscribe.c:671
#3  0x012136ef in add_font_entity_to_list@16 (logical_font=0x82d39c,
physical_font=0x82d1b4, font_type=4,
    lParam=8574288) at w32font.c:1243
#4  0x77f1b961 in GDI32!CreateFontA () from C:\WINDOWS\system32\gdi32.dll
#5  0x0082d39c in ?? ()
#6  0x0082d1b4 in ?? ()
#7  0x00000004 in ?? ()
#8  0x0082d550 in ?? ()
#9  0x00000001 in ?? ()
#10 0x0086efb8 in ?? ()
#11 0x00000000 in ?? ()

Lisp Backtrace:
"font-at" (0x82d8f4)
"auto-compose-chars" (0x82db20)


-- 
 Juanma

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> w32uniscribe.c:671: Emacs fatal error: assertion failed: CONSP((rest))
>   

I'll add code to avoid the assertion, but can you debug and see where 
this bogus font spec is coming from?

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Thu, Apr 3, 2008 at 5:06 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  I'll add code to avoid the assertion

In

+  /* Check the spec is in the right format.  */
+  if (!CONSP (otf_spec) || Flength (val) < 3)
+    return 0;
+

I suppose it's really Flength (otf_spec), isn't it?


> but can you debug and see where this
> bogus font spec is coming from?

Yes.


    Juanma

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> I suppose it's really Flength (otf_spec), isn't it?
>   

Fixed.

>> but can you debug and see where this
>> bogus font spec is coming from?
>>     
>
> Yes.
>   

To clarify what I mean, the following commands would give a lot of 
useful information:

(with old code, after the crash):
frame 2
pp otf_spec

(with new code):
break w32uniscribe.c:569
break w32uniscribe.c:618
run -q
pp otf_spec

    (gdb) backtrace
    #0  w32_abort () at w32fns.c:9380
    #1  0x0101f3bb in die (msg=0x143b2d8 "assertion failed:
    CONSP((rest))", file=0x143aab0 "w32uniscribe.c", line=671)
        at alloc.c:6210
    #2  0x01219b7c in uniscribe_check_otf (font=0x82d39c,
    otf_spec=19767685) at w32uniscribe.c:671
      

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:

>  (with old code, after the crash):
>  frame 2
>  pp otf_spec
>
>  (with new code):
>  break w32uniscribe.c:569
>  break w32uniscribe.c:618
>  run -q
>  pp otf_spec

Are you assuming that after adding this:

  /* Check the spec is in the right format.  */
  if (!CONSP (otf_spec) || Flength (otf_spec) < 3)
    return 0;

it does not crash? Because it still does.

   Juanma

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>>  (with old code, after the crash):
>>  frame 2
>>  pp otf_spec
>>
>>  (with new code):
>>  break w32uniscribe.c:569
>>  break w32uniscribe.c:618
>>  run -q
>>  pp otf_spec
>>     
>
> Are you assuming that after adding this:
>
>   /* Check the spec is in the right format.  */
>   if (!CONSP (otf_spec) || Flength (otf_spec) < 3)
>     return 0;
>
> it does not crash? Because it still does.
>   

I was assuming that the other part of the change would be what prevented 
this particular crash, since it was already getting past the point above:

      /* If features is not a cons, this font spec is messed up.  */
      if (!CONSP (features[i]))
        goto no_support;

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:

With new code:

--------------------------------------------------------------------------------
(gdb) break w32uniscribe.c:569
Breakpoint 3 at 0x1218e56: file w32uniscribe.c, line 569.
(gdb) break w32uniscribe.c:618
Breakpoint 4 at 0x1219166: file w32uniscribe.c, line 618.
(gdb) run -q
Starting program: C:\emacs\trunk\src/..\emacs.exe -q
[New thread 1560.0x720]
[New thread 1560.0x18c]

Breakpoint 3, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:572
572       script = XCAR (otf_spec);
(gdb) pp otf_spec
(gujr nil (rphf))
(gdb) continue
Continuing.

Breakpoint 4, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:621
621           OTF_INT16_VAL (tbl, 4, &scriptlist_table);
(gdb) pp otf_spec
0
(gdb) continue
Continuing.

w32uniscribe.c:679: Emacs fatal error: assertion failed: CONSP((rest))

Breakpoint 1, w32_abort () at w32fns.c:9380
9380      button = MessageBox (NULL,
(gdb) frame 2
#2  0x012198d2 in uniscribe_check_otf (font=0x82d39c,
otf_spec=19767413) at w32uniscribe.c:679
679           for (feature = XCAR (rest); CONSP (rest); feature = XCAR (rest))
(gdb) pp otf_spec
nil
(gdb)
--------------------------------------------------------------------------------

My Emacs is compiled with optimization, -DENABLE_CHECKING=1 and
-fno-crossjumping. I can do a non-optimized build, if necessary.

Perhaps irrelevant, but the crash is in Windows XP Pro, usp10.dll's
version is 1.601.5022.8, and gcc is "gcc (GCC) 4.2.1-sjlj
(mingw32-2)".

 Juanma

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
> With new code:
>   
You may need to compile without optimizations, to get the breakpoints on 
the actual goto statements instead of the following line.


> (gdb) break w32uniscribe.c:569
> Breakpoint 3, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
> at w32uniscribe.c:572
> 572       script = XCAR (otf_spec);
>   

> (gdb) pp otf_spec
> (gujr nil (rphf))
>   

That looks OK.

> Breakpoint 4, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
> at w32uniscribe.c:621
> 621           OTF_INT16_VAL (tbl, 4, &scriptlist_table);
> (gdb) pp otf_spec
>   
> 0
>   

That doesn't, but maybe optimizations are interfering, as otf_spec is 
not used later in the function, so it may have been optimized away already
What about "pp features[i]" and "print i"

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Fri, Apr 4, 2008 at 12:29 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  What about "pp features[i]" and "print i"

Breakpoint 3, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:572
572       script = XCAR (otf_spec);
(gdb) pp features[i]
0
(gdb) print i
$1 = 19767413
(gdb) continue
Continuing.

Breakpoint 4, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:621
621           OTF_INT16_VAL (tbl, 4, &scriptlist_table);
(gdb) pp features[i]
(rphf)
(gdb) print i
$2 = 0
(gdb) continue
Continuing.

w32uniscribe.c:679: Emacs fatal error: assertion failed: CONSP((rest))

Breakpoint 1, w32_abort () at w32fns.c:9380
9380      button = MessageBox (NULL,
(gdb) frame 2
#2  0x012198d2 in uniscribe_check_otf (font=0x82d39c,
otf_spec=19767413) at w32uniscribe.c:679
679           for (feature = XCAR (rest); CONSP (rest); feature = XCAR (rest))
(gdb) pp features[i]
Cannot access memory at address 0x6c27118
(gdb) print i
$3 = 26208257
(gdb)

 Juanma

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

Additional info: the assertion triggers when displaying bengali,
gujarati, hindi, kannada, khmer, lao, malayalam, oriya, sinhala,
tamil, tegulu or tibetan.

Note that the usp10.dll I have, 1.601.5022.8, comes from the "Sinhala
Enabling Pack for XP 0.42" (see
http://en.wikipedia.org/wiki/Uniscribe).

 Juanma

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

OK, it is working now. Thanks.

It is still slow, though. From  "emacs -Q -f view-hello-file" to
actually see etc/HELLO, about 8-10 seconds, or three times slower than
the same operation using --disable-font-backend.

 Juanma

Re: Assertion failes in w32uniscribe.c

[Lennart Borgman (gmail)]

Juanma Barranquero wrote:
> OK, it is working now. Thanks.
> 
> It is still slow, though. From  "emacs -Q -f view-hello-file" to
> actually see etc/HELLO, about 8-10 seconds, or three times slower than
> the same operation using --disable-font-backend.

I am still using --disable-font-backend because without it there has 
been some very annoying screen blinking. Has anyone else seen this?

Another strange things I have seen the last days is that sometimes the 
welcome screen is shown without any colors and without the image. Next 
time I try it works as it should. Does not that look like a missing 
initialization somewhere?

But please notice that this is with my slightly patched version (v 23, 
2008-04-03).

Re: Assertion failes in w32uniscribe.c

[Claus]

>  I am still using --disable-font-backend because without it there has been
> some very annoying screen blinking. Has anyone else seen this?

Confirmed. Lot's of blinking, especially when the screen is split (C-x
2). It looks like for each keystroke both buffers are completely
redisplayed (or parsed... or re-fontified... hard to tell the
difference).

Whatever it is, it causes lag / slowdown during typing.

Thus, I see myself using C-x 1 all the time to enhance performance a bit.

GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6000) of 2008-03-23 on WindowsVista

Claus


On Fri, Apr 4, 2008 at 7:02 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:
>
> Juanma Barranquero wrote:
>
> > OK, it is working now. Thanks.
> >
> > It is still slow, though. From  "emacs -Q -f view-hello-file" to
> > actually see etc/HELLO, about 8-10 seconds, or three times slower than
> > the same operation using --disable-font-backend.
> >
>
>  I am still using --disable-font-backend because without it there has been
> some very annoying screen blinking. Has anyone else seen this?
>
>  Another strange things I have seen the last days is that sometimes the
> welcome screen is shown without any colors and without the image. Next time
> I try it works as it should. Does not that look like a missing
> initialization somewhere?
>
>  But please notice that this is with my slightly patched version (v 23,
> 2008-04-03).
>
>
>



--

Mit freundlichem Gruß,
Claus Klingberg

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Claus wrote:
> Confirmed. Lot's of blinking, especially when the screen is split (C-x
> 2). It looks like for each keystroke both buffers are completely
> redisplayed (or parsed... or re-fontified... hard to tell the
> difference).
>
> GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6000) of 2008-03-23 on WindowsVista
>
> On Fri, Apr 4, 2008 at 7:02 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
>   
>>     
>>  But please notice that this is with my slightly patched version (v 23,
>> 2008-04-03).
>>     

Can you both please try the latest version. I fixed a bug yesterday with 
the text extents, which could explain the described behaviour.
It does not seem to flicker for me now, though admittedly I have seen it 
in the past.

Re: Assertion failes in w32uniscribe.c

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Claus wrote:
>> Confirmed. Lot's of blinking, especially when the screen is split (C-x
>> 2). It looks like for each keystroke both buffers are completely
>> redisplayed (or parsed... or re-fontified... hard to tell the
>> difference).
>>
>> GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6000) of 2008-03-23 on WindowsVista
>>
>> On Fri, Apr 4, 2008 at 7:02 PM, Lennart Borgman (gmail)
>> <lennart.borgman@gmail.com> wrote:
>>  
>>>      But please notice that this is with my slightly patched version 
>>> (v 23,
>>> 2008-04-03).
>>>     
> 
> Can you both please try the latest version. I fixed a bug yesterday with 
> the text extents, which could explain the described behaviour.
> It does not seem to flicker for me now, though admittedly I have seen it 
> in the past.

I just did a quick test and I see no flickering now. That is very good, 
thanks.

However moving with up/down arrows is still very slow. If I hold down 
the up or down arrow the point cursor jumps. (When I use 
--disable-font-backend it moves more smoothly.)

Re: Assertion failes in w32uniscribe.c

[Óscar Fuentes]

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> I am still using --disable-font-backend because without it there has
> been some very annoying screen blinking. Has anyone else seen this?

With the new font backend, redisplay is so slow that Emacs is unusable
on an AMD Athlon 550 MHz (Windows2kSP4), and takes a good share of CPU
on a 2 GHz Pentium M (XPSP2).

The effect is more serious on certain applications (Gnus, ERC) although
it is bad enough while editing or viewing C/C++/Elisp source files.

For now, I'll use --disable-font-backend.

[snip]

-- 
Oscar

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> It is still slow, though. From  "emacs -Q -f view-hello-file" to
> actually see etc/HELLO, about 8-10 seconds, or three times slower than
> the same operation using --disable-font-backend.
>   

I see a 5 second vs 3 second delay, but it'll depend on how many and 
which fonts you have installed. I don't think a performance hit can be 
avoided, as font enumeration is slow on Windows anyway, and we are 
searching for fonts in far more detail than before, especially for 
complex South and South East Asian scripts. Once a font is found, it is 
cached, so the slowdown only occurs the first time you encounter a 
character that needs an as yet unknown font.

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Sun, Apr 6, 2008 at 3:14 AM, Jason Rumney <jasonr@gnu.org> wrote:

> I don't think a performance hit can be avoided, as
> font enumeration is slow on Windows anyway, and we are searching for fonts
> in far more detail than before, especially for complex South and South East
> Asian scripts.

Fair enough.

But some operations are still too slow to be useful. Scrolling
etc/NEWS (with presumably contains not many non-ASCII chars) with the
new backend is unbearable, for example.

 Juanma

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> But some operations are still too slow to be useful. Scrolling
> etc/NEWS (with presumably contains not many non-ASCII chars) with the
> new backend is unbearable, for example.
>   

C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I 
think you'll need to debug why it is taking so long on your machine.

Re: Assertion failes in w32uniscribe.c

[Óscar Fuentes]

Jason Rumney <jasonr@gnu.org> writes:

> Juanma Barranquero wrote:
>> But some operations are still too slow to be useful. Scrolling
>> etc/NEWS (with presumably contains not many non-ASCII chars) with the
>> new backend is unbearable, for example.
>>   
>
> C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I
> think you'll need to debug why it is taking so long on your machine.

What machine are you using? On a 550 MHz Athlon it is very slow: you can
see how the screen is repainted, the CPU usage goes to 100% and, if you
keep C-v pressed, no redraw is performed until the the end of the buffer
is reached. When I keep C-v pressed on the same Emacs started with
--disable-font-backend, CPU activity is below 15%.

On a 2 GHz Pentium M, Emacs uses more than 50% CPU load while scrolling
etc/NEWS.

-- 
Oscar

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Sun, Apr 6, 2008 at 3:42 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I think
> you'll need to debug why it is taking so long on your machine.

I'm not talking about C-v. I'm talking about scrolling one line at a time.

I use this in my .emacs

(setq scroll-preserve-screen-position 'always
      scroll-conservatively most-positive-fixnum
      scroll-step 0)

because I *hate* recentering during scroll.

If you try the above setup with and without the new backend, you'll
see the difference, I think.

   Juanma

Re: Assertion failes in w32uniscribe.c

[Jason Rumney]

Juanma Barranquero wrote:
> On Sun, Apr 6, 2008 at 3:42 PM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>>  C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I think
>> you'll need to debug why it is taking so long on your machine.
>>     
>
> I'm not talking about C-v. I'm talking about scrolling one line at a time.
>
> I use this in my .emacs
>
> (setq scroll-preserve-screen-position 'always
>       scroll-conservatively most-positive-fixnum
>       scroll-step 0)
>
> because I *hate* recentering during scroll.
>
> If you try the above setup with and without the new backend, you'll
> see the difference, I think.
>   

I don't see a significant difference, certainly nothing to justify 
language like "unusable" and "unbearable" that has been used on this 
thread. Both recenter occasionally when the redisplay cannot keep up 
with key repeat, with the new font  backend it may happen more 
frequently, but that is not surprising for new development code that has 
not yet settled down, so noone has tried to optimize it yet.

Re: Assertion failes in w32uniscribe.c

[Juanma Barranquero]

On Mon, Apr 7, 2008 at 1:03 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  I don't see a significant difference

Well, THAT is surprising. They are not comparable at all for me. In my
setup, with the variable settings I reported, the old backend keeps up
with key repeat and I can scroll one line at a time as long as I want
(that's so in two different computers, with different XP versions,
different CPUs, etc.); and the redisplay during the scroll is smooth.
The new backend either scrolls visibly slow or, often, it just
recenters.

> certainly nothing to justify language like "unusable" and "unbearable" that has been used on this thread.

For my use and scrolling habits, the new backend is unusable and
unbearable. That's a fact: I wouldn't be able to use the CVS Emacs
right now, were not for --disable-font-backend. But that is not a
complain, I'm *reporting* one case of quite noticeable slowness in one
particular use case (scrolling one line at a time) that is perhaps
less usual that the "use C-v/M-v a lot and let next-line/previous-line
ocassionally recenter" behavior that many people prefers.

That said, if you take offense to my choice of words, I apologize and
will try to be more careful from now on. I wasn't trying to slight the
work you've done with the new backend, which is great.

 Juanma