Re: System calls without error checks in w32

[Lennart Borgman <lennart.borgman@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?