YOLO training segmentation fault: GPU memory and CUDA fixes

Darknet YOLOv2 training on an older card dies seconds after it starts: the weights load, the first image batch loads, then the terminal prints Segmentation fault (core dumped). The reflex is to reinstall the driver or rewrite the dataset config, and both are usually wrong. The fault is one of three things, in this order of likelihood: video memory exhausted at the first resize, a cuDNN library that does not match the CUDA toolkit, or a dataset file the loader cannot read. This guide gives you the log reading that separates the causes, the test that confirms each one, the fix that matches it, and the decision on whether the card in front of you can train YOLOv2 at all. The worked example uses the numbers from exactly this situation: a GTX 645 with 974 MiB on board, toolkit 8.0.62, driver 410.78, batch=20, subdivisions=20 at 416×416.

Read the log before you change anything

The sequence in the terminal output already narrows the field:

• The cfg parses and the network builds. The layer table prints down to the detection layer, 13 x 13 x 30 at the output. Your filters line is right, and the arithmetic is worth checking once: filters = (classes + 5) × 5 = (1 + 5) × 5 = 30 for classes=1. A wrong filters line is a classic YOLOv2 crash, and yours is not it.
• The pre-trained weights load: the log prints Loading weights from darknet19_448.conv.23 ... Done!
• The first data batch loads in 0.05 s, so the path list worked at least once.
• Resizing 576 prints, and the process dies before the first iteration line.

Configuration and weights are exonerated; the crash is in the first training step at the new input size. That is GPU territory. Everything that follows separates the three suspects that all die in the same place.

Cause 1: the resize runs the card out of VRAM

With random=1 in the [region] block, the trainer periodically changes the input resolution to another multiple of 32, and your log shows the first draw went to 576. Every activation buffer scales with input area, so 416 → 576 multiplies all of them by (576 ÷ 416)² ≈ 1.92. Training holds every layer's output for the backward pass, and cuDNN reserves convolution workspaces on top — workspaces Darknet never prints, which at this input size can take a few hundred megabytes alone. When an allocation inside that sequence fails, old Darknet builds do not print an out-of-memory message; they die with a segmentation fault. That is why a memory problem looks like a code problem.

Your cfg has batch=20 with subdivisions=20, so exactly 1 image is in flight per step: already the smallest footprint the framework can make. Shrinking batch cannot rescue this run — the card itself is the constraint.

Test: set random=0, drop the input to 352×352, and train ten iterations. If the run survives there and dies again the moment random=1 returns, memory is confirmed. If you have chased depth-video playback hangs before, it is the same signature — memory pinned at the ceiling, then death.

Worked example: 736 MiB free against a 576 pixel resize

Inputs, read straight from the crash report:

• Card memory: 974 MiB total, 238 MiB already used by the desktop, so 974 − 238 = 736 MiB free.
• Input sizes: base 416×416 from the cfg, first resize 576×576 from the log.
• Network shape: the layer table prints 18 filters per convolution down to the 13×13 head. Layer 0 alone holds 416 × 416 × 18 = 3,115,008 values per image, and the full printed stack sums to about 5.79 million values at the base size.
• Precision: the framework stores activations as 32-bit floats, 4 bytes per value.

Rule in words: training memory ≈ images per pass × sum of layer outputs × 4 bytes × (input ÷ base)², plus cuDNN workspaces.

Arithmetic:

• Resize factor: (576 ÷ 416)² = 1.385² ≈ 1.92.
• Activations per image at the base: 5,790,000 × 4 bytes ≈ 23 MB.
• Activations per image at 576: 23 MB × 1.92 ≈ 44 MB. Layer 0 alone accounts for 18 × 576 × 576 × 4 ≈ 24 MB of that.
• Images per pass: 20 ÷ 20 = 1.

Result: activations need about 44 MB, and the card shows 736 MiB free. Plain buffer math says this should run, and it dies anyway. The gap sits in the part Darknet does not print: cuDNN convolution workspaces and batch-normalization buffers at 576×576×18. On a card with 736 MiB free while the desktop already holds 238 MiB, those unprinted allocations are the difference between running and dying.

Decision and threshold: this card has no margin left to trade. The practitioner floor for full YOLOv2 training is a card with 8 GB or more, because the standard batch=64, subdivisions=8 run is done on 8 GB hardware. At 736 MiB free the card sits an order of magnitude below that floor, and no cfg edit closes the gap. Stop editing the cfg on this card; move the training job — the next sections show where it runs instead.

Cause 2: a cuDNN library that does not match CUDA 8.0

The toolkit in the report is release 8.0, V8.0.62 by nvcc -V. cuDNN ships separately from the toolkit, and a cuDNN built against a different toolkit crashes on exactly the training path: Darknet reports segmentation faults that trace into cudnnBatchNormalizationForwardTraining().

