assertion failed: c == event->code

assertion failed: c == event->code

[Juanma Barranquero]

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

I'm getting a failed assertion:

keyboard.c:5548: Emacs fatal error: assertion failed: c == event->code

Breakpoint 1, w32_abort () at w32fns.c:9127
9127      button = MessageBox (NULL,
(gdb) bt
#0  w32_abort () at w32fns.c:9127
#1  0x0101f2fb in die (msg=0x13598f8 "assertion failed: c == event->code",
    file=0x135686a "keyboard.c", line=5548) at alloc.c:6287
#2  0x01091bfc in read_char (commandflag=1, nmaps=2, maps=0x82fb70,
    prev_event=25171969, used_mouse_menu=0x82fc18, end_time=0x0)
    at keyboard.c:5548
#3  0x010928d1 in read_key_sequence (keybuf=0x82fce4, bufsize=30,
    prompt=25171969, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9459
#4  0x010952e1 in command_loop_1 () at keyboard.c:1666
#5  0x0101b0b7 in internal_condition_case (bfun=0x1095082 <command_loop_1>,
    handlers=25244841, hfun=0x108cba3 <cmd_error>) at eval.c:1493
#6  0x0108bdd0 in command_loop_2 () at keyboard.c:1381
#7  0x0101b152 in internal_catch (tag=25236817,
    func=0x108bdad <command_loop_2>, arg=25171969) at eval.c:1229
#8  0x0108c9dc in command_loop () at keyboard.c:1360
#9  0x0108cd06 in recursive_edit_1 () at keyboard.c:969
#10 0x0108ce71 in Frecursive_edit () at keyboard.c:1031
#11 0x01002b0c in main (argc=8585136, argv=0xa92778) at emacs.c:1781

That's on Windows XP, with an up-to-date trunk build, built with "gcc
(GCC) 4.2.1-sjlj (mingw32-2)".

The error happens (repeatably) whenever I press Ctrl + a non-ASCII key
(for example, C-Ñ, C-ç, C-º).

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Stefan Monnier]

> I'm getting a failed assertion:

> keyboard.c:5548: Emacs fatal error: assertion failed: c == event->code

> Breakpoint 1, w32_abort () at w32fns.c:9127
> 9127      button = MessageBox (NULL,
> (gdb) bt
> #0  w32_abort () at w32fns.c:9127
> #1  0x0101f2fb in die (msg=0x13598f8 "assertion failed: c == event->code",
>     file=0x135686a "keyboard.c", line=5548) at alloc.c:6287
> #2  0x01091bfc in read_char (commandflag=1, nmaps=2, maps=0x82fb70,
>     prev_event=25171969, used_mouse_menu=0x82fc18, end_time=0x0)
>     at keyboard.c:5548
> #3  0x010928d1 in read_key_sequence (keybuf=0x82fce4, bufsize=30,
>     prompt=25171969, dont_downcase_last=0, can_return_switch_frame=1,
>     fix_current_buffer=1) at keyboard.c:9459
> #4  0x010952e1 in command_loop_1 () at keyboard.c:1666
> #5  0x0101b0b7 in internal_condition_case (bfun=0x1095082 <command_loop_1>,
>     handlers=25244841, hfun=0x108cba3 <cmd_error>) at eval.c:1493
> #6  0x0108bdd0 in command_loop_2 () at keyboard.c:1381
> #7  0x0101b152 in internal_catch (tag=25236817,
>     func=0x108bdad <command_loop_2>, arg=25171969) at eval.c:1229
> #8  0x0108c9dc in command_loop () at keyboard.c:1360
> #9  0x0108cd06 in recursive_edit_1 () at keyboard.c:969
> #10 0x0108ce71 in Frecursive_edit () at keyboard.c:1031
> #11 0x01002b0c in main (argc=8585136, argv=0xa92778) at emacs.c:1781

> That's on Windows XP, with an up-to-date trunk build, built with "gcc
> (GCC) 4.2.1-sjlj (mingw32-2)".

