NZBGet Version

v26.0-stable (also reproduced on v26.1-testing)

Platform

Linux/Docker

Environment

• Device: Arch Linux x86_64
• CPU: AMD x86_64
• 7zip 26.00, unrar 7.x
• Running in Docker: No

Current Behavior

NZBGet crashes with SIGFPE (signal 8) on startup when post-processing resumes for downloads containing zero-byte or corrupt split file segments (e.g., .7z.001, .7z.002).

The crash occurs in UnpackController::JoinFile() at the progress calculation:

m_postInfo->SetStageProgress(int(written * 1000 / totalSize));

where totalSize is 0 because all fragment sizes are 0.

Since NZBGet resumes post-processing on startup, this results in a crash loop, NZBGet cannot start at all until the queue state is manually cleared.

Core dump stack trace:

Signal: 8 (FPE)
#0  _ZN16UnpackController8JoinFileEPKc (/usr/bin/nzbget + 0xfcb94)
#1  _ZN16UnpackController17JoinSplittedFilesEv (/usr/bin/nzbget + 0xfd0bd)
#2  _ZN16UnpackController3RunEv (/usr/bin/nzbget + 0xffd51)

Expected Behavior

NZBGet should log an error for the empty/corrupt segments and continue running, rather than crashing with a divide-by-zero.

Steps To Reproduce

1. Have a download with split file segments (e.g., .7z.001, .7z.002) where the segments are zero-byte
2. NZBGet attempts to join the split files during post-processing
3. NZBGet crashes with SIGFPE

Logs

coredumpctl info:
Signal: 8 (FPE)
#0  UnpackController::JoinFile(char const*) (/usr/bin/nzbget + 0xfcb94)
#1  UnpackController::JoinSplittedFiles() (/usr/bin/nzbget + 0xfd0bd)
#2  UnpackController::Run() (/usr/bin/nzbget + 0xffd51)

Extra information

Fix submitted in #772 which adds a guard to return early when totalSize <= 0.