GNU bug report logs -
#6414
f->output_data.w32->menubar_widget uninitialized?
Previous Next
Full log
View this message in rfc822 format
On Mon, Jul 4, 2011 at 02:34, Juanma Barranquero <lekktu <at> gmail.com> wrote:
> 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).
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.
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.