bug#7190: Crash in menus on w32

bug#7190: Crash in menus on w32

[Lennart Borgman]

Crash in menus on w32, my patched version of course. Any suggestions?


warning: HEAP[emacs.exe]:
warning: Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )


Program received signal SIGTRAP, Trace/breakpoint trap.
0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
(gdb) bt
#0  0x7c90120f in ntdll!DbgUiConnectToDbg ()
   from C:\WINDOWS\system32\ntdll.dll
#1  0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#2  0x7c96e576 in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#3  0x7c96f75e in ntdll!RtlpNtMakeTemporaryKey ()
   from C:\WINDOWS\system32\ntdll.dll
#4  0x7c94bc4c in ntdll!LdrFindEntryForAddress ()
   from C:\WINDOWS\system32\ntdll.dll
#5  0x00850000 in ?? ()
#6  0x7c927573 in ntdll!RtlPcToFileHeader ()
   from C:\WINDOWS\system32\ntdll.dll
#7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
#8  0x011c4e5f in w32_free_submenu_strings (menu=0x205f3) at w32menu.c:1706
#9  0x011c4e5f in w32_free_submenu_strings (menu=0xdd10145) at w32menu.c:1706
#10 0x011c4eaa in w32_free_menu_strings (hwnd=0x900ca) at w32menu.c:1723
#11 0x011c2b6e in menubar_selection_callback (f=0x3f63000, client_data=0x2510)
    at w32menu.c:353
#12 0x011dc6fc in w32_read_socket (terminal=0x3053c00, expected=0,
    hold_quit=0x82f6e0) at w32term.c:4624
#13 0x0100e484 in read_avail_input (expected=0) at keyboard.c:6986
#14 0x0100e38e in gobble_input (expected=0) at keyboard.c:6907
#15 0x0100e341 in get_input_pending (addr=0x13fab50, flags=1)
    at keyboard.c:6870
#16 0x0101489c in detect_input_pending_run_timers (do_display=0)
    at keyboard.c:10511
#17 0x01007d44 in read_char (commandflag=1, nmaps=22, maps=0x82f990,
    prev_event=45467674, used_mouse_menu=0x82fb6c, end_time=0x0)
    at keyboard.c:2556
#18 0x01011c8e in read_key_sequence (keybuf=0x82fc60, bufsize=30,
    prompt=45467674, dont_downcase_last=0, can_return_switch_frame=1,
    fix_current_buffer=1) at keyboard.c:9349
#19 0x010064a7 in command_loop_1 () at keyboard.c:1618
#20 0x01020721 in internal_condition_case (bfun=0x1006185 <command_loop_1>,
    handlers=45521258, hfun=0x1005b7a <cmd_error>) at eval.c:1460
#21 0x01005eea in command_loop_2 (ignore=45467674) at keyboard.c:1338
#22 0x01020212 in internal_catch (tag=45519378,
    func=0x1005ec7 <command_loop_2>, arg=45467674) at eval.c:1204
#23 0x01005ea2 in command_loop () at keyboard.c:1317
#24 0x01005796 in recursive_edit_1 () at keyboard.c:940
#25 0x010058fa in Frecursive_edit () at keyboard.c:1002
#26 0x0100264c in main (argc=1, argv=0xa928e8) at emacs.c:1704
(gdb)

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 11 Oct 2010 17:13:55 +0200
> Cc: 
> 
> Crash in menus on w32, my patched version of course. Any suggestions?
> 
> 
> warning: HEAP[emacs.exe]:
> warning: Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )
> 
> 
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
> (gdb) bt
> #0  0x7c90120f in ntdll!DbgUiConnectToDbg ()
>    from C:\WINDOWS\system32\ntdll.dll
> #1  0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey ()
>    from C:\WINDOWS\system32\ntdll.dll
> #2  0x7c96e576 in ntdll!RtlpNtMakeTemporaryKey ()
>    from C:\WINDOWS\system32\ntdll.dll
> #3  0x7c96f75e in ntdll!RtlpNtMakeTemporaryKey ()
>    from C:\WINDOWS\system32\ntdll.dll
> #4  0x7c94bc4c in ntdll!LdrFindEntryForAddress ()
>    from C:\WINDOWS\system32\ntdll.dll
> #5  0x00850000 in ?? ()
> #6  0x7c927573 in ntdll!RtlPcToFileHeader ()
>    from C:\WINDOWS\system32\ntdll.dll
> #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701

Looks identical to bug #7170.  Why did you open a new one?

And I don't understand what suggestion do you expect.  This happened
only for you so far, so you need to debug it on your machine.

One thing to do would be to see, each time this happen, which menu,
submenu, menu item(s) are involved.  If they are the same every time,
you will have to take a closer look at the code which creates them.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Mon, Oct 11, 2010 at 9:20 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 11 Oct 2010 17:13:55 +0200
>> Cc:
>>
>> Crash in menus on w32, my patched version of course. Any suggestions?
>>
>>
>> warning: HEAP[emacs.exe]:
>> warning: Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )
>>
>>
>> Program received signal SIGTRAP, Trace/breakpoint trap.
>> 0x7c90120f in ntdll!DbgUiConnectToDbg () from C:\WINDOWS\system32\ntdll.dll
>> (gdb) bt
>> #0  0x7c90120f in ntdll!DbgUiConnectToDbg ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #1  0x7c96e139 in ntdll!RtlpNtMakeTemporaryKey ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #2  0x7c96e576 in ntdll!RtlpNtMakeTemporaryKey ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #3  0x7c96f75e in ntdll!RtlpNtMakeTemporaryKey ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #4  0x7c94bc4c in ntdll!LdrFindEntryForAddress ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #5  0x00850000 in ?? ()
>> #6  0x7c927573 in ntdll!RtlPcToFileHeader ()
>>    from C:\WINDOWS\system32\ntdll.dll
>> #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
>
> Looks identical to bug #7170.  Why did you open a new one?

Yes, it was a bit stupid to open a new one.

> And I don't understand what suggestion do you expect.  This happened
> only for you so far, so you need to debug it on your machine.
>
> One thing to do would be to see, each time this happen, which menu,
> submenu, menu item(s) are involved.  If they are the same every time,
> you will have to take a closer look at the code which creates them.

I will try to remember what I did next time. I was in a hurry when
this happened so I am not quite sure.

Maybe it would be useful to trace the order of events with DebPrint
since they seem to be wrong? Any suggestions on what to trace?

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Mon, 11 Oct 2010 23:21:27 +0200
> Cc: 7190@debbugs.gnu.org
> 
> > One thing to do would be to see, each time this happen, which menu,
> > submenu, menu item(s) are involved.  If they are the same every time,
> > you will have to take a closer look at the code which creates them.
> 
> I will try to remember what I did next time. I was in a hurry when
> this happened so I am not quite sure.

I didn't mean that you need to remember what you did.  I meant to use
the debugger _when_ it crashes to find out what was the menu in
question.

> Maybe it would be useful to trace the order of events with DebPrint
> since they seem to be wrong? Any suggestions on what to trace?

I have no idea, because I don't know how to guess that from the
backtrace alone.  At least some data regarding the reason(s) of the
crash is needed, see above.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Tue, Oct 12, 2010 at 6:04 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Mon, 11 Oct 2010 23:21:27 +0200
>> Cc: 7190@debbugs.gnu.org
>>
>> > One thing to do would be to see, each time this happen, which menu,
>> > submenu, menu item(s) are involved.  If they are the same every time,
>> > you will have to take a closer look at the code which creates them.
>>
>> I will try to remember what I did next time. I was in a hurry when
>> this happened so I am not quite sure.
>
> I didn't mean that you need to remember what you did.  I meant to use
> the debugger _when_ it crashes to find out what was the menu in
> question.

Exactly how do I see that?

>> Maybe it would be useful to trace the order of events with DebPrint
>> since they seem to be wrong? Any suggestions on what to trace?
>
> I have no idea, because I don't know how to guess that from the
> backtrace alone.  At least some data regarding the reason(s) of the
> crash is needed, see above.

I just meant adding some DebPrint statements and recompile.

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 12 Oct 2010 11:37:52 +0200
> Cc: 7190@debbugs.gnu.org
> 
> > I didn't mean that you need to remember what you did.  I meant to use
> > the debugger _when_ it crashes to find out what was the menu in
> > question.
> 
> Exactly how do I see that?

By looking at the menu data structures accessed by these functions:

  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
  #8  0x011c4e5f in w32_free_submenu_strings (menu=0x205f3) at w32menu.c:1706
  #9  0x011c4e5f in w32_free_submenu_strings (menu=0xdd10145) at w32menu.c:1706
  #10 0x011c4eaa in w32_free_menu_strings (hwnd=0x900ca) at w32menu.c:1723
  #11 0x011c2b6e in menubar_selection_callback (f=0x3f63000, client_data=0x2510)
      at w32menu.c:353

In menubar_selection_callback, you will find that Emacs stores in the
keyboard buffer a couple of events produced by a menu selection.  If
my reading of the code is correct, this code:

	  entry = AREF (vector, i + MENU_ITEMS_ITEM_VALUE);

retrieves the selected menu item, and `vector' is the entire menu bar,
computed as

  vector = f->menu_bar_vector;

See frame.h for the structure of this vector.

By looking at `entry' you can find which menu item is being selected.

Then in w32_free_submenu_strings, you can see the same info in its
bare C form.

> >> Maybe it would be useful to trace the order of events with DebPrint
> >> since they seem to be wrong? Any suggestions on what to trace?
> >
> > I have no idea, because I don't know how to guess that from the
> > backtrace alone.  At least some data regarding the reason(s) of the
> > crash is needed, see above.
> 
> I just meant adding some DebPrint statements and recompile.

I wouldn't know where to add these statements, because we have no idea
what is causing the memory corruption which leads to the crash.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Tue, Oct 12, 2010 at 9:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Then in w32_free_submenu_strings, you can see the same info in its
> bare C form.

Thanks. I will use all this info you gave in the next crash.

>> I just meant adding some DebPrint statements and recompile.
>
> I wouldn't know where to add these statements, because we have no idea
> what is causing the memory corruption which leads to the crash.

I would assume that is all happens within the menus. Is the menu code
synched with the other code? Is it perhaps running in a separate
thread and not in Emacs normal GUI thread?

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 12 Oct 2010 21:13:08 +0200
> Cc: 7190@debbugs.gnu.org
> 
> >> I just meant adding some DebPrint statements and recompile.
> >
> > I wouldn't know where to add these statements, because we have no idea
> > what is causing the memory corruption which leads to the crash.
> 
> I would assume that is all happens within the menus.

No, it happens within Emacs.  We allocate the memory that we free when
Emacs crashes.

> Is the menu code synched with the other code? Is it perhaps running
> in a separate thread and not in Emacs normal GUI thread?

You can see in the backtrace that the code which crashes is called
from command_loop -> read_key_sequence -> read_socket chain, which is
part of the normal Emacs input processing of the main thread.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Tue, Oct 12, 2010 at 9:40 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 12 Oct 2010 21:13:08 +0200
>> Cc: 7190@debbugs.gnu.org
>>
>> >> I just meant adding some DebPrint statements and recompile.
>> >
>> > I wouldn't know where to add these statements, because we have no idea
>> > what is causing the memory corruption which leads to the crash.
>>
>> I would assume that is all happens within the menus.
>
> No, it happens within Emacs.  We allocate the memory that we free when
> Emacs crashes.

I mean that the failing code is among the code handling menus in Emacs.

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 12 Oct 2010 22:09:24 +0200
> Cc: 7190@debbugs.gnu.org
> 
> >> >> I just meant adding some DebPrint statements and recompile.
> >> >
> >> > I wouldn't know where to add these statements, because we have no idea
> >> > what is causing the memory corruption which leads to the crash.
> >>
> >> I would assume that is all happens within the menus.
> >
> > No, it happens within Emacs.  We allocate the memory that we free when
> > Emacs crashes.
> 
> I mean that the failing code is among the code handling menus in Emacs.

Yes.  But how does that help with adding debug prints?  The code that
handles menus is spread across several nontrivial functions, and we
have no idea which of them causes the problem and where.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Tue, Oct 12, 2010 at 10:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>
>> I mean that the failing code is among the code handling menus in Emacs.
>
> Yes.  But how does that help with adding debug prints?  The code that
> handles menus is spread across several nontrivial functions, and we
> have no idea which of them causes the problem and where.

I assume that their is either a logical problem with the code inside
Emacs or a bad assumption on how menu callbacks are actually run. By
adding DebPrint call we could perhaps see if some code where called in
an order we did not expect.

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 12 Oct 2010 22:49:11 +0200
> Cc: 7190@debbugs.gnu.org
> 
> On Tue, Oct 12, 2010 at 10:14 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >>
> >> I mean that the failing code is among the code handling menus in Emacs.
> >
> > Yes.  But how does that help with adding debug prints?  The code that
> > handles menus is spread across several nontrivial functions, and we
> > have no idea which of them causes the problem and where.
> 
> I assume that their is either a logical problem with the code inside
> Emacs or a bad assumption on how menu callbacks are actually run. By
> adding DebPrint call we could perhaps see if some code where called in
> an order we did not expect.

Good luck doing that; without at least some idea where the problem
happens, I would be unable to recommend where to put such DebPrint's
or what to print.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Tue, Oct 12, 2010 at 9:05 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 12 Oct 2010 11:37:52 +0200
>> Cc: 7190@debbugs.gnu.org
>>
>> > I didn't mean that you need to remember what you did.  I meant to use
>> > the debugger _when_ it crashes to find out what was the menu in
>> > question.
>>
>> Exactly how do I see that?
>
> By looking at the menu data structures accessed by these functions:
>
>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
>  #8  0x011c4e5f in w32_free_submenu_strings (menu=0x205f3) at w32menu.c:1706
>  #9  0x011c4e5f in w32_free_submenu_strings (menu=0xdd10145) at w32menu.c:1706
>  #10 0x011c4eaa in w32_free_menu_strings (hwnd=0x900ca) at w32menu.c:1723
>  #11 0x011c2b6e in menubar_selection_callback (f=0x3f63000, client_data=0x2510)
>      at w32menu.c:353
>
> In menubar_selection_callback, you will find that Emacs stores in the
> keyboard buffer a couple of events produced by a menu selection.  If
> my reading of the code is correct, this code:
>
>          entry = AREF (vector, i + MENU_ITEMS_ITEM_VALUE);
>
> retrieves the selected menu item, and `vector' is the entire menu bar,
> computed as
>
>  vector = f->menu_bar_vector;
>
> See frame.h for the structure of this vector.
>
> By looking at `entry' you can find which menu item is being selected.
>
> Then in w32_free_submenu_strings, you can see the same info in its
> bare C form.

I just got a new crash, but unfortunately I have still not understand
how to look at those values. With "bt full" I get this (part of the
bt):

#6  0x7c927573 in ntdll!RtlPcToFileHeader ()
   from C:\WINDOWS\system32\ntdll.dll
No symbol table info available.
#7  0x011c5399 in w32_free_submenu_strings (menu=0x9a05c5) at w32menu.c:1692
        info = {
          cbSize = 44,
          fMask = 52,
          fType = 256,
          fState = 0,
          wID = 0,
          hSubMenu = 0x0,
          hbmpChecked = 0x0,
          hbmpUnchecked = 0x0,
          dwItemData = 8975208,
          dwTypeData = 0x0,
          cch = 0
        }
        i = 6
        num = 17
#8  0x011c53ad in w32_free_submenu_strings (menu=0x5e80611) at w32menu.c:1697
        info = {
          cbSize = 44,
          fMask = 52,
          fType = 0,
          fState = 0,
          wID = 0,
          hSubMenu = 0x9a05c5,
          hbmpChecked = 0x0,
          hbmpUnchecked = 0x0,
          dwItemData = 0,
          dwTypeData = 0x0,
          cch = 10
        }
        i = 10
        num = 30
#9  0x011c53ad in w32_free_submenu_strings (menu=0x464d04eb) at w32menu.c:1697
        info = {
          cbSize = 44,
          fMask = 52,
          fType = 0,
          fState = 0,
          wID = 0,
          hSubMenu = 0x5e80611,
          hbmpChecked = 0x0,
          hbmpUnchecked = 0x0,
          dwItemData = 0,
          dwTypeData = 0x0,
          cch = 4
        }
        i = 5
        num = 10
#10 0x011c53f8 in w32_free_menu_strings (hwnd=0x220048) at w32menu.c:1714
        menu = 0x464d04eb
#11 0x011c311a in menubar_selection_callback (f=0x411dc00, client_data=0x184a)
    at w32menu.c:353
        j = 1
        buf = {
          kind = MENU_BAR_EVENT,
          code = 0,
          part = scroll_bar_above_handle,
          modifiers = 0,
          x = 0,
          y = 0,
          timestamp = 0,
          padding = {0x0, 0x0},
          frame_or_window = 68279301,
          arg = 59691226
        }
        frame = 68279301
        prefix = 59691298
        entry = 59691226
        vector = 92061701
        subprefix_stack = 0x825f00
        submenu_depth = 1
        i = 6218
#12 0x011dcc2c in w32_read_socket (terminal=0x2d04c00, expected=0,
    hold_quit=0x82f6e0) at w32term.c:4623
        inev = {
          kind = NO_EVENT,
          code = 0,
          part = scroll_bar_above_handle,
          modifiers = 0,
          x = 0,
          y = 0,
          timestamp = 0,
          padding = {0x0, 0x0},
          frame_or_window = 0,
          arg = 45484058
        }
        do_help = 0
        count = 0
        check_visibility = 0
        msg = {
          msg = {
            hwnd = 0x220048,
            message = 273,
            wParam = 6218,
            lParam = 0,
            time = 59842578,
            pt = {
              x = 7,
              y = 327687
            }
          },
          dwModifiers = 0,
          rect = {
            left = 545258848,
            top = 2118300673,
            right = 13317672,
            bottom = 0
          }
        }
        f = 0x411dc00
        dpyinfo = 0x14061b0

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Tue, 19 Oct 2010 02:20:42 +0200
> Cc: 7190@debbugs.gnu.org
> 
> >          entry = AREF (vector, i + MENU_ITEMS_ITEM_VALUE);
> >
> > retrieves the selected menu item, and `vector' is the entire menu bar,
> > computed as
> >
> >  vector = f->menu_bar_vector;
> >
> > See frame.h for the structure of this vector.
> >
> > By looking at `entry' you can find which menu item is being selected.
> >
> > Then in w32_free_submenu_strings, you can see the same info in its
> > bare C form.
> 
> I just got a new crash, but unfortunately I have still not understand
> how to look at those values.

Please be specific: what parts in the explanation above you don't
understand?  I don't know how to answer a question "I don't understand
how to do X", when I already explained how to do it.

> With "bt full"

"bt full" is useless in this case, because the problem is a corruption
of the heap.  We need to establish which menu item(s) are corrupted,
and the information about that is not in local variables displayed by
"bt full", it's in the data structures manipulated by
w32_free_submenu_strings and w32_free_menu_strings.  I gave you above
the way to start looking at these data structures.  Please try using
that as the starting point, and if the problem is not immediately
obvious, come back and report your findings.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Tue, Oct 19, 2010 at 7:59 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Lennart Borgman <lennart.borgman@gmail.com>
>> Date: Tue, 19 Oct 2010 02:20:42 +0200
>> Cc: 7190@debbugs.gnu.org
>>
>> >          entry = AREF (vector, i + MENU_ITEMS_ITEM_VALUE);
>> >
>> > retrieves the selected menu item, and `vector' is the entire menu bar,
>> > computed as
>> >
>> >  vector = f->menu_bar_vector;
>> >
>> > See frame.h for the structure of this vector.
>> >
>> > By looking at `entry' you can find which menu item is being selected.
>> >
>> > Then in w32_free_submenu_strings, you can see the same info in its
>> > bare C form.
>>
>> I just got a new crash, but unfortunately I have still not understand
>> how to look at those values.
>
> Please be specific: what parts in the explanation above you don't
> understand?  I don't know how to answer a question "I don't understand
> how to do X", when I already explained how to do it.
>
>> With "bt full"
>
> "bt full" is useless in this case, because the problem is a corruption
> of the heap.  We need to establish which menu item(s) are corrupted,
> and the information about that is not in local variables displayed by
> "bt full", it's in the data structures manipulated by
> w32_free_submenu_strings and w32_free_menu_strings.  I gave you above
> the way to start looking at these data structures.

Could you please tell me the exact commands to look at those data structures?

bug#7190: Crash in menus on w32

[grischka]

> I assume that their is either a logical problem with the code inside
> Emacs or a bad assumption on how menu callbacks are actually run. 

Is there a difference between logical problem and bad assumption?

> By
> adding DebPrint call we could perhaps see if some code where called in
> an order we did not expect.

Perhaps see the information that you already have?  For example
   #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
is telling where is "some code", and
   "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
is telling about "order we did not expect", as likely in:  Called
twice for the same memory object.  If in doubt, try to prove that
it can't happen.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Wed, Oct 13, 2010 at 1:02 PM, grischka <grishka@gmx.de> wrote:
>> I assume that their is either a logical problem with the code inside
>> Emacs or a bad assumption on how menu callbacks are actually run.
>
> Is there a difference between logical problem and bad assumption?

Yes. The code could be correct under some bad assumptions regarding
the way the interface to the OS works.

Is not that an important difference?

>> By
>> adding DebPrint call we could perhaps see if some code where called in
>> an order we did not expect.
>
> Perhaps see the information that you already have?  For example
>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
> is telling where is "some code", and
>  "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
> is telling about "order we did not expect", as likely in:  Called
> twice for the same memory object.  If in doubt, try to prove that
> it can't happen.

Yes, perhaps. But it could also be that memory objects are freed in an
order we did not expect.

bug#7190: Crash in menus on w32

[grischka]

Lennart Borgman wrote:
> On Wed, Oct 13, 2010 at 1:02 PM, grischka <grishka@gmx.de> wrote:
>>> I assume that their is either a logical problem with the code inside
>>> Emacs or a bad assumption on how menu callbacks are actually run.
>> Is there a difference between logical problem and bad assumption?
> 
> Yes. The code could be correct under some bad assumptions regarding
> the way the interface to the OS works.
> 
> Is not that an important difference?

Not if you want to fix the bug.

>>> By
>>> adding DebPrint call we could perhaps see if some code where called in
>>> an order we did not expect.
>> Perhaps see the information that you already have?  For example
>>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at w32menu.c:1701
>> is telling where is "some code", and
>>  "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
>> is telling about "order we did not expect", as likely in:  Called
>> twice for the same memory object.  If in doubt, try to prove that
>> it can't happen.
> 
> Yes, perhaps. But it could also be that memory objects are freed in an
> order we did not expect.
> 

Why should it matter in what order "Invalid Address" is passed to free?

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Wed, Oct 13, 2010 at 4:03 PM, grischka <grishka@gmx.de> wrote:
> Lennart Borgman wrote:
>>
>> On Wed, Oct 13, 2010 at 1:02 PM, grischka <grishka@gmx.de> wrote:
>>>>
>>>> I assume that their is either a logical problem with the code inside
>>>> Emacs or a bad assumption on how menu callbacks are actually run.
>>>
>>> Is there a difference between logical problem and bad assumption?
>>
>> Yes. The code could be correct under some bad assumptions regarding
>> the way the interface to the OS works.
>>
>> Is not that an important difference?
>
> Not if you want to fix the bug.

It looks like I am thinking nearly exactly the opposite.

For a simple bug it does not matter. For a complicated bug you can not
look at all possible places. That would take too long time. So putting
some structure on the different places and evaluating them makes much
sense to me.

>>>> By
>>>> adding DebPrint call we could perhaps see if some code where called in
>>>> an order we did not expect.
>>>
>>> Perhaps see the information that you already have?  For example
>>>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at
>>> w32menu.c:1701
>>> is telling where is "some code", and
>>>  "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
>>> is telling about "order we did not expect", as likely in:  Called
>>> twice for the same memory object.  If in doubt, try to prove that
>>> it can't happen.
>>
>> Yes, perhaps. But it could also be that memory objects are freed in an
>> order we did not expect.
>>
>
> Why should it matter in what order "Invalid Address" is passed to free?

Maybe I am misunderstanding, I do not know much about this part of the
code. Are you saying that you could not get this error from calls to
RtlFreeHeap coming in the wrong order? (That would perhaps help much
to know.)

bug#7190: Crash in menus on w32

[grischka]

