GNU bug report logs -
#6414
f->output_data.w32->menubar_widget uninitialized?
Previous Next
Full log
Message #38 received at 6414 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 4, 2011 at 01:42, Lennart Borgman <lennart.borgman <at> 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
This bug report was last modified 13 years and 250 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.