I also tried to run it with the newest container on Seqera containers:

docker run -i --cpu-shares 2048 --memory 8192m --platform linux/amd64 -v /Users/franziska.franziska/workspace/seqinspector:/Users/franziska.franziska/workspace/seqinspector -u $(id -u):$(id -g) <http://community.wave.seqera.io/library/toulligqc:2.8.4--2e474221a8568dff|community.wave.seqera.io/library/toulligqc:2.8.4--2e474221a8568dff> toulligqc --fastq Undetermined_S0_L001_R1_001.fastq.gz --output-directory Undetermined_05

and get yet another error that seems to be linked to the mac chip issue:

qemu: uncaught target signal 11 (Segmentation fault) - core dumped

@Mahesh Binzer-Panchal

And giving more memory doesn't help either I guess?

I don’t HAVE more memory didn’t specify the amount of memory, so I think this is all the memory I can allocate. Also, based on all I can find in the internetzzz, this is a problem of identification, not allocated resources

I was plugging it into Seqera's AI. This is what it says

Root Cause Analysis: toulligqc Segmentation Fault

Based on my research, I've identified the specific reason why

toulligqc

is failing with exit status 139 (segmentation fault) under QEMU emulation on your Mac with Apple Silicon:

The Culprit: h5py and HDF5 Library

Key Dependencies of toulligqc:

From the PyPI page, toulligqc requires:

• h5py - Python bindings for HDF5

• pod5 - Oxford Nanopore POD5 file format (also uses HDF5 internally)

• numpy, pandas, scipy, scikit-learn, pysam, plotly, matplotlib, tqdm

Why h5py Causes Segfaults Under QEMU:

HDF5 is Architecture-Specific C Code

HDF5 (Hierarchical Data Format 5) is written in C with architecture-specific optimizations

1. During compilation, HDF5 generates architecture-specific headers (

H5Tinit.c

,

H5lib_settings.c

) by running test programs on the target architecture

2. These headers contain hardware-specific details about:

3. Data type sizes and alignment

4. Byte ordering (endianness)

5. Floating-point representation

6. Memory layout

Cross-Architecture Incompatibility

1. The biocontainers image (

<http://quay.io/biocontainers/toulligqc:2.7.1|quay.io/biocontainers/toulligqc:2.7.1>

) contains x86_64 compiled binaries of HDF5

2. When QEMU tries to emulate these x86_64 binaries on ARM:

3. Memory access patterns differ between architectures

4. System calls are translated but may have subtle differences

5. SIMD instructions (SSE/AVX on x86) don't map cleanly to ARM NEON

6. Thread synchronization primitives behave differently under emulation

FASTQ File Processing = Heavy I/O + Memory Operations

1. Your command processes

.fastq.gz

files, which likely triggers:

2. Memory-mapped I/O (mmap) - notoriously problematic in QEMU

3. Large buffer allocations - emulation has 2-3x memory overhead

4. Multi-threaded decompression - thread emulation is fragile

5. HDF5 writes - complex file format with metadata and chunked storage

Why It's Failing at Runtime (Not Compile Time)

The container already contains pre-compiled x86_64 binaries of h5py/HDF5

1. QEMU successfully loads and starts the program

2. Segfault occurs when HDF5 tries to:

3. Access memory with x86-specific alignment assumptions

4. Use atomic operations that don't emulate correctly

5. Perform file I/O with architecture-specific buffer handling

Why This Specific Problem:

HDF5 is Notoriously Difficult to Cross-Compile

From the research:

HDF5 developers explicitly discourage cross-compilation

• The build process requires running test programs on the target architecture

• Cannot cross-compile from x86 → ARM or ARM → x86 easily

• This is a known limitation documented in HDF5 forums

Bioinformatics Tools + HDF5 = Common Pain Point

Oxford Nanopore sequencing uses HDF5 formats (FAST5, POD5)

• Many tools in the biocontainers repository are only built for x86_64

• No ARM64 builds available because HDF5 cross-compilation is hard

looks like there is no other solution. Quite disappointing 😢