Lennart Borgman wrote:
>>> Is not that an important difference?
>> Not if you want to fix the bug.
> 
> It looks like I am thinking nearly exactly the opposite.
> 
> For a simple bug it does not matter. For a complicated bug you can not
> look at all possible places. That would take too long time. So putting
> some structure on the different places and evaluating them makes much
> sense to me.

This bug is simple.

>>>>> By
>>>>> adding DebPrint call we could perhaps see if some code where called in
>>>>> an order we did not expect.
>>>> Perhaps see the information that you already have?  For example
>>>>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at
>>>> w32menu.c:1701
>>>> is telling where is "some code", and
>>>>  "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
>>>> is telling about "order we did not expect", as likely in:  Called
>>>> twice for the same memory object.  If in doubt, try to prove that
>>>> it can't happen.
>>> Yes, perhaps. But it could also be that memory objects are freed in an
>>> order we did not expect.
>>>
>> Why should it matter in what order "Invalid Address" is passed to free?
> 
> Maybe I am misunderstanding, I do not know much about this part of the
> code. Are you saying that you could not get this error from calls to
> RtlFreeHeap coming in the wrong order? (That would perhaps help much
> to know.)

Yes,  RtlFreeHeap (like any free) doesn't care about order.  It only
cares that it's a valid object (which it isn't if it was already freed).
Did not someone see corrupted first letters in menu strings and such?
That is also a symptom of premature free, often.  Count 1+1 ...

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Wed, Oct 13, 2010 at 5:51 PM, grischka <grishka@gmx.de> wrote:
> Lennart Borgman wrote:
>>>>
>>>> Is not that an important difference?
>>>
>>> Not if you want to fix the bug.
>>
>> It looks like I am thinking nearly exactly the opposite.
>>
>> For a simple bug it does not matter. For a complicated bug you can not
>> look at all possible places. That would take too long time. So putting
>> some structure on the different places and evaluating them makes much
>> sense to me.
>
> This bug is simple.

Didn't someone say life is easier for pessimists... ;-)

>>>>>> By
>>>>>> adding DebPrint call we could perhaps see if some code where called in
>>>>>> an order we did not expect.
>>>>>
>>>>> Perhaps see the information that you already have?  For example
>>>>>  #7  0x011c4e4b in w32_free_submenu_strings (menu=0x205e3) at
>>>>> w32menu.c:1701
>>>>> is telling where is "some code", and
>>>>>  "Invalid Address specified to RtlFreeHeap( 00850000, 0088BDC8 )"
>>>>> is telling about "order we did not expect", as likely in:  Called
>>>>> twice for the same memory object.  If in doubt, try to prove that
>>>>> it can't happen.
>>>>
>>>> Yes, perhaps. But it could also be that memory objects are freed in an
>>>> order we did not expect.
>>>>
>>> Why should it matter in what order "Invalid Address" is passed to free?
>>
>> Maybe I am misunderstanding, I do not know much about this part of the
>> code. Are you saying that you could not get this error from calls to
>> RtlFreeHeap coming in the wrong order? (That would perhaps help much
>> to know.)
>
> Yes,  RtlFreeHeap (like any free) doesn't care about order.  It only
> cares that it's a valid object (which it isn't if it was already freed).
> Did not someone see corrupted first letters in menu strings and such?
> That is also a symptom of premature free, often.  Count 1+1 ...

Thanks, that helps. It makes it easier for me to put in some trace
messages in useful places.

bug#7190: Crash in menus on w32

[grischka]

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

Here's a patch that fixes the bug.  Actually 4 bugs:
1) the initial cause: was freeing items prematurely and trying to
     free already freed items
2) memory leak: was trying to free items from already deleted menu
3) memory leak: was trying to free menu from already deleted window
4) other: was trying to set cursor in window with no associated frame

--- grischka


[-- Attachment #2: free-menu-strings.diff --]
[-- Type: text/plain, Size: 7179 bytes --]

commit 064225db78640a1fb48b68aac603c8e05cc69b80
Author: grischka <grischka>
Date:   Thu Oct 14 13:23:38 2010 +0200

    fix w32menu ownerdraw string alloc/free

diff --git a/src/w32fns.c b/src/w32fns.c
index 8085035..83d577e 100644
--- a/src/w32fns.c
+++ b/src/w32fns.c
@@ -76,7 +76,6 @@ extern void free_frame_menubar (struct frame *);
 extern double atof (const char *);
 extern int w32_console_toggle_lock_key (int, Lisp_Object);
 extern void w32_menu_display_help (HWND, HMENU, UINT, UINT);
-extern void w32_free_menu_strings (HWND);
 extern const char *map_w32_filename (const char *, const char **);
 
 extern int quit_char;
@@ -280,12 +279,7 @@ unsigned int msh_mousewheel = 0;
 /* Timers */
 #define MOUSE_BUTTON_ID	1
 #define MOUSE_MOVE_ID	2
-#define MENU_FREE_ID 3
 #define HOURGLASS_ID 4
-/* The delay (milliseconds) before a menu is freed after WM_EXITMENULOOP
-   is received.  */
-#define MENU_FREE_DELAY 1000
-static unsigned menu_free_timer = 0;
 
 /* In dispnew.c */
 
@@ -3387,21 +3381,6 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
 	  KillTimer (hwnd, mouse_move_timer);
 	  mouse_move_timer = 0;
 	}