> The error happens (repeatably) whenever I press Ctrl + a non-ASCII key
> (for example, C-Ñ, C-ç, C-º).

Hmm.. if you just remove this eassert, you should get back the previous
behavior.  But then I wonder: is this previous behavior correct, and if
so, why?

Basically, the issue is that when a key is pressed, the W32 code inserts
a "ASCII_KEYSTROKE_EVENT" in the queue, even for non-ASCII chars, and
then keyboard.c applies a "& 0377" to it, so there's a risk of losing
some bits and turning a non-ASCII keypress into some ASCII char.

This "& 0377" was introduced by:

   revision 1.135
   date: 1993-08-11 07:56:40 +0000;  author: rms;  state: Exp;  lines: +1 -1;
   (make_lispy_event): Clear all but 0377 in event->code.
   ----------------------------

so I have no idea why it's there.


        Stefan

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

On Dec 12, 2007 6:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Hmm.. if you just remove this eassert, you should get back the previous
> behavior.  But then I wonder: is this previous behavior correct, and if
> so, why?

No idea.

> Basically, the issue is that when a key is pressed, the W32 code inserts
> a "ASCII_KEYSTROKE_EVENT" in the queue, even for non-ASCII chars, and
> then keyboard.c applies a "& 0377" to it, so there's a risk of losing
> some bits and turning a non-ASCII keypress into some ASCII char.

Without the eassert, C-ñ returns ' (U+2018, translated from \221), C-ç
returns ‡ (U+2021, translated from \207). Not sure whether that is
intended or not.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Stefan Monnier]

>> Basically, the issue is that when a key is pressed, the W32 code inserts
>> a "ASCII_KEYSTROKE_EVENT" in the queue, even for non-ASCII chars, and
>> then keyboard.c applies a "& 0377" to it, so there's a risk of losing
>> some bits and turning a non-ASCII keypress into some ASCII char.

> Without the eassert, C-ñ returns ' (U+2018, translated from \221), C-ç
> returns ‡ (U+2021, translated from \207). Not sure whether that is
> intended or not.

Well, what does it look like to you?  To me it looks like a plain bug.
Can you try the patch below?


        Stefan


--- w32term.c.~1.276.~	2007-11-09 10:15:55.000000000 -0500
+++ w32term.c	2007-12-12 14:43:54.000000000 -0500
@@ -4329,7 +4329,9 @@
 	      if (temp_index == sizeof temp_buffer / sizeof (short))
 		temp_index = 0;
 	      temp_buffer[temp_index++] = msg.msg.wParam;
-	      inev.kind = ASCII_KEYSTROKE_EVENT;
+	      inev.kind = (msg.msg.wParam < 0xff
+			   ? ASCII_KEYSTROKE_EVENT
+			   : MULTIBYTE_CHAR_KEYSTROKE_EVENT);
 	      inev.code = msg.msg.wParam;
 	      inev.modifiers = msg.dwModifiers;
 	      XSETFRAME (inev.frame_or_window, f);

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

On Dec 12, 2007 9:05 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Well, what does it look like to you?

As a bug, I suppose, but Emacs' low-level keyboard handling is not the
easiest thing to understand...

> Can you try the patch below?

C-h k C-º    => Invalid char code -70 is undefined
C-h k C-ñ    => Invalid char code -15 is undefined
C-h k C-ç    => Invalid char code -25 is undefined.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Jason Rumney]

Stefan Monnier wrote:
> --- w32term.c.~1.276.~	2007-11-09 10:15:55.000000000 -0500
> +++ w32term.c	2007-12-12 14:43:54.000000000 -0500
> @@ -4329,7 +4329,9 @@
>  	      if (temp_index == sizeof temp_buffer / sizeof (short))
>  		temp_index = 0;
>  	      temp_buffer[temp_index++] = msg.msg.wParam;
> -	      inev.kind = ASCII_KEYSTROKE_EVENT;
> +	      inev.kind = (msg.msg.wParam < 0xff
> +			   ? ASCII_KEYSTROKE_EVENT
> +			   : MULTIBYTE_CHAR_KEYSTROKE_EVENT);
>  	      inev.code = msg.msg.wParam;
>  	      inev.modifiers = msg.dwModifiers;
>  	      XSETFRAME (inev.frame_or_window, f);
>   

Is it really that simple? Doesn't the multibyte character need to be
encoded to emacs-mule first?

Re: assertion failed: c == event->code

[Jason Rumney]

Juanma Barranquero wrote:
> On Dec 12, 2007 6:30 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>
>   
>> Hmm.. if you just remove this eassert, you should get back the previous
>> behavior.  But then I wonder: is this previous behavior correct, and if
>> so, why?
>>     
>
> No idea.
>
>   
>> Basically, the issue is that when a key is pressed, the W32 code inserts
>> a "ASCII_KEYSTROKE_EVENT" in the queue, even for non-ASCII chars, and
>> then keyboard.c applies a "& 0377" to it, so there's a risk of losing
>> some bits and turning a non-ASCII keypress into some ASCII char.
>>     
>
> Without the eassert, C-ñ returns ' (U+2018, translated from \221), C-ç
> returns ‡ (U+2021, translated from \207). Not sure whether that is
> intended or not.
>   
What is your locale set to, and keyboard-coding-system?
Also, does this happen with emacs -Q?

Since Windows effectively blocks Cntl and AltGr being used together, the
only sequences I can type are C-£ and C-¬, both of which work correctly
with a UK English Windows locale, and keyboard-coding-system set to cp1252.

Looking at the actual code for ASCII_KEYSTROKE_EVENT, it really means
UNIBYTE_CHAR_KEYSTROKE_EVENT, as the mask is against \0377 (0xff), and a
test in xterm.c tests for SINGLE_BYTE_CHAR_P.

Other naming in that enum is not clear, as NONASCII_KEYSTROKE_EVENT
actually means FUNCTION_KEYSTROKE_EVENT, or NON_CHAR_KEYSTROKE_EVENT.

MULTIBYTE_CHAR_KEYSTROKE_EVENT seems clearer, but it is not clear from
the comments, nor the code in xterm.c, whether it should be an
emacs-mule encoded character, or a double byte character in the keyboard
coding system, as the code in xterm.c seems to generate both.

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

On Dec 13, 2007 3:16 PM, Jason Rumney <jasonr@gnu.org> wrote:

> What is your locale set to

This is a Windows XP with Spanish (Spain) locale and the Spanish
(International Sorting) keyboard.

> and keyboard-coding-system?

cp1252

> Also, does this happen with emacs -Q?

Of course, I was reporting the behavior with -Q.

> Since Windows effectively blocks Cntl and AltGr being used together, the
> only sequences I can type are C-£ and C-¬, both of which work correctly
> with a UK English Windows locale, and keyboard-coding-system set to cp1252.

I can type C-º, C-ª, C-¿, C-¡, C-ñ, C-Ñ, C-ç, C-Ç.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Jason Rumney]

Juanma Barranquero wrote:
> I can type C-º, C-ª, C-¿, C-¡, C-ñ, C-Ñ, C-ç, C-Ç.
>   
OK, I see the code in keyboard.c tries to handle ISO controls (with the
top bit set). Since the keyboard coding system is cp1252, the ISO
control codes get translated into the characters you are seeing. This
doesn't explain why the eassert is triggering though, as the original
characters are within the expected range (0-0xff).

Re: assertion failed: c == event->code

[Juanma Barranquero]

On Dec 13, 2007 5:37 PM, Jason Rumney <jasonr@gnu.org> wrote:

> This
> doesn't explain why the eassert is triggering though, as the original
> characters are within the expected range (0-0xff).

I can try to debug it, if you explain to me what to look for and where.

             Juanma

Re: assertion failed: c == event->code

[Jason Rumney]

Juanma Barranquero wrote:
> On Dec 13, 2007 5:37 PM, Jason Rumney <jasonr@gnu.org> wrote:
>   
> I can try to debug it, if you explain to me what to look for and where.
>   

If you reproduce the bug, you get this backtrace:

    keyboard.c:5548: Emacs fatal error: assertion failed: c == event->code

    Breakpoint 1, w32_abort () at w32fns.c:9127
    9127      button = MessageBox (NULL,
    (gdb) bt
    #0  w32_abort () at w32fns.c:9127
    #1  0x0101f2fb in die (msg=0x13598f8 "assertion failed: c == event->code",
        file=0x135686a "keyboard.c", line=5548) at alloc.c:6287
    #2  0x01091bfc in read_char (commandflag=1, nmaps=2, maps=0x82fb70,
        prev_event=25171969, used_mouse_menu=0x82fc18, end_time=0x0)
        at keyboard.c:5548
    #3  0x010928d1 in read_key_sequence (keybuf=0x82fce4, bufsize=30,
        prompt=25171969, dont_downcase_last=0, can_return_switch_frame=1,
        fix_current_buffer=1) at keyboard.c:9459
      

"frame 2" takes you to the point in keyboard.c where the assertion was triggered.
"print c", "print event->code" will print the values of the respective variables.

From there, you can go further up the stack and print other related variables to see where event->code became greater than 0xff.

Re: assertion failed: c == event->code

[Juanma Barranquero]

On Dec 14, 2007 10:24 AM, Jason Rumney <jasonr@gnu.org> wrote:

> From there, you can go further up the stack and print other related variables to see where event->code became greater than 0xff.

OK, I'll try to debug it over the weekend.

             Juanma

Re: assertion failed: c == event->code

[Kenichi Handa]

In article <47613EC3.7020004@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> MULTIBYTE_CHAR_KEYSTROKE_EVENT seems clearer, but it is not clear from
> the comments, nor the code in xterm.c, whether it should be an
> emacs-mule encoded character, or a double byte character in the keyboard
> coding system, as the code in xterm.c seems to generate both.

MULTIBYTE_CHAR_KEYSTROKE_EVENT should be for an Emacs's
internal character code (i.e. emacs-mule encoded character
in the trunk).  Where in xterm.c, "a double byte character
in the keyboard coding system" is generated?

---
Kenichi Handa
handa@ni.aist.go.jp

Re: assertion failed: c == event->code

[Jason Rumney]

Kenichi Handa wrote:
> MULTIBYTE_CHAR_KEYSTROKE_EVENT should be for an Emacs's
> internal character code (i.e. emacs-mule encoded character
> in the trunk).  Where in xterm.c, "a double byte character
> in the keyboard coding system" is generated?
>   

Around line 6417, we have:

           inev.ie.kind = (SINGLE_BYTE_CHAR_P (XFASTINT (c))
                              ? ASCII_KEYSTROKE_EVENT
                              : MULTIBYTE_CHAR_KEYSTROKE_EVENT);

But I see c at that point is the result of a lookup in x-keysym-table,
so it might be OK.

Re: assertion failed: c == event->code

[Kenichi Handa]

In article <47624334.109@gnu.org>, Jason Rumney <jasonr@gnu.org> writes:

> Kenichi Handa wrote:
> > MULTIBYTE_CHAR_KEYSTROKE_EVENT should be for an Emacs's
> > internal character code (i.e. emacs-mule encoded character
> > in the trunk).  Where in xterm.c, "a double byte character
> > in the keyboard coding system" is generated?
> >   

> Around line 6417, we have:

>            inev.ie.kind = (SINGLE_BYTE_CHAR_P (XFASTINT (c))
>                               ? ASCII_KEYSTROKE_EVENT
>                               : MULTIBYTE_CHAR_KEYSTROKE_EVENT);

> But I see c at that point is the result of a lookup in x-keysym-table,
> so it might be OK.

Yes.

