bug#6414: f->output_data.w32->menubar_widget uninitialized?

[Juanma Barranquero <lekktu@gmail.com>]

On Mon, Jul 4, 2011 at 01:42, Lennart Borgman <lennart.borgman@gmail.com> wrote:

> That there is (was) a bug in the menus is not hypothetical.

That you have stumbled upon some bugs in the menus I don't deny. But
this report was not about any bug report, just a system call return
value that did not cause any bug (or at least, such bug was not
reported).

> The reason
> I am seeing those bugs and not so many other people is probably that I
> am using the menus. (Since I do not use Alt as META I can use them
> more easily. And I do.)

Perhaps you're right, but I don't believe you're the only heavy user
of menus. And still there aren't many menu-related bug reports. That
does not mean that there are no bugs, of course; just that they aren't
very frequent.

> I think you misunderstand the logic here. The race condition shows up
> because of system messages. In your case you probably see much, much
> less of those since (I believe) you use menus much less often.

I can believe that the messages help in making a race condition more
visible, but it should still happen every now and then without them.

> As I have explained quite a few times the refusal to add things like
> error checking puts a lot of burden on me.

There's no refusal to add error checking. There has been, several
times, a refusal to indiscriminately put such tests in places where
they don't seem necessary. But if you point out places where a system
call is likely to return an error code that we should check, nobody is
going to say "no, don't check that".

> You might want to fix the core Emacs.

I think that's a bit too vague to be of any help.

> Now I am a bit lost. I thought I had done that change, but I have not.
> (Or it has been reverted by some merge, that happens.)

What change?

> However I see another small change that I have made to w32term.c that
> might have fixed some crashes (but this is unrelated to the problem we
> are discussing) :
>
> *** 4491,4497 ****
>
>          else
>
>            {
>
>              f = x_window_to_frame (dpyinfo, msg.msg.hwnd);
>
> !             f->async_visible = msg.msg.wParam;
>
>            }
>
>  #endif

This patch is against your patched version, and in the trunk sources
the equivalent code is

	  /* If window has been obscured or exposed by another window
	     being maximised or minimised/restored, then recheck
	     visibility of all frames.  Direct changes to our own
	     windows get handled by WM_SIZE.  */
#if 0
	  if (msg.msg.lParam != 0)
	    check_visibility = 1;
	  else
	    {
	      f = x_window_to_frame (dpyinfo, msg.msg.hwnd);
	      f->async_visible = msg.msg.wParam;
	    }
#endif

which is obviously not executed.

    Juanma