-      else if (wParam == menu_free_timer)
-	{
-	  KillTimer (hwnd, menu_free_timer);
-	  menu_free_timer = 0;
-	  f = x_window_to_frame (dpyinfo, hwnd);
-          /* If a popup menu is active, don't wipe its strings.  */
-	  if (menubar_in_use
-              && current_popup_menu == NULL)
-	    {
-	      /* Free memory used by owner-drawn and help-echo strings.  */
-	      w32_free_menu_strings (hwnd);
-	      f->output_data.w32->menubar_active = 0;
-              menubar_in_use = 0;
-	    }
-	}
       else if (wParam == hourglass_timer)
 	{
 	  KillTimer (hwnd, hourglass_timer);
@@ -3465,14 +3444,11 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
     case WM_EXITMENULOOP:
       f = x_window_to_frame (dpyinfo, hwnd);
 
-      /* If a menu is still active, check again after a short delay,
-	 since Windows often (always?) sends the WM_EXITMENULOOP
-	 before the corresponding WM_COMMAND message.
-         Don't do this if a popup menu is active, since it is only
-         menubar menus that require cleaning up in this way.
-      */
       if (f && menubar_in_use && current_popup_menu == NULL)
-	menu_free_timer = SetTimer (hwnd, MENU_FREE_ID, MENU_FREE_DELAY, NULL);
+       {
+         f->output_data.w32->menubar_active = 0;
+         menubar_in_use = 0;
+       }
 
       /* If hourglass cursor should be displayed, display it now.  */
       if (f && f->output_data.w32->hourglass_p)
@@ -3632,15 +3608,6 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
       goto command;
     case WM_COMMAND:
       menubar_in_use = 0;
-      f = x_window_to_frame (dpyinfo, hwnd);
-      if (f && HIWORD (wParam) == 0)
-	{
-	  if (menu_free_timer)
-	    {
-	      KillTimer (hwnd, menu_free_timer);
-	      menu_free_timer = 0;
-	    }
-	}
     case WM_MOVE:
     case WM_SIZE:
     command:
@@ -3748,6 +3715,8 @@ w32_wnd_proc (HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam)
       if (LOWORD (lParam) == HTCLIENT)
 	{
 	  f = x_window_to_frame (dpyinfo, hwnd);
+	  if (!f)
+	    return 0;
 	  if (f->output_data.w32->hourglass_p && !menubar_in_use
 	      && !current_popup_menu)
 	    SetCursor (f->output_data.w32->hourglass_cursor);
diff --git a/src/w32menu.c b/src/w32menu.c
index ff6bd97..78d59fc 100644
--- a/src/w32menu.c
+++ b/src/w32menu.c
@@ -108,7 +108,7 @@ static Lisp_Object simple_dialog_show (FRAME_PTR, Lisp_Object, Lisp_Object);
 static void utf8to16 (unsigned char *, int, WCHAR *);
 static int fill_in_menu (HMENU, widget_value *);
 
-void w32_free_menu_strings (HWND);
+static void w32_free_menu_strings (HMENU);
 \f
 
 /* This is set nonzero after the user activates the menu bar, and set
@@ -347,8 +347,6 @@ menubar_selection_callback (FRAME_PTR f, void * client_data)
 	      buf.kind = MENU_BAR_EVENT;
 	      buf.frame_or_window = frame;
 	      buf.arg = entry;
-	      /* Free memory used by owner-drawn and help-echo strings.  */
-	      w32_free_menu_strings (FRAME_W32_WINDOW (f));
 	      kbd_buffer_store_event (&buf);
 
 	      f->output_data.w32->menubar_active = 0;
@@ -357,8 +355,6 @@ menubar_selection_callback (FRAME_PTR f, void * client_data)
 	  i += MENU_ITEMS_ITEM_LENGTH;
 	}
     }
-  /* Free memory used by owner-drawn and help-echo strings.  */
-  w32_free_menu_strings (FRAME_W32_WINDOW (f));
   f->output_data.w32->menubar_active = 0;
 }
 
@@ -588,6 +584,7 @@ set_frame_menubar (FRAME_PTR f, int first_time, int deep_p)
 
   if (menubar_widget)
     {
+      w32_free_menu_strings (menubar_widget);
       /* Empty current menubar, rather than creating a fresh one.  */
       while (DeleteMenu (menubar_widget, 0, MF_BYPOSITION))
 	;
@@ -643,6 +640,7 @@ free_frame_menubar (FRAME_PTR f)
     HMENU old = GetMenu (FRAME_W32_WINDOW (f));
     SetMenu (FRAME_W32_WINDOW (f), NULL);
     f->output_data.w32->menubar_widget = NULL;
+    w32_free_menu_strings (old);
     DestroyMenu (old);
   }
 
@@ -898,10 +896,11 @@ w32_menu_show (FRAME_PTR f, int x, int y, int for_click, int keymaps,
   /* Free the widget_value objects we used to specify the contents.  */
   free_menubar_widget_value_tree (first_wv);
 
+  /* Free the owner-drawn and help-echo menu strings.  */
+  w32_free_menu_strings (menu);
   DestroyMenu (menu);
+  current_popup_menu = NULL;
 
-  /* Free the owner-drawn and help-echo menu strings.  */
-  w32_free_menu_strings (FRAME_W32_WINDOW (f));
   f->output_data.w32->menubar_active = 0;
 
   /* Find the selected item, and its pane, to return
@@ -1651,9 +1650,11 @@ w32_menu_display_help (HWND owner, HMENU menu, UINT item, UINT flags)
 
 /* Free memory used by owner-drawn strings.  */
 static void
-w32_free_submenu_strings (HMENU menu)
+w32_free_menu_strings (HMENU menu)
 {
   int i, num = GetMenuItemCount (menu);
+  if (!get_menu_item_info)
+    return;
   for (i = 0; i < num; i++)
     {
       MENUITEMINFO info;
@@ -1674,29 +1675,10 @@ w32_free_submenu_strings (HMENU menu)
 
       /* Recurse down submenus.  */
       if (info.hSubMenu)
-	w32_free_submenu_strings (info.hSubMenu);
+	w32_free_menu_strings (info.hSubMenu);
     }
 }
 
-void
-w32_free_menu_strings (HWND hwnd)
-{
-  HMENU menu = current_popup_menu;
-
-  if (get_menu_item_info)
-    {
-      /* If there is no popup menu active, free the strings from the frame's
-	 menubar.  */
-      if (!menu)
-	menu = GetMenu (hwnd);
-
-      if (menu)
-	w32_free_submenu_strings (menu);
-    }
-
-  current_popup_menu = NULL;
-}
-
 #endif /* HAVE_MENUS */
 
 /* The following is used by delayed window autoselection.  */
diff --git a/src/w32term.c b/src/w32term.c
index 1f53860..0cef1b7 100644
--- a/src/w32term.c
+++ b/src/w32term.c
@@ -5734,11 +5734,11 @@ x_free_frame_resources (struct frame *f)
   if (FRAME_FACE_CACHE (f))
     free_frame_faces (f);
 
+  free_frame_menubar (f);
+
   if (FRAME_W32_WINDOW (f))
     my_destroy_window (f, FRAME_W32_WINDOW (f));
 
-  free_frame_menubar (f);
-
   unload_color (f, FRAME_FOREGROUND_PIXEL (f));
   unload_color (f, FRAME_BACKGROUND_PIXEL (f));
   unload_color (f, f->output_data.w32->cursor_pixel);

bug#7190: Crash in menus on w32

[Jason Rumney]

grischka <grishka@gmx.de> writes:

>      case WM_EXITMENULOOP:
>        f = x_window_to_frame (dpyinfo, hwnd);
>  
> -      /* If a menu is still active, check again after a short delay,
> -	 since Windows often (always?) sends the WM_EXITMENULOOP
> -	 before the corresponding WM_COMMAND message.
> -         Don't do this if a popup menu is active, since it is only
> -         menubar menus that require cleaning up in this way.
> -      */
>        if (f && menubar_in_use && current_popup_menu == NULL)
> -	menu_free_timer = SetTimer (hwnd, MENU_FREE_ID, MENU_FREE_DELAY, NULL);
> +       {
> +         f->output_data.w32->menubar_active = 0;
> +         menubar_in_use = 0;
> +       }

I don't see anything in your change to handle freeing of the menubar
structures in the case where the user clicks on the menubar then clicks
away without selecting anything.  The above code was to fix a memory and
resource leak in that case.

Jason

bug#7190: Crash in menus on w32

[grischka]

Jason Rumney wrote:
> I don't see anything in your change to handle freeing of the menubar
> structures in the case where the user clicks on the menubar then clicks
> away without selecting anything.  

This is correct.  The patch frees the item-string always when (and
in the same place where) the MENUITEM structure itself is destroyed.
Since this structure is the only place that has the pointer, it is
hence impossible by design to access the pointer after it was freed.

> The above code was to fix a memory and resource leak in that case.

With the patch, leaking these strings cannot happen by design also
provided the MENUITEMs themselves are destroyed correctly always which
is made sure by bugs 2/3 fixed:
>> 2) memory leak: was trying to free items from already deleted menu
>> 3) memory leak: was trying to free menu from already deleted window

--- grischka

bug#7190: Crash in menus on w32

[Jason Rumney]

grischka <grishka@gmx.de> writes:

>> The above code was to fix a memory and resource leak in that case.
>
> With the patch, leaking these strings cannot happen by design also
> provided the MENUITEMs themselves are destroyed correctly always which
> is made sure by bugs 2/3 fixed:
>>> 2) memory leak: was trying to free items from already deleted menu
>>> 3) memory leak: was trying to free menu from already deleted window

OK, I understand now - it seems you have fixed the underlying bug that
caused that memory leak to happen in the first place, so the timer
kludge is no longer neccesary.

bug#7190: Crash in menus on w32

[grischka]

Jason Rumney wrote:
> grischka <grishka@gmx.de> writes:
> 
>>> The above code was to fix a memory and resource leak in that case.
>> With the patch, leaking these strings cannot happen by design also
>> provided the MENUITEMs themselves are destroyed correctly always which
>> is made sure by bugs 2/3 fixed:
>>>> 2) memory leak: was trying to free items from already deleted menu
>>>> 3) memory leak: was trying to free menu from already deleted window
> 
> OK, I understand now - it seems you have fixed the underlying bug that
> caused that memory leak to happen in the first place, so the timer
> kludge is no longer neccesary.
> 

Just tried to be less clever.

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." -- Brian Kernighan

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Fri, Oct 22, 2010 at 6:20 PM, grischka <grishka@gmx.de> wrote:
>
> Just tried to be less clever.
>
> "Debugging is twice as hard as writing the code in the first place.
> Therefore, if you write the code as cleverly as possible, you are,
> by definition, not smart enough to debug it." -- Brian Kernighan

What is the status of this? I just got a crash using my patched Emacs
with sources as below.

This Emacs was built from sources in bazaar identified as:

Nick 'trunk' info:
  revision id: yamaoka@jpl.org-20101019081945-8auglqcd1ne2o0rb
        revno: 101998
         date: 2010-10-19 08:19:45 +0000

Nick 'emacsw32' (from 'trunk') info:
  revision id: lennart.borgman@gmail.com-20101019140903-0x7gubo4o0c9voai
        revno: 99341
         date: 2010-10-19 16:09:03 +0200

bug#7190: Crash in menus on w32

[grischka]

Lennart Borgman wrote:
> What is the status of this? I just got a crash using my patched Emacs
> with sources as below.

You're using the patch from above and still get the crash???

> 
> This Emacs was built from sources in bazaar identified as:
> 
> Nick 'trunk' info:
>   revision id: yamaoka@jpl.org-20101019081945-8auglqcd1ne2o0rb
>         revno: 101998
>          date: 2010-10-19 08:19:45 +0000
> 
> Nick 'emacsw32' (from 'trunk') info:
>   revision id: lennart.borgman@gmail.com-20101019140903-0x7gubo4o0c9voai
>         revno: 99341
>          date: 2010-10-19 16:09:03 +0200
> 

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Mon, Nov 8, 2010 at 11:15 AM, grischka <grishka@gmx.de> wrote:
> Lennart Borgman wrote:
>>
>> What is the status of this? I just got a crash using my patched Emacs
>> with sources as below.
>
> You're using the patch from above and still get the crash???
>
>>
>> This Emacs was built from sources in bazaar identified as:
>>
>> Nick 'trunk' info:
>>  revision id: yamaoka@jpl.org-20101019081945-8auglqcd1ne2o0rb
>>        revno: 101998
>>         date: 2010-10-19 08:19:45 +0000
>>
>> Nick 'emacsw32' (from 'trunk') info:
>>  revision id: lennart.borgman@gmail.com-20101019140903-0x7gubo4o0c9voai
>>        revno: 99341
>>         date: 2010-10-19 16:09:03 +0200


I do not know if I am using it, that is what I am asking ;-)

I have not applied it myself. Should it be in the checkout I have
made? (How do I see that?)

bug#7190: Crash in menus on w32

[grischka]

Lennart Borgman wrote:
> I do not know if I am using it, that is what I am asking ;-)
> 
> I have not applied it myself. Should it be in the checkout I have
> made? (How do I see that?)

To know that you're using the patch, apply it.

bug#7190: Crash in menus on w32

[Lennart Borgman]