---
Kenichi Handa
handa@ni.aist.go.jp

Re: assertion failed: c == event->code

[Jason Rumney]

Now that everything is clear, I've implemented
MULTIBYTE_CHAR_KEYSTROKE_EVENT input for Windows. But the original test
cases (C-ñ, C-ç) now cannot be input at all, Emacs just ignores them. Is
this the case on other platforms too?

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

On Dec 14, 2007 1:23 PM, Jason Rumney <jasonr@gnu.org> wrote:

> But the original test
> cases (C-ñ, C-ç) now cannot be input at all, Emacs just ignores them.

That's not good. The behavior before Stefan's eassert patch was
perhaps wrong, but it was more useful.

I've had C-ñ mapped to insert `~' for a long time. It is much easier
than the "right" way, AltGr + 4 + other key.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

Unless someone opposes, I'm gonna install this change.

This is the best of both worlds: the C-ñ, C-ç, etc. keystrokes do not
trigger the assertion, and they are not ignored by Emacs.

             Juanma


Index: src/w32term.c
===================================================================
RCS file: /cvsroot/emacs/emacs/src/w32term.c,v
retrieving revision 1.277
diff -u -2 -r1.277 w32term.c
--- src/w32term.c	16 Dec 2007 04:31:47 -0000	1.277
+++ src/w32term.c	16 Dec 2007 14:51:58 -0000
@@ -4338,5 +4338,5 @@
                   inev.code = msg.msg.wParam;
                 }
-              else if (msg.msg.wParam < 256)
+              else
                 {
                   wchar_t code;
@@ -4414,12 +4414,4 @@
                     }
                 }
-              else
-                {
-                  /* Windows shouldn't generate WM_CHAR events above 0xFF
-                     in non-Unicode message handlers.  */
-                  DebPrint (("Non-byte WM_CHAR: %d\n", msg.msg.wParam));
-                  inev.kind = NO_EVENT;
-                  break;
-                }
 	      inev.modifiers = msg.dwModifiers;
 	      XSETFRAME (inev.frame_or_window, f);

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Jason Rumney]

Juanma Barranquero wrote:
> Unless someone opposes, I'm gonna install this change.
>   
> This is the best of both worlds: the C-ñ, C-ç, etc. keystrokes do not
> trigger the assertion, and they are not ignored by Emacs.
>   
Does it give correct results? The reason I left keys > 0xff out is that
the code to handle non-ASCII keys does not properly handle such values.
If there is a ctrl bit to filter out, then lets filter it out.

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

On Dec 16, 2007 9:49 PM, Jason Rumney <jasonr@gnu.org> wrote:

> Does it give correct results?

How do you define "correct results"? Your patch + the change I propose
solve an old bug I reported (the discussion is at
http://thread.gmane.org/gmane.emacs.devel/67080) were

  (global-set-key (kbd "C-M-º") 'my-command)

produced a keybinding that `describe-key' didn't recognize. Or, put it
differently, before:

  (event-basic-type (aref (kbd "C-M-º") 0))  => 2234
  (event-basic-type (event-basic-type (aref (read-key-sequence "Type
C-M-º: ") 0))  => 186

Now both return 2234.

> If there is a ctrl bit to filter out, then lets filter it out.

Sorry, I don't understand what you mean.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Juanma Barranquero]

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

On Dec 16, 2007 9:53 PM, Juanma Barranquero <lekktu@gmail.com> wrote:

> (event-basic-type (event-basic-type (aref (read-key-sequence "Type
> C-M-º: ") 0))  => 186

  (event-basic-type (aref (read-key-sequence "Type C-M-º: ") 0)) => 186

I mean.

             Juanma

[-- Attachment #2: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: assertion failed: c == event->code

[Miles Bader]

"Juanma Barranquero" <lekktu@gmail.com> writes:
>> Does it give correct results?
...
> produced a keybinding that `describe-key' didn't recognize. Or, put it
> differently, before:
>
>   (event-basic-type (aref (kbd "C-M-º") 0))  => 2234
>   (event-basic-type (event-basic-type (aref (read-key-sequence "Type
> C-M-º: ") 0))  => 186
>
> Now both return 2234.

In case anybody else is confused[*], 2234 is the emacs-mule internal
codepoint, 186 is the latin-1 (and unicode) codepoint.

[*] I was, though part of that is because "º" displays on my display
    as "U" for some reason, font problems or something...

-Miles

-- 
People who are more than casually interested in computers should have at
least some idea of what the underlying hardware is like.  Otherwise the
programs they write will be pretty weird.  -- Donald Knuth

Re: assertion failed: c == event->code

[Jason Rumney]

Jason Rumney wrote:
> Juanma Barranquero wrote:
>   
>> Unless someone opposes, I'm gonna install this change.
>>   
>> This is the best of both worlds: the C-ñ, C-ç, etc. keystrokes do not
>> trigger the assertion, and they are not ignored by Emacs.
>>   
>>     
> Does it give correct results? The reason I left keys > 0xff out is that
> the code to handle non-ASCII keys does not properly handle such values.
> If there is a ctrl bit to filter out, then lets filter it out.
>   
The problem was caused by a signed/unsigned mismatch where the WM_CHAR
message was created in w32fns.c. I've fixed it now, no need to check in
your change.

Re: assertion failed: c == event->code

[Juanma Barranquero]

On Dec 17, 2007 2:52 AM, Jason Rumney <jasonr@gnu.org> wrote:

> The problem was caused by a signed/unsigned mismatch where the WM_CHAR
> message was created in w32fns.c. I've fixed it now, no need to check in
> your change.

That's even better. Thanks.

             Juanma

Re: assertion failed: c == event->code

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Basically, the issue is that when a key is pressed, the W32 code inserts
> a "ASCII_KEYSTROKE_EVENT" in the queue, even for non-ASCII chars,

That looks like a bug.  Shouldn't it use MULTIBYTE_CHAR_KEYSTROKE_EVENT
for non-ASCII input?  Both xterm.c and macterm.c get that right, as it
seems.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: assertion failed: c == event->code

[martin rudalics]

 > I'm getting a failed assertion:
 >
 > keyboard.c:5548: Emacs fatal error: assertion failed: c == event->code
 >
 > Breakpoint 1, w32_abort () at w32fns.c:9127
 > 9127      button = MessageBox (NULL,
 > (gdb) bt
 > #0  w32_abort () at w32fns.c:9127
...
 > That's on Windows XP, with an up-to-date trunk build, built with "gcc
 > (GCC) 4.2.1-sjlj (mingw32-2)".
 >
 > The error happens (repeatably) whenever I press Ctrl + a non-ASCII key
 > (for example, C-Ñ, C-ç, C-º).

I can't resist adding my personal favorite in this department here:

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread -335645.0xfffad9b7]
w32_wnd_proc (hwnd=0x69c, msg=256, wParam=4287102993, lParam=1075642369) at w32fns.c:3082
(gdb) backtrace
#0  w32_wnd_proc (hwnd=0x69c, msg=256, wParam=4287102993, lParam=1075642369) at w32fns.c:3082
#1  0xbff63613 in _libwinspool_a_iname ()
#2  0xbff848f7 in _libwinspool_a_iname ()
#3  0x21028d7a in ?? ()
#4  0x00058f64 in ?? ()
#5  0x280a0d0a in ?? ()

where the offending line in w32fns.c is

	  if (lispy_function_keys[wParam] == 0)

Repeatable on WindowsME ever since by scrolling the mouse-wheel with the
control or meta key pressed down.

Note: The bug occurs iff "enhanced scroll-mode" is turned on, that is
C-h k for spinning the mouse-wheel gives

<vertical-scroll-bar> <mouse-1> (translated from <mouse-1>) at that spot runs the command scroll-bar-toolkit-scroll

Maybe the person handling Juanma's problem could have a kind look at
this one too ;-)