Test failure on s390x with GCC 12

[musicinmybrain]

• asyncpg version: 0.25.0
• PostgreSQL version: 14.1
• Do you use a PostgreSQL SaaS? If so, which? Can you reproduce
  the issue with a local PostgreSQL install?: N/A
• Python version: 3.10.1
• Platform: Fedora Rawhide (development version of Fedora Linux), s390x architecture
• Do you use pgbouncer?: no
• Did you install asyncpg with pip?: no
• If you built asyncpg locally, which version of Cython did you use?: 0.29.26
• Can the issue be reproduced under both asyncio and
  uvloop?: I don’t know how to answer this. I’m just running the test suite.

I’m the maintainer of the python-asyncpg package in Fedora Linux. A pre-release version of GCC 12 was just introduced into Rawhide, the development version of the distribution. This seems to have brought about a new test failure on the s390x platform only:

=================================== FAILURES ===================================
_____________________ TestPrepare.test_prepare_28_max_args _____________________
self = <tests.test_prepare.TestPrepare testMethod=test_prepare_28_max_args>
    async def test_prepare_28_max_args(self):
        N = 32768
        args = ','.join('${}'.format(i) for i in range(1, N + 1))
        query = 'SELECT ARRAY[{}]'.format(args)
    
        with self.assertRaisesRegex(
                exceptions.InterfaceError,
                'the number of query arguments cannot exceed 32767'):
>           await self.con.fetchval(query, *range(1, N + 1))
tests/test_prepare.py:546: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
asyncpg/connection.py:645: in fetchval
    data = await self._execute(query, args, 1, timeout)
asyncpg/connection.py:1659: in _execute
    result, _ = await self.__execute(
asyncpg/connection.py:1684: in __execute
    return await self._do_execute(
asyncpg/connection.py:1711: in _do_execute
    stmt = await self._get_statement(
asyncpg/connection.py:398: in _get_statement
    statement = await self._protocol.prepare(
asyncpg/protocol/protocol.pyx:168: in prepare
    return await waiter
asyncpg/protocol/protocol.pyx:832: in asyncpg.protocol.protocol.BaseProtocol._dispatch_result
    self._on_result__prepare(waiter)
asyncpg/protocol/protocol.pyx:756: in asyncpg.protocol.protocol.BaseProtocol._on_result__prepare
    self.statement._set_args_desc(self.result_param_desc)
asyncpg/protocol/prepared_stmt.pyx:281: in asyncpg.protocol.protocol.PreparedStatementState._set_args_desc
    self.parameters_desc = _decode_parameters_desc(desc)
asyncpg/protocol/prepared_stmt.pyx:349: in asyncpg.protocol.protocol._decode_parameters_desc
    p_oid = <uint32_t>reader.read_int32()
asyncpg/pgproto/buffer.pyx:501: in asyncpg.pgproto.pgproto.ReadBuffer.read_int32
    self._ensure_first_buf()
asyncpg/pgproto/buffer.pyx:309: in asyncpg.pgproto.pgproto.ReadBuffer._ensure_first_buf
    self._switch_to_next_buf()
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 
>   self._buf0 = <bytes>self._bufs[0]
E   IndexError: deque index out of range
asyncpg/pgproto/buffer.pyx:319: IndexError
=========================== short test summary info ============================
FAILED tests/test_prepare.py::TestPrepare::test_prepare_28_max_args - IndexEr...

(Unfortunately, postgresql/libpq was upgraded from 13.x to 14.x at the same time, but I was able to do a local emulated build with libpq 14.x and GCC 11 and did not observe the problem, while a local emulated build with libpq 14.x and GCC 12 did reproduce the problem—which seems to point conclusively to GCC 12 as the trigger.)

I’m not quite sure how to debug this, but I’m happy to do any experiments that might help, either in emulation or on real hardware—on which I don’t have interactive shell access, but I can run as many RPM test builds as I need to.

[elprans]

Interesting. I'll need to see if I can repro this. This could be a miscompilation, but could be a genuine bug too caused by some undefined C behavior somewhere.

[musicinmybrain]

Interesting. I'll need to see if I can repro this. This could be a miscompilation, but could be a genuine bug too caused by some undefined C behavior somewhere.

It looks like this problem went away with a later GCC 12 pre-release, so I think it’s safe enough to call it a probable compiler bug.