chromium-92.0.4515.159/buildtools/freebsd/clang-format and python bytes/bytarray vs. str failures in poudriere-devel based builds

From: Mark Millard via freebsd-chromium <freebsd-chromium_at_freebsd.org>
Date: Mon, 04 Oct 2021 08:02:32 UTC
When I try to build www/chromium via poudriere-devel
I get errors of the form:

Traceback (most recent call last):
  File "/wrkdirs/usr/ports/www/chromium/work/chromium-92.0.4515.159/buildtools/freebsd/clang-format", line 34, in <module>
    stdout, stderr = proc.communicate(input=contents)
  File "/usr/local/lib/python3.8/subprocess.py", line 1028, in communicate
    stdout, stderr = self._communicate(input, endtime, timeout)
  File "/usr/local/lib/python3.8/subprocess.py", line 1848, in _communicate
    input_view = memoryview(self._input)

When I look at:

/wrkdirs/usr/ports/www/chromium/work/chromium-92.0.4515.159/buildtools/freebsd/clang-format

I see (in part):

. . .
contents = ''
if '-' in args or not inputfiles:
   contents = sys.stdin.read()
. . .
   proc = subprocess.Popen(
       ['clang-format'] + args,
       stdin=subprocess.PIPE,
       stdout=subprocess.PIPE,
       stderr=subprocess.PIPE,
       env=env)
   stdout, stderr = proc.communicate(input=contents)
. . .

Which looks to me to be passing a str, not a bytes nor a bytearray
nor a None.

Also Popen.stdin is documented with:

QUOTE
Popen.stdin
If the stdin argument was PIPE, this attribute is a writeable stream object
as returned by open(). If the encoding or errors arguments were specified
or the universal_newlines argument was True, the stream is a text stream,
otherwise it is a byte stream. If the stdin argument was not PIPE, this
attribute is None.
END QUOTE

So, if I gather correctly, stdin ends up being a byte stream acording
to the documenation.

proc.communicate is documented with "If streams were opened in text
mode, input must be a string. Otherwise, it must be bytes." as well.

And that in turn involves:

/usr/local/lib/python3.8/subprocess.py has:

   def communicate(self, input=None, timeout=None):
. . .
               stdout, stderr = self._communicate(input, endtime, timeout)
. . .

So input still seems to be a str for the following:

       def _communicate(self, input, endtime, orig_timeout):
. . .
           self._save_input(input)            
           if self._input:
               input_view = memoryview(self._input)
. . .

but self._input need not be.

This is where:

       def _save_input(self, input):
           # This method is called from the _communicate_with_*() methods
           # so that if we time out while communicating, we can continue
           # sending input if we retry.
           if self.stdin and self._input is None:
               self._input_offset = 0
               self._input = input
               if input is not None and self.text_mode:
                   self._input = self._input.encode(self.stdin.encoding,
                                                    self.stdin.errors)

The implication of the error would seem to be
that the encode did not happen and, so, either

self.stdin and self._input is None

was false or:

self.text_mode

was false (and it appears to be the later).

This fits with the stdin being a byte stream but input being a str
--and so the error report from memoryview.

But I still have no clue why the FreeBSD server builds of chromium
do not end up with such an error report.

Note: I've duplicated the failure in my aarch64 and amd64 contexts.


For reference:

# pwd
/usr/ports
# ~/fbsd-based-on-what-commit.sh
branch: main
merge-base: 59611d61d70a85f4418f3f701db1b7baf58560ba
merge-base: CommitDate: 2021-09-29 09:39:17 +0000
59611d61d70a (HEAD -> main, freebsd/main, freebsd/HEAD) databases/postgresql14-server: fix openssl dependency
n560161 (--first-parent --count for merge-base)

# uname -apKU
FreeBSD CA72_16Gp_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021     root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm64.aarch64/sys/GENERIC-NODBG-CA72  arm64 aarch64 1400032 1400032

I do not see such a failure in the likes of:

http://ampere2.nyi.freebsd.org/data/main-arm64-default/p5f5c0fe00a09_s3fcbde5e88/logs/chromium-92.0.4515.159_2.log

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)