After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 781312 - Fix 'Bad file descriptor' error when checking libtool version
Fix 'Bad file descriptor' error when checking libtool version
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: g-ir-scanner
2.43.x
Other Linux
: Normal minor
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2017-04-14 12:12 UTC by Sam Thursfield
Modified: 2017-06-15 08:05 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Fix (1.20 KB, patch)
2017-04-14 12:12 UTC, Sam Thursfield
none Details | Review
Fix v2 (1.06 KB, patch)
2017-04-14 19:31 UTC, Sam Thursfield
committed Details | Review
giscanner/utils.py: Fix on non-UNIX-like platforms (1.24 KB, patch)
2017-06-15 01:08 UTC, Fan, Chun-wei
committed Details | Review

Description Sam Thursfield 2017-04-14 12:12:00 UTC
Created attachment 349865 [details] [review]
Fix

Running g-ir-scanner on Fedora 25 (libtool 2.4.6) produces the following
message on stderr, twice:

    /usr/bin/libtool: line 2460: printf: write error: Bad file descriptor

The error is harmless as we are just checking if libtool is present, but
it is misleading for g-ir-scanner to show such an error.

Giving libtool a valid stdout fixes the issue. We could instead redirect
stderr to /dev/null but this risks hiding a useful error message.
Comment 1 Colin Walters 2017-04-14 13:37:36 UTC
Review of attachment 349865 [details] [review]:

::: giscanner/utils.py
@@ +160,3 @@
     try:
         subprocess.check_call([libtool_cmd, '--version'],
+                              stdout=subprocess.PIPE)

Isn't the right fix here to do:

stdout=open(os.devnull, 'w')

?

The problem with doing a pipe is if we're not reading from it,
it can result in deadlock.
Comment 2 Sam Thursfield 2017-04-14 19:31:40 UTC
Created attachment 349877 [details] [review]
Fix v2

Thanks for the review. That's a very good point! Opening /dev/null for writing also fixes the issue and doesn't risk deadlocks if there's lots of output.
Comment 3 Colin Walters 2017-04-14 19:35:02 UTC
Review of attachment 349877 [details] [review]:

LGTM.
Comment 4 Fan, Chun-wei 2017-06-15 01:01:37 UTC
Hi,

Unfortunately this broke the build of .gir files on Windows on non-MSYS as the notion of /dev/null does not exist there.  We still need to use os.devnull, and open it as writable.

With blessings, thank you!
Comment 5 Fan, Chun-wei 2017-06-15 01:08:57 UTC
Created attachment 353782 [details] [review]
giscanner/utils.py: Fix on non-UNIX-like platforms

Hi,

Here's the patch to use os.devnull rather than /dev/null.

With blessings, thank you!
Comment 6 Colin Walters 2017-06-15 01:53:07 UTC
Review of attachment 353782 [details] [review]:

This is triggering a vague memory about `os.devnull` maybe not being available on old Python, but I doubt we care.

So LGTM.
Comment 7 Fan, Chun-wei 2017-06-15 08:05:11 UTC
Review of attachment 353782 [details] [review]:

Hi Colin,

Thanks!  I pushed the patch as e8f39a0.

With blessings, thank you!