tech@mandoc.bsd.lv
 help / color / mirror / Atom feed
* [PATCH] Fix "Wait: No Child Process"
@ 2015-03-02 10:55 Baptiste Daroussin
  2015-03-02 14:56 ` Ingo Schwarze
  0 siblings, 1 reply; 4+ messages in thread
From: Baptiste Daroussin @ 2015-03-02 10:55 UTC (permalink / raw)
  To: tech


[-- Attachment #1.1: Type: text/plain, Size: 130 bytes --]

Hi,

Here is a small patch to fix mandoc complaining about no child process when .gz
manpages are being read.

Best regards,
Bapt

[-- Attachment #1.2: read.c.diff --]
[-- Type: text/x-diff, Size: 421 bytes --]

Index: read.c
===================================================================
RCS file: /cvs/mdocml/read.c,v
retrieving revision 1.128
diff -u -r1.128 read.c
--- read.c	23 Feb 2015 13:31:04 -0000	1.128
+++ read.c	2 Mar 2015 10:50:12 -0000
@@ -878,6 +878,7 @@
 		    "gunzip failed with code %d", WEXITSTATUS(status));
 		return(MANDOCLEVEL_ERROR);
 	}
+	curp->child = 0;
 	return(MANDOCLEVEL_OK);
 }
 

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Fix "Wait: No Child Process"
  2015-03-02 10:55 [PATCH] Fix "Wait: No Child Process" Baptiste Daroussin
@ 2015-03-02 14:56 ` Ingo Schwarze
  2015-03-09 21:04   ` Kristaps Dzonsons
  0 siblings, 1 reply; 4+ messages in thread
From: Ingo Schwarze @ 2015-03-02 14:56 UTC (permalink / raw)
  To: Baptiste Daroussin; +Cc: tech

Hi Baptiste,

Baptiste Daroussin wrote on Mon, Mar 02, 2015 at 11:55:19AM +0100:

> Here is a small patch to fix mandoc complaining about no child process
> when .gz manpages are being read.

Good catch, thanks for reporting!

I committed a tweaked version of the patch such that it also works
correctly if gunzip fails or is killed by a signal.

Yours,
  Ingo


> Index: read.c
> ===================================================================
> RCS file: /cvs/mdocml/read.c,v
> retrieving revision 1.128
> diff -u -r1.128 read.c
> --- read.c	23 Feb 2015 13:31:04 -0000	1.128
> +++ read.c	2 Mar 2015 10:50:12 -0000
> @@ -878,6 +878,7 @@
>  		    "gunzip failed with code %d", WEXITSTATUS(status));
>  		return(MANDOCLEVEL_ERROR);
>  	}
> +	curp->child = 0;
>  	return(MANDOCLEVEL_OK);
>  }
>  


Log Message:
-----------
If a non-gz manual is read after a gzipped manual, refrain 
from throwing a bogus error "wait: No child processes".
As reported by Baptiste Daroussin <bapt at FreeBSD dot org>, 
clearing the state variable curp->child after use was forgotten.

Modified Files:
--------------
    mdocml:
        read.c

Revision Data
-------------
Index: read.c
===================================================================
RCS file: /home/cvs/mdocml/mdocml/read.c,v
retrieving revision 1.128
retrieving revision 1.129
diff -Lread.c -Lread.c -u -p -r1.128 -r1.129
--- read.c
+++ read.c
@@ -868,6 +868,7 @@ mparse_wait(struct mparse *curp)
 		perror("wait");
 		exit((int)MANDOCLEVEL_SYSERR);
 	}
+	curp->child = 0;
 	if (WIFSIGNALED(status)) {
 		mandoc_vmsg(MANDOCERR_FILE, curp, 0, 0,
 		    "gunzip died from signal %d", WTERMSIG(status));
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Fix "Wait: No Child Process"
  2015-03-02 14:56 ` Ingo Schwarze
@ 2015-03-09 21:04   ` Kristaps Dzonsons
  2015-03-10  3:23     ` Ingo Schwarze
  0 siblings, 1 reply; 4+ messages in thread
From: Kristaps Dzonsons @ 2015-03-09 21:04 UTC (permalink / raw)
  To: tech, Baptiste Daroussin

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I'm still getting this error on Mac OS X, only for gzip'd files when
invoked as man(1).  Invoking directly as mandoc(1) does not cause the
issue.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJU/gr6AAoJEMT2SUY9XBESQJoP/jQphUQGQ6wySRb8eoPzWmT5
KY+6wjjbyQ6RWFmAAeWwd2PdWEPHR7kCP0AxaraCHgANx5M+BkqAkYDRyPRtpB2l
v8yZuvI5aJp4DGyxX02IuNJ5NevEw06hx1rHiuvi7fttXy9PRseBw8yYYtamR8/B
WMGevGkz/VIaRQapNbZgnTHVgaDNpjTkxu5WhiEifLTZOqk1nqpL8wCAXn43/Ris
IvYRYbRinZOkSWPPMpuQKd5VfVxM9T/qCsmjJAhoRJxSXdAcLxNt9n/mDRdMFfvZ
OJu4qUzfPXGHGQ6+Fu0eN2sIB7+jiRe0+5d0xEg/J1l+V2fkYnBkoBMfmsuMNDEV
VGZ2XwGu3VmFrr4JFKPWT0ItywzLFYITLv6l32QhK6GC2DxB2Sjnl7XjtitEuXsv
Yb8t+JLjj04IxpB81bK0CP1fYRdny2W9F2XCBnEVHHNwSgDOL58J6D/rghSGNI1y
oXIWXxbVtmbT9HtA/EJNo7tBPWDD2TbmYUPVS4uGieKN9yonJcD/Pc3u61OJqwd8
QYp0KGbBCeN7sO5am4SbvHmAz7ZLAOhHljdOw9j+cLvUOGU7i5XJkjE//K1yMu4C
qEPXfDPiH1qvmLlmlQVpyJ3EbgcYlXhvbzhF4KhLwdoyF16zVe5PqFMiPuPoi5ec
FxJlnsI8sGj9+S9NKpb2
=R2MF
-----END PGP SIGNATURE-----
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Fix "Wait: No Child Process"
  2015-03-09 21:04   ` Kristaps Dzonsons
@ 2015-03-10  3:23     ` Ingo Schwarze
  0 siblings, 0 replies; 4+ messages in thread
From: Ingo Schwarze @ 2015-03-10  3:23 UTC (permalink / raw)
  To: tech

Hi Kristaps,

Kristaps Dzonsons wrote on Mon, Mar 09, 2015 at 10:04:58PM +0100:

> I'm still getting this error on Mac OS X, only for gzip'd files
> when invoked as man(1).  Invoking directly as mandoc(1) does not
> cause the issue.

Gah, there was indeed a second issue causing this symptom, unrelated
to the one reported by bapt@.  It was introduced as a side effect of
main.c rev. 1.212 ("do not spawn a pager when there is no output").

Fixed now...

Thanks for reporting,
  Ingo


Log Message:
-----------
Fix a regression caused in rev. 1.212, reported by kristaps@:

When using a pager and the first manual shown is gzip'ed,
the gunzip(1) process ended up as a child of the pager process
such that the man(1) process couldn't wait for it, preventing
proper display of the manual.

Solve this by making the pager a child of the man(1) process
(instead of the other way round), which requires being a bit
more careful about properly closing file descriptors after use
and waiting for the pager before exiting man(1).

Modified Files:
--------------
    mdocml:
        main.c

Revision Data
-------------
Index: main.c
===================================================================
RCS file: /home/cvs/mdocml/mdocml/main.c,v
retrieving revision 1.223
retrieving revision 1.224
diff -Lmain.c -Lmain.c -u -p -r1.223 -r1.224
--- main.c
+++ main.c
@@ -20,6 +20,7 @@
 
 #include <sys/types.h>
 #include <sys/param.h>	/* MACHINE */
+#include <sys/wait.h>
 
 #include <assert.h>
 #include <ctype.h>
@@ -481,6 +482,21 @@ out:
 
 	free(defos);
 
+	/*
+	 * Flush the output and signal end of file.
+	 * If a pager is attached, it allows browsing to the end.
+	 * Otherwise, it does no harm, we are about to exit anyway.
+	 */
+
+	fclose(stdout);
+
+	/*
+	 * If we spawned a pager, wait for the user to close it.
+	 * Otherwise, this call fails with no adverse effect.
+	 */
+
+	wait(NULL);
+
 	return((int)rc);
 }
 
@@ -951,18 +967,19 @@ spawn_pager(void)
 		    progname, strerror(errno));
 		exit((int)MANDOCLEVEL_SYSERR);
 	case 0:
+		break;
+	default:
 		close(fildes[0]);
 		if (dup2(fildes[1], STDOUT_FILENO) == -1) {
 			fprintf(stderr, "%s: dup output: %s\n",
 			    progname, strerror(errno));
 			exit((int)MANDOCLEVEL_SYSERR);
 		}
+		close(fildes[1]);
 		return;
-	default:
-		break;
 	}
 
-	/* The original process becomes the pager. */
+	/* The child process becomes the pager. */
 
 	close(fildes[1]);
 	if (dup2(fildes[0], STDIN_FILENO) == -1) {
@@ -970,6 +987,7 @@ spawn_pager(void)
 		    progname, strerror(errno));
 		exit((int)MANDOCLEVEL_SYSERR);
 	}
+	close(fildes[0]);
 
 	pager = getenv("MANPAGER");
 	if (pager == NULL || *pager == '\0')
--
 To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2015-03-10  3:23 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-03-02 10:55 [PATCH] Fix "Wait: No Child Process" Baptiste Daroussin
2015-03-02 14:56 ` Ingo Schwarze
2015-03-09 21:04   ` Kristaps Dzonsons
2015-03-10  3:23     ` Ingo Schwarze

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 NNTP newsgroup(s).