might a bug in ido-mode

might a bug in ido-mode

[zwz]

I found a problem that crashes emacs.
The problem seems a little random, but I produced it twice by:

1. start the emacs: emacs -q
2. eval the elisp code below in the scratch buffer:

(setq ido-save-directory-list-file "~/.emacs.d/.ido.last"
      ido-create-new-buffer 'always
      ido-enable-flex-matching t
      ido-enable-tramp-completion t)
(ido-mode t)

3. C-x C-f, and input a file name like "main.c".
   Wait a second, while the the ido-mode is looking for "main.c", hit
   the keys C-j (if no problem, then a buffer "main.c" is created)
4. do 3 again, with the same file name in the same directory.
   When you hit C-j during the ido-mode's searching, emacs crashes!
   (maybe you have to try more times to get the problem)

By the way, I am using GNU Emacs 24.0.50.1 (i386-mingw-nt6.0.6002) of
2010-04-24 On Window Vista

Re: might a bug in ido-mode

[Eli Zaretskii]

> From: zwz <zhangweize@gmail.com>
> Date: Sun, 25 Apr 2010 20:57:42 +0800
> 
> I found a problem that crashes emacs.
> The problem seems a little random, but I produced it twice by:
> 
> 1. start the emacs: emacs -q
> 2. eval the elisp code below in the scratch buffer:
> 
> (setq ido-save-directory-list-file "~/.emacs.d/.ido.last"
>       ido-create-new-buffer 'always
>       ido-enable-flex-matching t
>       ido-enable-tramp-completion t)
> (ido-mode t)
> 
> 3. C-x C-f, and input a file name like "main.c".
>    Wait a second, while the the ido-mode is looking for "main.c", hit
>    the keys C-j (if no problem, then a buffer "main.c" is created)
> 4. do 3 again, with the same file name in the same directory.
>    When you hit C-j during the ido-mode's searching, emacs crashes!
>    (maybe you have to try more times to get the problem)

FWIW, I cannot reproduce this on my machine.

Can you run Emacs under GDB and when it crashes, show the backtrace?

Re: might a bug in ido-mode

[Chong Yidong]

zwz <zhangweize@gmail.com> writes:

> I found a problem that crashes emacs.
> The problem seems a little random, but I produced it twice by:
>
> 1. start the emacs: emacs -q
> 2. eval the elisp code below in the scratch buffer:
>
> (setq ido-save-directory-list-file "~/.emacs.d/.ido.last"
>       ido-create-new-buffer 'always
>       ido-enable-flex-matching t
>       ido-enable-tramp-completion t)
> (ido-mode t)
>
> 3. C-x C-f, and input a file name like "main.c".
>    Wait a second, while the the ido-mode is looking for "main.c", hit
>    the keys C-j (if no problem, then a buffer "main.c" is created)
> 4. do 3 again, with the same file name in the same directory.
>    When you hit C-j during the ido-mode's searching, emacs crashes!
>    (maybe you have to try more times to get the problem)
>
> By the way, I am using GNU Emacs 24.0.50.1 (i386-mingw-nt6.0.6002) of
> 2010-04-24 On Window Vista

Could you provide a backtrace?

Re: might a bug in ido-mode

