Mail Archives: cygwin/2006/05/26/17:34:15
cgf wrote:
> >0022FF88 61005EB3 (00000000, 00000000, 00000000, 00000000)
>
> That's apparently a call to mktemp, although I can't tell what's causing
> the problem.
Well, looking at the source to the cygwin distribution of texinfo, it is
pretty obvious:
$ diff -u texindex.c.orig texindex.c
--- texindex.c.orig 2004-04-11 11:56:47.001000000 -0600
+++ texindex.c 2005-10-07 08:43:50.001000000 -0600
@@ -99,6 +99,9 @@
/* Directory to use for temporary files. On Unix, it ends with a slash. */
char *tempdir;
+/* Basename for temp files inside of tempdir. */
+char *tempbase;
+
/* Number of last temporary file. */
int tempcount;
@@ -190,6 +193,11 @@
decode_command (argc, argv);
+ /* XXX mkstemp not appropriate, as we need to have somewhat predictable
+ * names. But race condition was fixed, see maketempname.
+ */
+ tempbase = mktemp ("txidxXXXXXX");
+
...
OOPS!!!! The texinfo maintainer, in their modifications to upstream texindex,
is passing a READ-ONLY string to mktemp, and is deserving of their crash
(although cygwin could perhaps handle it more gracefully, perhaps by returning
NULL on a fault so that at least the stack trace is not in the middle of
cygwin1.dll). But if you are going to go to the effort of modifications, use
mkstemp instead (mktemp is insecure, after all). I would further argue that
maketempname should use the O_BINARY flag to open(), unless texindex can handle
text mounts gracefully. Can we get a new texinfo release soon with this fixed?
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -