protocolbuffers / protocolbuffers/protobuf
[Python] Null pointer dereference (SIGSEGV) in _message.abi3.so on s390x (big-endian) at process startup — regression from 6.31.1 → 6.32+
Nobody has claimed this yet.
- Dominant language
- C++
- Stars
- 72k
- Forks
- 16.3k
- Avg merge
- 1d 17h
- Merged PRs (30d)
- 140
Description
What version of protobuf and what language are you using?
Version: 6.32+
Language: C++/Java/Python/C#/Ruby/PHP/Objective-C/Javascript
Architecture: S390x
supported runtime / compiler version: python 3.12
ISSUE Description:
Environment
- Platform: s390x
- OS: Red Hat Enterprise Linux 9 (el9_8), kernel 5.14.0-687.33.1.el9_8.s390x
- Python: 3.12
- protobuf version that crashes: 6.33.5 (also expected on 6.32.x — not individually tested)
- Last known-good protobuf version: 6.31.1
- grpcio version: 1.73.1
What happens
The Python process crashes with a kernel-level segfault immediately at startup,
inside _message.abi3.so, during AddSerializedFile() when the gRPC-generated
_pb2.py module is first imported. The process never reaches application code.
Kernel log (s390x)
User process fault: interruption code 003b ilc:3 in _message.abi3.so[3ff9cb80000+5c000]
Failing address: 0000000000000000 TEID: 0000000000000800
Fault in primary space mode while using user ASCE.
CPU: 0 PID: 3757 Comm: start-component Not tainted 5.14.0-687.33.1.el9_8.s390x #1
Hardware name: XXXX
User GPRS: 00000000000xxxx 00000000000yyyyyy ....
Worked on 6.31.1 and Failing on 6.32+
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining the Python extension in _message.abi3.so and the AddSerializedFile() path reached when a generated _pb2.py module is imported. Reproduce the startup crash on s390x with Python 3.12, compare protobuf 6.31.1 against 6.32+ and 6.33.5, and consider the issue done when the process no longer segfaults during import.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp, python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100