From: Lennart Borgman <lennart.borgman@gmail.com>
To: Juanma Barranquero <lekktu@gmail.com>
Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
Subject: Re: System calls without error checks in w32
Date: Mon, 31 May 2010 00:37:26 +0200 [thread overview]
Message-ID: <AANLkTimZa6XsUR9ssry-CyA7SQ-30iKvT4pspIloO_Tt@mail.gmail.com> (raw)
In-Reply-To: <AANLkTintgr1mOZtJ6zsLA4sfX0OYeLa9CTq9rmQSKyeh@mail.gmail.com>
On Sun, May 30, 2010 at 9:24 PM, Juanma Barranquero <lekktu@gmail.com> wrote:
> On Sun, May 30, 2010 at 20:02, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>
>> My intention is to get a chance to know why a system call failed. That
>> is a way to find those errors that are a bit harder to find than those
>> you may see directly by inspecting the code.
>
> If you have DebPrint for every system call, and some of them return
> trivial errors, debugging will sometimes be harder just because of the
> noise.
Yes, my intention was not to add them everywhere, only on interesting places.
> I think you'll see that many system calls won't ever return an error
> (because the error conditions are pretty infrequent). Some of them
> will, for example system calls related to file manipulation (because
> of nonexistent or nonaccesible files, etc.); it would be interesting
> to know how many of those don't have already checking in place.
On a quick look I got the impression that file calls are better
handled than GUI system calls.
>> One example of this is when I see Emacs going totally weird. That
>> happens quite often and I am not sure what is happening. It might in
>> my cases be problems with edebug or it might be problems with the
>> system calls that makes the depends on resource exhaustion in the
>> black system box.
>
> Does that happen to you with your patched Emacs, or unpatched?
It happens to me with my patched Emacs because that is the one I am
using. I only use unpatched Emacs for bug testing etc.
> Because
> I see occasional crashes, but not nearly as frequently as it seems to
> happen to you (not by a loooong shot), and I have not seem "weird"
> behavior (unresponsive Emacs, looping, etc.) perhaps for years.
All I know is that some system resources seems to be exhausted. What I
directly can see without digging is that GDI are exhausted (these are
shown in Windows Task Manager). explorer.exe are owning a lot of them,
which I believe means it is system windows like menus that are badly
handled. However if Emacs is the culprit or windows itself I do not
know. (I am using sticky keys and I think it is related to that.)
>> To be able to fix it I need some kind of logging of
>> the system calls.
>
> Because you somehow assume that the trouble is likely related to bad
> system calls; most Emacs bugs aren't.
That is surely true, but I am not comfortable with how threads are
integrated (i.e. it is not visible enough IMO). I wonder if there are
any troubles there. Those threads of course communicate through system
calls.
I might have fixed some of the problems with related to frames which
calls crashes, but there might be more.
Menus are rather often broken. I can see that in my patched version
because menus are more easily accessed there. I surely
And I wonder why Emacs sometimes seems to hang temporarily when frame
related operations are going on. Is something going wrong?
And the inability to stop Emacs sometimes is quite disturbing. What is
going on there? Why does not the GUI thread get resources? Or is it
given resources but a block occur in some other way? Is GUI messages
not checked when looping?
>>> This is even worse, because it's impossible to understand what this
>>> does without looking up the magical W32DEBPRINT macro.
>>
>>
>> I think it has some advantages, actually. It is easy to see and
>> distinguish from the normal code. It can be a null op in non-debugging
>> compilations.
>
> IMHO is horribly ugly. If you're going to have error checks, better to
> have them on the clear.
So both you and Eli think that way is ugly. I am a bit surprised (but
I accept it of course). This type of entering the checks is very
similar to what `assert' does in Emacs. Does that mean you think
`assert' is very ugly too or is there some difference I am missing?
next prev parent reply other threads:[~2010-05-30 22:37 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-05-29 2:38 System calls without error checks in w32 Lennart Borgman
2010-05-29 17:43 ` Eli Zaretskii
2010-05-29 18:42 ` Lennart Borgman
2010-05-29 19:35 ` Eli Zaretskii
2010-05-29 20:02 ` Lennart Borgman
2010-05-29 21:25 ` Eli Zaretskii
2010-05-29 21:30 ` Lennart Borgman
2010-05-30 3:02 ` Eli Zaretskii
2010-05-30 3:26 ` Lennart Borgman
2010-05-30 17:36 ` Eli Zaretskii
2010-05-30 18:02 ` Lennart Borgman
2010-05-30 19:24 ` Juanma Barranquero
2010-05-30 22:37 ` Lennart Borgman [this message]
2010-05-30 23:03 ` Juanma Barranquero
2010-05-30 23:28 ` Lennart Borgman
2010-05-31 0:10 ` Juanma Barranquero
2010-05-31 0:58 ` Lennart Borgman
2010-05-31 2:02 ` Juanma Barranquero
2010-05-31 2:36 ` Lennart Borgman
2010-05-31 3:06 ` Juanma Barranquero
2010-05-31 3:05 ` Eli Zaretskii
-- strict thread matches above, loose matches on Subject: below --
2010-05-31 9:18 grischka
2010-06-05 17:15 ` Jason Rumney
2010-06-07 10:37 ` grischka
2010-06-07 14:54 ` Stephen J. Turnbull
2010-06-07 15:23 ` Lennart Borgman
2010-06-07 17:21 ` grischka
2010-06-07 17:30 ` Lennart Borgman
2010-06-07 18:54 ` grischka
2010-06-08 0:32 ` Lennart Borgman
2010-06-08 0:34 ` Lennart Borgman
2010-06-07 19:56 ` Stefan Monnier
2010-06-07 23:35 ` 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=AANLkTimZa6XsUR9ssry-CyA7SQ-30iKvT4pspIloO_Tt@mail.gmail.com \
--to=lennart.borgman@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=lekktu@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.