Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: gdb-patches@sourceware.org
Subject: "Invalid parameter passed to C runtime function" from MinGW GDB
Date: Sun, 18 Nov 2018 16:46:00 -0000	[thread overview]
Message-ID: <838t1qtjty.fsf@gnu.org> (raw)

While debugging the issue with internal_error when stepping out of
'main', I noticed that GDB emits the above warning many times.  It
turns out the warning is triggered by this:

  common/filestuff.c:

  gdb_file_up
  gdb_fopen_cloexec (const char *filename, const char *opentype)
  {
    FILE *result;
    /* Probe for "e" support once.  But, if we can tell the operating
       system doesn't know about close on exec mode "e" without probing,
       skip it.  E.g., the Windows runtime issues an "Invalid parameter
       passed to C runtime function" OutputDebugString warning for
       unknown modes.  Assume that if O_CLOEXEC is zero, then "e" isn't
       supported.  */
    static int fopen_e_ever_failed_einval = O_CLOEXEC == 0;  <<<<<<<<<<<<

    if (!fopen_e_ever_failed_einval)
      {
	char *copy;

	copy = (char *) alloca (strlen (opentype) + 2);
	strcpy (copy, opentype);
	/* This is a glibc extension but we try it unconditionally on
	   this path.  */
	strcat (copy, "e");
	result = fopen (filename, copy);  <<<<<<<<<<<<<<<<<<

MinGW doesn't support the "e" mode.  As you see, we try to be smart
about that, but that trick no longer works, because Gnulib does this:

  build-gnulib/import/fcntl.h:

  #if !defined O_CLOEXEC && defined O_NOINHERIT
  /* Mingw spells it 'O_NOINHERIT'.  */
  # define O_CLOEXEC O_NOINHERIT
  #endif

and O_CLOEXEC is no longer zero.

I propose to fix this as below.  Any objections to committing this to
master (with a suitable ChangeLog, of course)? 

diff --git a/gdb/common/filestuff.c b/gdb/common/filestuff.c
index d4bd1a8..3fa035a 100644
--- a/gdb/common/filestuff.c
+++ b/gdb/common/filestuff.c
@@ -300,8 +300,10 @@ gdb_fopen_cloexec (const char *filename, const char *opentype)
      skip it.  E.g., the Windows runtime issues an "Invalid parameter
      passed to C runtime function" OutputDebugString warning for
      unknown modes.  Assume that if O_CLOEXEC is zero, then "e" isn't
-     supported.  */
-  static int fopen_e_ever_failed_einval = O_CLOEXEC == 0;
+     supported.  On MinGW, O_CLOEXEC is an alias of O_NOINHERIT, and
+     "e" isn't supported.  */
+  static int fopen_e_ever_failed_einval =
+    O_CLOEXEC == 0 || O_CLOEXEC == O_NOINHERIT;
 
   if (!fopen_e_ever_failed_einval)
     {


             reply	other threads:[~2018-11-18 16:46 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-18 16:46 Eli Zaretskii [this message]
2018-11-19 22:06 ` Tom Tromey
2018-11-20 16:52   ` Eli Zaretskii
2018-11-20 16:54   ` Eli Zaretskii

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=838t1qtjty.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=gdb-patches@sourceware.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox