Bear causes unxz to fail when unpacking a .tar.xz

[moyix]

Describe the bug

For reasons I can't quite figure out, bear causes tar (or more specifically, the unxz process it launches) to fail when unpacking the following .tar.xz file: https://moyix.net/~moyix/qemu_6.2+dfsg.orig.tar.xz

To Reproduce

With the latest bear from git:

moyix@isabella:/fastdata$ tar tf qemu_6.2+dfsg.orig.tar.xz > /dev/null # Succeeds
moyix@isabella:/fastdata$ bear -- tar tf qemu_6.2+dfsg.orig.tar.xz > /dev/null # Fails
tar: Child returned status 1
tar: Error is not recoverable: exiting now

Expected behavior

The tar command should run successfully under bear.

Environment:

• OS name: Linux
• OS version: Ubuntu 20.04
• OS architecture: x86_64
• Bear version: bear 3.0.19
• Bear install method: tested both building source and using the packages in debian unstable (bear 3.0.18)

Additional context

• Can you give us a reference to the project that you are running against this tool? This command fails as part of using bear to wrap apt-get -b source qemu on debian unstable.
• What build tools this project is using? QEMU uses meson, but the package build fails before it starts trying to build QEMU itself.
• What architecture you are trying to compile for? x86_64 (no cross compile)
• Could you attach build logs? Attached: bear_untar.log

Before you send...

• Have you read the README.md file or man bear? Yes
• Have you looked what other open issues Bear has? Yes
• Are you sure that the build works without Bear? Yes

[moyix]

Note that the (somewhat ancient) version of bear in Ubuntu 20.04 does work fine here:

moyix@isabella:/fastdata$ bear --version
bear 2.4.3
moyix@isabella:/fastdata$ bear tar tf qemu_6.2+dfsg.orig.tar.xz > /dev/null # Succeeds
moyix@isabella:/fastdata$

[rizsotto]

Thanks @moyix , this is a good catch!

The new version of Bear is spawning a supervisor process for each process execution. The old version was just record the execution attempt and executed the requested process. The new approach allow us to capture the exit codes, or emit other metrics about the execution... But it probably has a bug about the standard input/output redirection.

I've run a few tests now, with bzip2 it works just fine. Will need some time to find fix for this bug. :smile: