Mutex issue when constructing gemma model object

[sidwan02]

I'm running into a mutex issue when constructing the gemma model object:

libc++abi: terminating due to uncaught exception of type std::__1::system_error: mutex lock failed: Invalid argument
Abort trap: 6

Reproduce:

from gemma import gm

model = gm.nn.Gemma3_4B()
params = gm.ckpts.load_params(gm.ckpts.CheckpointPath.GEMMA3_4B_IT)

Spec:

• Mac M3 Pro with JAX installed for CPU
• Python 3.13.7

How can I provide additional information to help debug this setup issue?
Thanks!

[Balakrishna-Chennamsetti]

Hi @sidwan02 ,

The above mentioned code snippet is running fine without any issues on the free Colab notebook. The possible workaround could be following:

A common solution is to isolate the conflicting libraries. If you installed JAX for CPU, you might be hitting a generic macOS/JAX issue.

1. Use a different environment/Python version: Try setting up a completely fresh virtual environment with a slightly different Python version (e.g., Python 3.11 or 3.12, if 3.13 is new for your setup).

2. Check for PyArrow/TensorFlow conflicts: If you have PyArrow or TensorFlow installed (even if you don't use them directly), try upgrading or downgrading them, as they are often the source of these low-level C++ conflicts on Mac.

Thanks.

[kkom]

I'm running into this as well, also on Apple silicon (Python 3.12.12).

Apparently it happens when libprotobuf is concurrently linked by multiple packages, and something about it changed in TensorFlow 2.20.

Here is a bunch of related issues:

• Importing TF 2.20.0rc0 and PyArrow results in a Abort trap: 6 on MacOS ARM tensorflow/tensorflow#98563
• v2.20 : erreur [mutex.cc : 452] RAW: Lock blocking tensorflow/tensorflow#99464
• [Python] mutex lock failed: Invalid argument when importing after tink (M1, macOS 14.2.1) apache/arrow#40088
• Mutex issues when two versions of libprotobuf are linked to two Python libraries separately protocolbuffers/protobuf#21686

So far, I managed to solve mutex lock failed: Invalid argument by constraining tensorflow<2.20.

Unfortunately, I get [mutex.cc : 452] RAW: Lock blocking 0x... @ instead now. Someone suggested using pyarrow 17.0.0, but that didn't work for me.

[chrisfougner]

Upgrading to pyarrow 22.0.0 fixed it for me.