bugfindutils - Bugs: bug #49466, xargs with 2>&1 returns...


bug #49466: xargs with 2>&1 returns error code in macOS 10.12

Submitter:  None
Submitted:  Fri 28 Oct 2016 08:19:31 AM UTC
Category:  xargs Severity:  3 - Normal
Item Group:  Wrong result Status:  Platform Issue
Privacy:  Public Assigned to:  jay
Originator Name:  Originator Email:  -email is unavailable-
Open/Closed:  Open Release:  4.6.0
Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup

Jump to the original submission

Sun 23 Jul 2017 11:54:03 PM UTC, comment #6: 

This issue appears to be fixed: it no longer reproduces for me with macOS 10.12.6.  I suspect it was caused by the same underlying behavior change to poll described here: https://github.com/curl/curl/issues/1057 (fixed in 10.12.2).

Michael Cahill <michaelcahill>
Sun 23 Jul 2017 09:28:15 PM UTC, comment #5: 

Could you provide a system call trace?

James Youngman <jay>
Group administrator
Tue 07 Feb 2017 03:21:03 AM UTC, comment #4: 

This only appears on MaxOS 10.12.

Tue 22 Nov 2016 01:00:52 PM UTC, comment #3: 

I could not reproduce this problem with findutils-4.6.0 freshly-built with LLVM 6.1.0 on Mac OS X 10.11.6.   Therefore, the system call trace output Bernhard mentions is our best next step for understanding what is happening.

AIUI the relevant tool on Mac OS X is "trace -E" rather than "strace" but I'm not familiar with it.   Another good option is to investigate with a debugger.

James Youngman <jay>
Group administrator
Tue 22 Nov 2016 03:51:55 AM UTC, comment #2: 

I'm seeing the same thing, here is the stack trace as reported by Apple's crash reporter:

3   libsystem_c.dylib                     0x00007fffc9447893 __assert_rtn + 320
4   xargs                                 0x0000000100e02e9f complain_about_leaky_fds + 145
5   xargs                                 0x0000000100e014f3 xargs_do_exec + 532
6   xargs                                 0x0000000100e024f5 bc_do_exec + 248
7   xargs                                 0x0000000100e00c7d main + 3117

This change avoids the crash by not checking the file descriptors for stdin, stdout or stderr, but tbh I can't follow all of what's going on in there:

diff -ur findutils-4.6.0/lib/fdleak.c findutils-4.6.0.patched/lib/fdleak.c
--- findutils-4.6.0/lib/fdleak.c        2015-12-29 08:10:23.000000000 +1100
+++ findutils-4.6.0.patched/lib/fdleak.c        2016-11-22 14:47:29.000000000 +1100
@@ -294,7 +294,7 @@
   context.used = n;
   context.lookup_pos = 0;
   context.leaked_fd = -1;
-  visit_open_fds (0, max_fd, find_first_leak_callback, &context);
+  visit_open_fds (3, max_fd, find_first_leak_callback, &context);
   return context.leaked_fd;

I hope that helps,

Michael Cahill <michaelcahill>
Fri 28 Oct 2016 02:16:08 PM UTC, comment #1: 

I don't see any reason for xargs to fail here; it doesn't even
see the "2>&1" redirection as the shell is evaluating this.
In effect, this should be identical to

  echo a | /usr/local/bin/xargs > /dev/null 2> /dev/null

So the reason could be a bug in your shell, or the file /dev/null
(which is usually a special character device to discard any input,
or still xargs.  You could run xargs under investigation of a tool
like 'strace' (which I don't know whether it is available on MacOS)
to see a bit more what happens:

  echo a | strace -o xargs.trace /usr/bin/xargs > /dev/null 2>&1 ; echo $?

The output in 'xargs.trace' would be quite interesting.

Thanks & have a nice day,

Bernhard Voelker <berny>
Group administrator
Fri 28 Oct 2016 08:19:31 AM UTC, original submission:  

[sunrunaway:~]$ echo a | /usr/bin/xargs > /dev/null 2>&1 ; echo $?
[sunrunaway:~]$ echo a | /usr/local/bin/xargs > /dev/null 2>&1 ; echo $?



(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #38827:  QQ20161028-0.png added by None (267KiB - image/png)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by jay (Posted a comment)
  • -email is unavailable- added by michaelcahill (Posted a comment)
  • -email is unavailable- added by berny (Posted a comment)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2019-09-01 jay StatusInvalid Platform Issue
    2019-09-01 jay StatusNone Invalid
        Assigned toNone jay
    2016-10-28 None Attached File- Added QQ20161028-0.png, #38827

    Back to the top

    Powered by Savane 3.13-b921.
    Corresponding source code