[zwz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: zwz <zhangweize@gmail.com>
>> Date: Sun, 25 Apr 2010 20:57:42 +0800
>> 
>> I found a problem that crashes emacs.
>> The problem seems a little random, but I produced it twice by:
>> 
>> 1. start the emacs: emacs -q
>> 2. eval the elisp code below in the scratch buffer:
>> 
>> (setq ido-save-directory-list-file "~/.emacs.d/.ido.last"
>>       ido-create-new-buffer 'always
>>       ido-enable-flex-matching t
>>       ido-enable-tramp-completion t)
>> (ido-mode t)
>> 
>> 3. C-x C-f, and input a file name like "main.c".
>>    Wait a second, while the the ido-mode is looking for "main.c", hit
>>    the keys C-j (if no problem, then a buffer "main.c" is created)
>> 4. do 3 again, with the same file name in the same directory.
>>    When you hit C-j during the ido-mode's searching, emacs crashes!
>>    (maybe you have to try more times to get the problem)
>
> FWIW, I cannot reproduce this on my machine.
>
> Can you run Emacs under GDB and when it crashes, show the backtrace?

Now, I start emacs by: gdb --args emacs -q
and input "r" to run it

Gdb console says:
starting program: d:\emacs\bin\emacs.exe -q
[new thread 5860.0x1270]
[new thread 5860.0xa80]
[new thread 5860.0x69c]
[new thread 5860.0x1134]

and then I tried the step 3 and 4 many times with various file names
(e.g. main.c, test.c, etc.). Here the most important thing is that you
should try to hit C-j when the ido-mode is searching. The timing is the
key to catch the bug.

the gdb console says:
gdb: unknown target exception 0xc0000029 at 0x77d10754
program received signal ?, unknown signal.
[switch to thread 5860.0xa80]
0x77d10754 in ntdll!EtwpNotificationThread()
    from C:\Windows\system32\ntdll.dll
(gdb) warning: Invalid parameter passed to C runtime function. (9 times)

And after I input "c" to continue the program, emacs crashes, with
the gdb console saying:
program exited with code 030000000051

Re: might a bug in ido-mode

[Eli Zaretskii]

> From: zwz <zhangweize@gmail.com>
> Date: Mon, 26 Apr 2010 19:27:24 +0800
> 
> and then I tried the step 3 and 4 many times with various file names
> (e.g. main.c, test.c, etc.). Here the most important thing is that you
> should try to hit C-j when the ido-mode is searching. The timing is the
> key to catch the bug.

I didn't succeed in doing that, ido is too fast on my machine.

> the gdb console says:
> gdb: unknown target exception 0xc0000029 at 0x77d10754
> program received signal ?, unknown signal.

What version of GDB is that? what does "gdb --version" display?

> [switch to thread 5860.0xa80]
> 0x77d10754 in ntdll!EtwpNotificationThread()
>     from C:\Windows\system32\ntdll.dll
> (gdb) warning: Invalid parameter passed to C runtime function. (9 times)
> 
> And after I input "c" to continue the program, emacs crashes, with
> the gdb console saying:
> program exited with code 030000000051

Instead of typing "c", type "bt" and show the results.  Please do that
in all of the 4 threads you have, like this:

  (gdb) thread 1
  (gdb) bt
  (gdb) thread 2
  (gdb) bt

etc.

Thanks.

Re: might a bug in ido-mode

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> Instead of typing "c", type "bt" and show the results.  Please do that
> in all of the 4 threads you have, like this:
>
>   (gdb) thread 1
>   (gdb) bt
>   (gdb) thread 2
>   (gdb) bt
>
> etc.

or

(gdb) thread apply all bt

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: might a bug in ido-mode

[zwz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: zwz <zhangweize@gmail.com>
>> Date: Mon, 26 Apr 2010 19:27:24 +0800
>> 
>> and then I tried the step 3 and 4 many times with various file names
>> (e.g. main.c, test.c, etc.). Here the most important thing is that you
>> should try to hit C-j when the ido-mode is searching. The timing is the
>> key to catch the bug.
>
> I didn't succeed in doing that, ido is too fast on my machine.

When I am using ido, I can see "searching for main.cpp ..." in the
minibuffer, and then I try to hit the C-j, or backspace to catch the bug.

>
>> the gdb console says:
>> gdb: unknown target exception 0xc0000029 at 0x77d10754
>> program received signal ?, unknown signal.
>
> What version of GDB is that? what does "gdb --version" display?

I am using GDB 7.1.

>
>> [switch to thread 5860.0xa80]
>> 0x77d10754 in ntdll!EtwpNotificationThread()
>>     from C:\Windows\system32\ntdll.dll
>> (gdb) warning: Invalid parameter passed to C runtime function. (9 times)
>> 
>> And after I input "c" to continue the program, emacs crashes, with
>> the gdb console saying:
>> program exited with code 030000000051
>
> Instead of typing "c", type "bt" and show the results.  Please do that
> in all of the 4 threads you have, like this:
>
>   (gdb) thread 1
>   (gdb) bt
>   (gdb) thread 2
>   (gdb) bt
>
> etc.
>
> Thanks.

Re: might a bug in ido-mode

[zwz]

Andreas Schwab <schwab@linux-m68k.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Instead of typing "c", type "bt" and show the results.  Please do that
>> in all of the 4 threads you have, like this:
>>
>>   (gdb) thread 1
>>   (gdb) bt
>>   (gdb) thread 2
>>   (gdb) bt
>>
>> etc.
>
> or
>
> (gdb) thread apply all bt
>
> Andreas.

Ok. Here is the output:
Thread 3 (thread 4136.0xa80):
#0  0x77cf5e74 in ntdll!LdrAccessResource ()
    from C:\windows\system32\ntddl.dll
#1  0x77cf5610 in ntdll!ZwWaitForMultipleObjects32 ()
    from C:\windows\system32\ntddl.dll
#2  0x7672a5d7 in WaitForMultipleObjectsEx ()
    from C:\windows\system32\kernel32.dll
#3  0x00000002 in ?? ()
#4  0x21dafef0 in ?? ()
#5  0x7672a6f0 in WaitForMultipleObjects ()
    from C:\windows\system32\kernel32.dll
#6  0x6e2d1883 in msiltcfg!ShutdownMsi ()
    from C:\windows\system32\msiltcfg.dll
#7  0x00000002 in ?? ()
#8  0x21daff78 in ?? ()
#9  0x7672d0e9 in KERNEL32!AcquireSRWLockExclusive ()
    from C:\windows\system32\kernel32.dll
#10 0x77cd19bb in ntdll!RtlInitializeNtUserPfn ()
    from C:\windows\system32\ntddl.dll
#11 0x77cd198e in ntdll!RtlInitializeNtUserPfn ()
    from C:\windows\system32\ntddl.dll
#12 0x00000000 in ?? ()

Thread 2 (thread 4136.0x1148):
#0  0x77cf5e74 in ntdll!LdrAccessResource ()
    from C:\windows\system32\ntddl.dll
#1  0x76aed67f in setjmp () from C:\windows\system32\msvcrt.dll
#2  0x0082ffc4 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (thread 4136.0xea8):
#0  0x77cf5e74 in ntdll!LdrAccessResource ()
    from C:\windows\system32\ntddl.dll
#1  0x764a6fd1 in USER32!SetMenuContextHelpId ()
    from C:\windows\system32\user32.dll
#2  0x0116e2fe in set_frame_menubar ()
#3  0x010178ef in update_menu_bar ()
#4  0x0102ad6a in prepare_menu_bars ()
#5  0x0102ed02 in redisplay_internal ()
#6  0x01061d66 in read_char ()
#7  0x01063334 in read_key_sequence.clone.0 ()
#8  0x01065bd0 in command_loop_1 ()
#9  0x0100a592 in internal_condition_case ()
#10 0x0105bebf in command_loop_2 ()
#11 0x0100a4dc in internal_catch ()
#12 0x0105c848 in command_loop ()
#13 0x0105c8d3 in recursive_edit_1 ()
#14 0x0104c8ce in Frecursive_edit ()
#15 0x01002d86 in main ()

I am using gdb 7.1.
p.s. Is there anyway to print the backtract to a file?

I want to give another description of how I catch the bug.
After C-x C-f, and input a file name, usually the ido-mode will try to
search in other directories if such a file exists, and says in the
minibuffer "searching for blabal ...". Now it is the very timing to hit
C-j or backspace. I find it is easier to catch the bug by backspace.
Anyway, I have to try many times in different directories with various
file names (which should be found by ido-mode in another directory other
than the current one) to catch the bug.

Hope this helps.

Re: might a bug in ido-mode

[Eli Zaretskii]

> From: zwz <zhangweize@gmail.com>
> Date: Tue, 27 Apr 2010 16:21:29 +0800
> 
> Thread 1 (thread 4136.0xea8):
> #0  0x77cf5e74 in ntdll!LdrAccessResource ()
>     from C:\windows\system32\ntddl.dll
> #1  0x764a6fd1 in USER32!SetMenuContextHelpId ()
>     from C:\windows\system32\user32.dll
> #2  0x0116e2fe in set_frame_menubar ()
> #3  0x010178ef in update_menu_bar ()
> #4  0x0102ad6a in prepare_menu_bars ()
> #5  0x0102ed02 in redisplay_internal ()
> #6  0x01061d66 in read_char ()
> #7  0x01063334 in read_key_sequence.clone.0 ()
> #8  0x01065bd0 in command_loop_1 ()
> #9  0x0100a592 in internal_condition_case ()
> #10 0x0105bebf in command_loop_2 ()
> #11 0x0100a4dc in internal_catch ()
> #12 0x0105c848 in command_loop ()
> #13 0x0105c8d3 in recursive_edit_1 ()
> #14 0x0104c8ce in Frecursive_edit ()
> #15 0x01002d86 in main ()

This thread (thread 1) is the one we are interested in.  But why
doesn't the backtrace include function arguments?  Did you strip some
of the debugging info or something?

What does this show:

  (gdb) thread 1
  (gdb) bt 5 full

> p.s. Is there anyway to print the backtract to a file?

Yes, say "set logging on" before "bt", and then all output will be ion
the file gdb.txt.

Re: might a bug in ido-mode

[zwz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: zwz <zhangweize@gmail.com>
>> Date: Tue, 27 Apr 2010 16:21:29 +0800
>> 
>> Thread 1 (thread 4136.0xea8):
>> #0  0x77cf5e74 in ntdll!LdrAccessResource ()
>>     from C:\windows\system32\ntddl.dll
>> #1  0x764a6fd1 in USER32!SetMenuContextHelpId ()
>>     from C:\windows\system32\user32.dll
>> #2  0x0116e2fe in set_frame_menubar ()
>> #3  0x010178ef in update_menu_bar ()
>> #4  0x0102ad6a in prepare_menu_bars ()
>> #5  0x0102ed02 in redisplay_internal ()
>> #6  0x01061d66 in read_char ()
>> #7  0x01063334 in read_key_sequence.clone.0 ()
>> #8  0x01065bd0 in command_loop_1 ()
>> #9  0x0100a592 in internal_condition_case ()
>> #10 0x0105bebf in command_loop_2 ()
>> #11 0x0100a4dc in internal_catch ()
>> #12 0x0105c848 in command_loop ()
>> #13 0x0105c8d3 in recursive_edit_1 ()
>> #14 0x0104c8ce in Frecursive_edit ()
>> #15 0x01002d86 in main ()
>
> This thread (thread 1) is the one we are interested in.  But why
> doesn't the backtrace include function arguments?  Did you strip some
> of the debugging info or something?

No, this is what gdb outputs. I have no idea why it does not include more info.

>
> What does this show:
>
>   (gdb) thread 1
>   (gdb) bt 5 full

I tried this one. But still no function arguments.
However this time the debug info is a little different:
(gdb) #0  0x77cccd69 in ntdll!RtlAreAllAccessesGranted ()
   from C:\Windows\system32\ntdll.dll
No symbol table info available.
#1  0x77cce275 in ntdll!LdrGetProcedureAddress ()
   from C:\Windows\system32\ntdll.dll
No symbol table info available.
#2  0x76726a69 in KERNEL32!FindResourceW ()
   from C:\Windows\system32\kernel32.dll
No symbol table info available.
#3  0x22a60001 in ?? ()
No symbol table info available.
#4  0x764ac5f7 in USER32!GetMenuBarInfo () from C:\Windows\system32\user32.dll
No symbol table info available.
(More stack frames follow...)
(gdb) [Switching to thread 2 (Thread 5496.0x17d0)]#0  0x77d10754 in ntdll!EtwpNotificationThread () from C:\Windows\system32\ntdll.dll
(gdb) #0  0x77d10754 in ntdll!EtwpNotificationThread ()
   from C:\Windows\system32\ntdll.dll
No symbol table info available.
#1  0x76aed67f in setjmp () from C:\Windows\system32\msvcrt.dll
No symbol table info available.
#2  0x0082ffc4 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) [Switching to thread 3 (Thread 5496.0x1f24)]#0  0x77cf5e74 in ntdll!LdrAccessResource () from C:\Windows\system32\ntdll.dll
(gdb) Invalid character '^[' in expression.


Here is the output by "thread apply all bt":
Thread 3 (Thread 5496.0x1f24):
#0  0x77cf5e74 in ntdll!LdrAccessResource ()
   from C:\Windows\system32\ntdll.dll
#1  0x77cf5610 in ntdll!ZwWaitForMultipleObjects32 ()
   from C:\Windows\system32\ntdll.dll
#2  0x7672a5d7 in WaitForMultipleObjectsEx ()
   from C:\Windows\system32\kernel32.dll
#3  0x00000002 in ?? ()
#4  0x2226fef0 in ?? ()
#5  0x7672a6f0 in WaitForMultipleObjects ()
   from C:\Windows\system32\kernel32.dll
#6  0x6e2d1883 in msiltcfg!ShutdownMsi ()
   from C:\Windows\system32\msiltcfg.dll
#7  0x00000002 in ?? ()
#8  0x2226ff78 in ?? ()
#9  0x7672d0e9 in KERNEL32!AcquireSRWLockExclusive ()
   from C:\Windows\system32\kernel32.dll
#10 0x77cd19bb in ntdll!RtlInitializeNtUserPfn ()
   from C:\Windows\system32\ntdll.dll
#11 0x77cd198e in ntdll!RtlInitializeNtUserPfn ()
   from C:\Windows\system32\ntdll.dll
#12 0x00000000 in ?? ()

Thread 2 (Thread 5496.0x17d0):
#0  0x77d10754 in ntdll!EtwpNotificationThread ()
   from C:\Windows\system32\ntdll.dll
#1  0x76aed67f in setjmp () from C:\Windows\system32\msvcrt.dll
#2  0x0082ffc4 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Thread 1 (Thread 5496.0x1b20):
#0  0x77cccd69 in ntdll!RtlAreAllAccessesGranted ()
   from C:\Windows\system32\ntdll.dll
#1  0x77cce275 in ntdll!LdrGetProcedureAddress ()
   from C:\Windows\system32\ntdll.dll
#2  0x76726a69 in KERNEL32!FindResourceW ()
   from C:\Windows\system32\kernel32.dll
#3  0x22a60001 in ?? ()
#4  0x764ac5f7 in USER32!GetMenuBarInfo () from C:\Windows\system32\user32.dll
#5  0x22a60001 in ?? ()
#6  0x764ac619 in USER32!GetMenuBarInfo () from C:\Windows\system32\user32.dll
#7  0x22a60001 in ?? ()
#8  0x764ac508 in USER32!GetMenuBarInfo () from C:\Windows\system32\user32.dll
#9  0x22a60001 in ?? ()
#10 0x764ac67e in USER32!GetMenuBarInfo () from C:\Windows\system32\user32.dll
#11 0x22a60001 in ?? ()
#12 0x764adaba in USER32!LoadImageA () from C:\Windows\system32\user32.dll
#13 0x7536a13e in DllInstall ()
   from C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll
#14 0x752e223c in DPA_GetPtrIndex ()
   from C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll
#15 0x7531bb28 in DSA_EnumCallback ()
   from C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll
#16 0x752e2fb9 in DPA_GetPtrIndex ()
   from C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll
#17 0x75308540 in DSA_Destroy ()
   from C:\Windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.6002.18005_none_5cb72f96088b0de0\comctl32.dll
#18 0x764bfd72 in USER32!GetWindowMinimizeRect ()
   from C:\Windows\system32\user32.dll
#19 0x000b0d32 in ?? ()
#20 0x00000001 in ?? ()
#21 0x00000000 in ?? ()

>
>> p.s. Is there anyway to print the backtract to a file?
>
> Yes, say "set logging on" before "bt", and then all output will be ion
> the file gdb.txt.

Re: might a bug in ido-mode

[Eli Zaretskii]

> From: zwz <zhangweize@gmail.com>
> Date: Wed, 28 Apr 2010 12:23:08 +0800
> 
> > What does this show:
> >
> >   (gdb) thread 1
> >   (gdb) bt 5 full
> 
> I tried this one. But still no function arguments.
> However this time the debug info is a little different:

You are deeper in the stack, so you need more than 5 in the bt
command.

I'm not sure what this means.  Emacs crashes deep inside Windows
system libraries, for some reason I cannot grok.

Re: might a bug in ido-mode

[zwz]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: zwz <zhangweize@gmail.com>
>> Date: Wed, 28 Apr 2010 12:23:08 +0800
>> 
>> > What does this show:
>> >
>> >   (gdb) thread 1
>> >   (gdb) bt 5 full
>> 
>> I tried this one. But still no function arguments.
>> However this time the debug info is a little different:
>
> You are deeper in the stack, so you need more than 5 in the bt
> command.

I tried other options, but the output is the same.

>
> I'm not sure what this means.  Emacs crashes deep inside Windows
> system libraries, for some reason I cannot grok.

Yes, I cannot reproduce the bug on Linux. It is weird. Maybe it has
something to do tramp, since after C-x C-f the tramp library is loaded.