From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: System calls without error checks in w32 Date: Mon, 31 May 2010 00:37:26 +0200 Message-ID: References: <83ocfytxhg.fsf@gnu.org> <83mxvitsay.fsf@gnu.org> <83ljb2tn6i.fsf@gnu.org> <83k4qmt7lb.fsf@gnu.org> <83hblpthpt.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: dough.gmane.org 1275260543 26159 80.91.229.12 (30 May 2010 23:02:23 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sun, 30 May 2010 23:02:23 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Juanma Barranquero Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon May 31 01:02:22 2010 connect(): No such file or directory Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OIrWQ-0000lg-25 for ged-emacs-devel@m.gmane.org; Mon, 31 May 2010 01:02:22 +0200 Original-Received: from localhost ([127.0.0.1]:57075 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIrC8-00056K-Bp for ged-emacs-devel@m.gmane.org; Sun, 30 May 2010 18:41:24 -0400 Original-Received: from [140.186.70.92] (port=46859 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OIrBi-0004qy-T9 for emacs-devel@gnu.org; Sun, 30 May 2010 18:41:17 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OIr8c-0000SA-RT for emacs-devel@gnu.org; Sun, 30 May 2010 18:37:47 -0400 Original-Received: from mail-gw0-f41.google.com ([74.125.83.41]:43758) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OIr8c-0000S5-OF; Sun, 30 May 2010 18:37:46 -0400 Original-Received: by gwb19 with SMTP id 19so2920756gwb.0 for ; Sun, 30 May 2010 15:37:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=HNnY5xEiWL7Atr0wfSmrvRapPDsm4VvX9H1tnkXzPX8=; b=aBi65hJhLDb9ussbzlp9jdzQQnNVRhGzpbj700eDxJfEh7afoj9vJD0yO4J+M2YPCu eu9NxB/ugDxdoBd6SYVO2W+BBAZQnBIVMLYSAIiAwbJnKtyrc2Y9oL39h5og0KcwueQx Xlp3gBP74fjQ3aiaueCUDeyDy9FL/yTkied1s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=lnz+Le0BF4CR/a4BB+rxsut5y3AwziljXcQ4sKXeEpDIL2+KLEWpkXXhMd35Ywg3Hr gKwQfjisqjFM2VEajb02ClE0s9ZBxv2BR7BBIJob+4BIxEFcHKQatMg7TFl9YzJObGWJ 5y5XptICaP09/qcD4yS+JigFVp8iPePND+9dU= Original-Received: by 10.100.245.4 with SMTP id s4mr3887933anh.224.1275259066134; Sun, 30 May 2010 15:37:46 -0700 (PDT) Original-Received: by 10.100.44.20 with HTTP; Sun, 30 May 2010 15:37:26 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:125374 Archived-At: On Sun, May 30, 2010 at 9:24 PM, Juanma Barranquero wrote: > On Sun, May 30, 2010 at 20:02, Lennart Borgman > 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?