The test is one rebuild. Compile Darknet with cuDNN disabled and run the identical command. If the segfault disappears — training will be slower — the library was the fault. Install the cuDNN release built for CUDA 8.0, rebuild with cuDNN enabled, and keep that pair fixed. One toolkit and one matching cuDNN per machine is the same discipline that keeps version drift out of container deployments: pin one SDK version everywhere.

Run the crash under gdb first and read the backtrace, because the two GPU causes leave different signatures. A backtrace that lands inside a cudnn symbol is this cause. Death at the resize with free memory near zero is Cause 1.

Cause 3: broken paths and corrupted images in the dataset

The list files in the report carry the classic traps. The train.txt lines read /home/uaer/src/... while the dataset sits in /home/user/src/..., dataset.data points at /home/useer/src/..., and the filenames contain spaces: img (10).jpg. A path that misses by one character, or an image file that is truncated, kills the loader. Corrupted images are a recorded training-time segfault cause in Darknet, and the loader dies without naming the bad file.

Check the entire list before the next run. This loop prints every path that does not exist:

while IFS= read -r p; do
  [ -f "$p" ] || echo "missing: $p"
done < cfg/task/train.txt

Then open a sample of the images in any viewer, confirm each has a matching label .txt, and rename the spaces out: img_10.jpg rather than img (10).jpg, then regenerate the list. Your label lines are already in the right form — 0 0.435937 0.033333 0.190625 0.058333 is class, x-centre, y-centre, width, height, normalized 0 to 1.

In this particular run the first batch loaded cleanly, which points away from paths as the immediate killer. Fix them anyway: the same list crashes the next run at a different image. Dataset-side crashes look identical across frameworks — the folder and mask errors that break anomaly-detection training reach the terminal the same way.

Ruled out: the 410.78 driver and the CUDA 10.0 label

The report suspects the driver because nvidia-smi prints CUDA Version: 10.0 next to Driver Version: 410.78 while the build used toolkit 8.0. That label is the newest toolkit the installed driver can run, not a demand on your build. Drivers are backward compatible: an application compiled against CUDA 8.0.62 runs on a 410.78 driver, and the GTX 645 is covered by both. The pairing in the report is legal.

Driver state is still the right lever for some industrial GPU crashes, just on other software: a robot-simulation startup crash fixed by the GPU driver rather than a reinstall is the same distinction pointed the other way. Here, the driver stays as it is.

Which cards can train YOLOv2, and where the job runs

Training is the GPU-hungry half of a vision AI project — that is why GPUs beat CPUs for deep learning training. Inference is light: one image forward, no backward pass, no resize surprise. Typical working points for Darknet YOLOv2 training:

The basis: the standard config, batch=64 with subdivisions=8, puts 8 images in flight and is run on 8 GB cards, and the framework's own advice for an out-of-memory error is to keep batch and raise subdivisions. The GTX 645 sits below every row; its remaining useful life is as a display card.

On-site, the clean split is a training machine for the offline half and inference hardware for the line.

On-site training, kept off the line PCs:

A quad-GPU AI training server takes the team's training jobs while production keeps running.

Once trained, the line-side job is inference, which needs a fraction of the memory. The AI inference terminals come in single-card and dual-card versions:

All 2 share: Power supply 24 V DC; Installation method Desktop or wall mounting; Temperature 0 to 45 °C; Humidity 20% RH to 95% RH (no condensation); Certification CE, KC. Values as printed in each product's data sheet; open a part for its drawing and full specifications.

For a multi-camera cell that runs cameras and the trained model together, one vision controller does both jobs:

This VC5000 controller carries 32 GB of memory, PoE camera ports and 8 built-in light channels, so cameras and lights land on one box. Deployment is its own discipline: shrinking the GPU container for embedded deployment covers the software side, and CPU-only inference is the fallback for slower lines.

Prevention: checks before the next training run

Each item exists because it kills a run somewhere:

• Compute images per pass first — batch ÷ subdivisions — and match the card to that number. VRAM scales with images in flight, not with batch alone.
• Train with random=0 until a full run survives, then step the input size up deliberately. random changes the memory target mid-run.
• Keep nvidia-smi open on a second terminal for the whole run. The crash-moment reading picks the cause in seconds.
• Validate the dataset before training: the missing-file loop, a sample of opened images, label files present. The loader segfaults on bad input instead of reporting it.
• Fix one toolkit and one matching cuDNN per machine, and rebuild after every change. Version drift is its own crash class.
• Split the job: train off-line, deploy inference on the line. A training crash should never be able to touch production.
• If your own inference code shares the GPU with other processes, own the contexts and buffers explicitly — the CUDA context mistakes that follow camera close apply to training machines too.

One environment rule: do not train inside a virtual machine unless the GPU is passed through to it. A virtual display adapter brings its own crash class, as in an HMI black screen traced to a virtual GPU adapter.

If the split between a training machine and a line-side controller needs numbers for your cell, send the cfg and the nvidia-smi output through the contact page — the sizing answer is a page of arithmetic. More debugging at this layer lives on the systems topic page.