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

[Lennart Borgman]

On Mon, Jul 4, 2011 at 02:34, Juanma Barranquero <lekktu@gmail.com> wrote:
> 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).

This call was related to the menus.

>> 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 believe many of the heavy menu users might be using my patched
version (since this allows them to use the windows-key as META). That
might be the reason you do not see the bug reports.

>> 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.

Of course, but you just do not know it was a race condition. You have
no clue at all, since such a condition with a system call can give
very strange results. (I have seen such cases.)

>> 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".

I would say every system call. Why do you think some of them should be
excluded from error checking?

>> You might want to fix the core Emacs.
>
> I think that's a bit too vague to be of any help.

Hm. My mistake. ;-)

As I said I thought I had changed the code at that point I suggested,
in x_free_frame_resources. It was a simple change (and I still believe
it should be done).

>> 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?

That one in x_free_frame_resources (that I told about 2010-06-13).

>> 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.

:-)

I wonder why I cared to add that check then. Perhaps was it executed
before, I have no idea now.