On Mon, Nov 8, 2010 at 8:51 PM, grischka <grishka@gmx.de> wrote:
> Lennart Borgman wrote:
>>
>> I do not know if I am using it, that is what I am asking ;-)
>>
>> I have not applied it myself. Should it be in the checkout I have
>> made? (How do I see that?)
>
> To know that you're using the patch, apply it.

Has it been applied to the trunk yet?

bug#7190: Crash in menus on w32

[grischka]

Lennart Borgman wrote:
> On Mon, Nov 8, 2010 at 8:51 PM, grischka <grishka@gmx.de> wrote:
>> Lennart Borgman wrote:
>>> I do not know if I am using it, that is what I am asking ;-)
>>>
>>> I have not applied it myself. Should it be in the checkout I have
>>> made? (How do I see that?)
>> To know that you're using the patch, apply it.
> 
> Has it been applied to the trunk yet?
> 

Obviously, if you want that and don't have commit rights yourself
you need to find someone else who understands the patch and is willing
to commit it.

Also, before doing so it might make sense if you test the patch esp.
since you seem to be the only person who sees this bug due to your
personal setup (i.e. ownerdrawn items in the menu-bar menu).

Of course the patch is correct but there is no reason to believe me ;)

--- grischka

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> Date: Tue, 09 Nov 2010 17:16:46 +0100
> From: grischka <grishka@gmx.de>
> Cc: bug-gnu-emacs@gnu.org
> 
> Obviously, if you want that and don't have commit rights yourself
> you need to find someone else who understands the patch and is willing
> to commit it.

I think it's too large to be committed without your signing legal
papers.  And I don't see your name on file with the FSF copyright
assignments list.  If you want your patch to be installed, please
contact Stefan or Chong and ask them for instructions.  (They could
also decide that I'm wrong, and the patch can be treated as "tiny",
which doesn't need papers.)

TIA

bug#7190: Crash in menus on w32

[grischka]

Eli Zaretskii wrote:
>> Date: Tue, 09 Nov 2010 17:16:46 +0100
>> From: grischka <grishka@gmx.de>
>> Cc: bug-gnu-emacs@gnu.org
>>
>> Obviously, if you want that and don't have commit rights yourself
>> you need to find someone else who understands the patch and is willing
>> to commit it.
> 
> I think it's too large to be committed without your signing legal
> papers.  And I don't see your name on file with the FSF copyright
> assignments list.  If you want your patch to be installed, please
> contact Stefan or Chong and ask them for instructions.  (They could
> also decide that I'm wrong, and the patch can be treated as "tiny",
> which doesn't need papers.)

I will not assign my copyright to someone else however I do not claim
copyright for this patch.  Anyway it does not add one single new line.
(~50 lines removed, ~20 lines moved to other places.)

--- grischka

> 
> TIA
> 

bug#7190: Crash in menus on w32

[grischka]

Stefan Monnier wrote:
>> I will not assign my copyright to someone else however I do not claim
>> copyright for this patch.  Anyway it does not add one single new line.
>> (~50 lines removed, ~20 lines moved to other places.)
> 
> As you know, programming is not just writing the lines, but also putting
> them in the right order ;-).  

Then again even more programming effort is required to put lines in
wrong order ;).

> Your patch is much too non-trivial to be accepted as a "tiny change", 
> which means we need you to sign some paperwork before we can install it.
> 
> If you're willing to do that, then please fill the form below and email
> it as instructed so the FSF can send you the relevant paperwork to sign.
> Thank you very much for your help in improving Emacs,
> 

Well, thanks very much too for developing emacs.

Please understand that in order to preserve rsp. encourage symmetry and
transparency in the meta-code I give this patch to you as I give it to
anyone else who wants it, that is under the same terms and conditions
as I received your code and without any further agreements beyond those
terms with certain parties.

--- grischka

bug#7190: Crash in menus on w32

[Glenn Morris]

grischka wrote:

> I will not assign my copyright to someone else however I do not claim
> copyright for this patch.

Would you be willing to sign a copyright disclaimer to put this change
in the public domain?

(You seem to be saying that, but we need a signed piece of paper to
that effect to be able to use it.)

(It sounds like this may be being discussed off-list.)

bug#7190: Crash in menus on w32

[grischka]

Glenn Morris wrote:
> grischka wrote:
> 
>> I will not assign my copyright to someone else however I do not claim
>> copyright for this patch.
> 
> Would you be willing to sign a copyright disclaimer to put this change
> in the public domain?
> 
> (You seem to be saying that, but we need a signed piece of paper to
> that effect to be able to use it.)

Yes, I was saying that because to me there was no content with
copyright really.  If you say there is then I do not disclaim it.

Note that giving up my copyright (if any) would allow you to bypass
the GPL with the patch.  As it is based on code that I received
under GPL myself, this is not possible.

--- grischka

> 
> (It sounds like this may be being discussed off-list.)
> 

bug#7190: Crash in menus on w32

[Chong Yidong]

grischka <grishka@gmx.de> writes:

> Note that giving up my copyright (if any) would allow you to bypass
> the GPL with the patch.

No it doesn't.

bug#7190: Crash in menus on w32

[Glenn Morris]

So IIUC there is some kind of issue here, and someone wrote a patch.
However, they don't want to assign copyright for it (which is their
prerogative, of course). But given this, I don't see how any progress
can be made.

bug#7190: Crash in menus on w32

[Lennart Borgman]

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

My old suggestion was adding checks for all system calls. I started doing
that, but since those checks were not added to the core I found the merging
to difficult. I ran out of time and had to skip it.

I still suggest adding checks for all system calls. Maybe someone else have
time to catch the error now.


On Mon, Feb 18, 2013 at 3:23 AM, Glenn Morris <rgm@gnu.org> wrote:

>
> So IIUC there is some kind of issue here, and someone wrote a patch.
> However, they don't want to assign copyright for it (which is their
> prerogative, of course). But given this, I don't see how any progress
> can be made.
>
>
>
>

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

bug#7190: Crash in menus on w32

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Sun, 17 Feb 2013 21:23:44 -0500
> 
> 
> So IIUC there is some kind of issue here, and someone wrote a patch.
> However, they don't want to assign copyright for it (which is their
> prerogative, of course). But given this, I don't see how any progress
> can be made.

Please close.