From: Juanma Barranquero <lekktu@gmail.com>
To: Lennart Borgman <lennart.borgman@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 04:02:55 +0200 [thread overview]
Message-ID: <AANLkTikU8rrGgne3snlDlW68exZwrbFkkDGNS8CALR_D@mail.gmail.com> (raw)
In-Reply-To: <AANLkTilZjww4ThFzZCfHnyitzvDSLX96vu2JTU2b2YOK@mail.gmail.com>
On Mon, May 31, 2010 at 02:58, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> I don't think so. It is just much more difficult to track some of
> these. For example I know Drew recently wrote about problems when
> creating new frames. It is quite hard to both understand what is
> happening and what is a bug and what is not.
Well, I'd say that should be the first step...
> I just mean that the normal C code (i.e. not related to system calls)
> seems better checked on w32.
Not sure what do you mean with "better checked". Obviously it is
easier to know what one of our own C functions is doing that what a
Windows system call does, so it's less likely that a return code from
a C function is ignored.
> Maybe you are missing my point. The system tries to stay stable. There
> are timing issues etc.
Maybe. Sometimes it seems like you assume your interlocutor knows it
all about the bugs you encounter; I tend to find your descriptions
vague and hard to follow (not necessarily your fault, of course).
> When I entered this list I went into a long discussion about the
> problems with printing on the w32 side. I actually felt I wasted a lot
> of time when I told that the code was in error. Since then I have
> thought it is less waste of time to keep the patches in my patched
> version. Now and then I ask if things have changed. If they have not I
> just skip it, but with some regret about the extra trouble and lost
> work.
I see no practical difference between my take of the situation
(regarding your patches) and yours.
> I have done that many times (or sent reports to the list before) but
> these kind of errors are not easy to track down. And since I have some
> patches (that correct some bugs, but also makes other bugs more
> visible) they tend to be dismissed.
I don't think so. They aren't dismissed because of your patches, but
because they are (at least, some that I've followed) very hard to
reproduce in standard Emacs.
> It seems much more trouble reporting the problems than fixing them.
> Maybe I should try to make a "system calls fix branch" from savannah
> and pick them one by one when I have time.
Perhaps it'd be a good idea.
> I have an example where I create a frame contact a web page in
> pause.el. Is that specific enough? (You have to run my patched code to
> see it since I can't do the frame manipulation I need without that.)
Then, why are you sure the problem isn't in your code? Surely if it is
a bug in Emacs there will be a way to show it with the trunk code?
> No ;-)
Hmm... allow me to disagree ;-)
> I don't think so. You should most often not crash Emacs because of bad
> system call return status. You should take a relevant action.
That's explicit in my comment. If you can take relevant action, do it
(not DebPrint, but a really relevant action). If you cannot, and the
bug is real, then abort.
> Of course, but you may be interested in information about what happened too.
While debugging. Not as a general principle. I don't want to run Emacs
under GDB for a totally unrelated reason and have a lot of noise. I
want that "noise", if it is relevant, to be acted upon. So, instead of
just adding lots of DebPrints, it would be more sensible to add them
locally for debugging, find what's happening (surely if you have so
many troubles, the error output will be abundant) and either fix it or
file a bug report for it.
> And the changes that allows better menu handling are also a bit
> scaring when merging. They are still only in my code.
Perhaps the latter is consequence of the former.
Juanma
next prev parent reply other threads:[~2010-05-31 2:02 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
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 [this message]
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
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=AANLkTikU8rrGgne3snlDlW68exZwrbFkkDGNS8CALR_D@mail.gmail.com \
--to=lekktu@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@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).