From: Juanma Barranquero <lekktu@gmail.com>
To: Lennart Borgman <lennart.borgman@gmail.com>
Cc: 6414@debbugs.gnu.org
Subject: bug#6414: f->output_data.w32->menubar_widget uninitialized?
Date: Mon, 4 Jul 2011 02:34:00 +0200 [thread overview]
Message-ID: <CAAeL0ST0xOZ-TK--+buScLDZJ0rsJ-LpmZ7kCmgyTCzHewVO4A@mail.gmail.com> (raw)
In-Reply-To: <CANbX367XCCDTu0v8=SgMUOPtcJFoKE+XLEyQMCW_Tx0s2fsCQA@mail.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
next prev parent reply other threads:[~2011-07-04 0:34 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-13 18:01 bug#6414: f->output_data.w32->menubar_widget uninitialized? Lennart Borgman
2010-06-13 18:32 ` Lennart Borgman
2010-06-13 18:47 ` Lennart Borgman
2011-07-03 18:54 ` Juanma Barranquero
2011-07-03 22:19 ` Lennart Borgman
2011-07-03 22:30 ` Juanma Barranquero
2011-07-03 22:37 ` Lennart Borgman
2011-07-03 22:48 ` Juanma Barranquero
2011-07-03 23:11 ` Lennart Borgman
2011-07-03 23:21 ` Juanma Barranquero
2011-07-03 23:42 ` Lennart Borgman
2011-07-04 0:34 ` Juanma Barranquero [this message]
2011-07-04 1:08 ` Lennart Borgman
2011-07-04 1:21 ` Juanma Barranquero
2011-07-04 1:44 ` Lennart Borgman
2011-07-04 2:13 ` Juanma Barranquero
2011-07-04 2:18 ` Lennart Borgman
2011-07-04 2:35 ` Juanma Barranquero
2011-09-21 20:32 ` Lars Magne Ingebrigtsen
2011-09-21 20:40 ` Lennart Borgman
2011-09-21 20:44 ` Juanma Barranquero
2011-09-21 20:46 ` Lennart Borgman
2011-09-21 20:59 ` Lars Magne Ingebrigtsen
2011-09-21 21:07 ` Lennart Borgman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAAeL0ST0xOZ-TK--+buScLDZJ0rsJ-LpmZ7kCmgyTCzHewVO4A@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=6414@debbugs.gnu.org \
--cc=lennart.borgman@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).