[2.1.14] Crash (SDL_audiocvt.c)

Place for things which are bugs but we have no idea how to solve them. Things related to hardware, libraries, strange setups, etc.
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

[2.1.14] Crash (SDL_audiocvt.c)

Post by armoredbull »

After a VERY long debugging process thinking I had a hardware malfunction I turned off core isolation and the game finally threw a revealing crash log... The crash happened in a background thread specifically responsible for playing audio (PlaybackAudioThread). The game tried to copy audio data into memory (memcpy), but it attempted to write to an invalid memory address (0000000000000900), which immediately caused Windows to shut the program down to protect my system. I have attached the crash log and dump as well as the save file. The fix was to turn off surround sound.
Attachments
_autosave3.zip
(5.38 MiB) Downloaded 21 times
factorio-dump-previous.dmp
(1013.79 KiB) Downloaded 19 times
factorio-previous.log
(18.31 KiB) Downloaded 23 times
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

Re: [2.1.14] Access Violation Crash Due to Game Engine Audio Handler

Post by armoredbull »

I should clarify that this is a repeating crash that happens seemingly at random.
Loewchen
Global Moderator
Global Moderator
Posts: 10993
Joined: Wed Jan 07, 2015 5:53 pm
Contact:

Re: [2.1.14] Crash (SDL_audiocvt.c)

Post by Loewchen »

Likely a hardware issue, especially considering that this is still the same hardware as 126905. If you find a way to reliably reproduce it let us know.
User avatar
pioruns
Filter Inserter
Filter Inserter
Posts: 364
Joined: Tue Nov 05, 2024 3:38 pm
Contact:

Re: [2.1.14] Access Violation Crash Due to Game Engine Audio Handler

Post by pioruns »

armoredbull wrote: Wed Aug 19, 2026 8:02 pm I should clarify that this is a repeating crash that happens seemingly at random.
Prime95 and memtest86 results?
Playing on: Fractal Meshify 2 RGB | AMD Ryzen 9 5950X (32) @ 3.4GHz
ASRock X570 Steel Legend | 64GiB ECC DDR4 RAM @ 3200MT/s
Radeon RX 6800 XT 16GiB | Crucial P2 SSD 500GB NVMe | 2x 2TB HDD | OS: Devuan GNU/Linux
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

Re: [2.1.14] Crash (SDL_audiocvt.c)

Post by armoredbull »

Passed Memtest on 4 rounds. I even removed two sticks thinking maybe 4 sticks of DDR5 was too much for my memory controller, but that wasn’t the case. I still have only two sticks in and will try Prime95 and get back to you later.
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

Re: [2.1.14] Crash (SDL_audiocvt.c)

Post by armoredbull »

Loewchen wrote: Wed Aug 19, 2026 8:47 pm Likely a hardware issue, especially considering that this is still the same hardware as 126905. If you find a way to reliably reproduce it let us know.
Instead of enforcing limits, the older BIOS would set the CPU's power limits (PL1 and PL2) to 4096W (effectively infinite) and uncap the maximum electrical current (ICCMax). The Intel Core i9-12900KS is a special, extremely aggressive processor When paired with the older unrestricted BIOS defaults When Factorio executed a sudden, highly complex task the processor instantly boosted its clock speed and demanded a massive surge of current. Because the motherboard wasn't enforcing any current limits, the CPU pulled so much power that the motherboard's power delivery components could not maintain perfect voltage. The voltage dipped for just a microsecond. Running at extreme clock speeds with momentarily insufficient voltage causes physical instability. The processor made a microscopic calculation error, slightly corrupting a memory pointer before handing it back to the game. Factorio tried to read that corrupted memory address, realized it was invalid, and Windows instantly terminated the game (producing the Segmentation Fault) to prevent systemic corruption.

That is a different error and years have passed since BIOS defaults have been patched. Also I correctly identified the fault and haven’t had problems until moving to the experimental branch.
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

Re: [2.1.14] Access Violation Crash Due to Game Engine Audio Handler

Post by armoredbull »

pioruns wrote: Wed Aug 19, 2026 8:53 pm
armoredbull wrote: Wed Aug 19, 2026 8:02 pm I should clarify that this is a repeating crash that happens seemingly at random.
Prime95 and memtest86 results?
Prime95 came back with 0 errors and 0 warnings after an hour of running…
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

Re: [2.1.14] Crash (SDL_audiocvt.c)

Post by armoredbull »

So I ran /c game.speed = 100 and

/c game.forces.player.chart(game.player.surface, {{x = -5000, y = -5000}, {x = 5000, y = 5000}})

and

/c for x=1,100 do for y=1,100 do game.player.surface.create_entity({name="behemoth-biter", position={game.player.position.x+x, game.player.position.y+y}}) end end

And didn’t encounter any issues. I have my sound set to 2 channels instead of 6 which fixed the problem. It’s reproducible by running the game with 6 channels.
Donion
Factorio Staff
Factorio Staff
Posts: 512
Joined: Sun Aug 22, 2021 9:18 am
Contact:

Re: [2.1.14] Crash (SDL_audiocvt.c)

Post by Donion »

The log shows it crashes in SDL internals, so largely outside our control. I'll see if I can reproduce it on my end.
armoredbull
Burner Inserter
Burner Inserter
Posts: 11
Joined: Mon Feb 17, 2025 1:06 pm
Contact:

Re: [2.1.14] Crash (SDL_audiocvt.c)

Post by armoredbull »

Loewchen wrote: Wed Aug 19, 2026 8:47 pm Likely a hardware issue, especially considering that this is still the same hardware as 126905. If you find a way to reliably reproduce it let us know.
Actually you are correct. I sincerely apologise for any inconveniences I may have caused! The crash was caused by transient CPU Vdroop under high load, which has since been resolved via BIOS tuning as the defaults are not stable under load!

The ⁠0xc0000005⁠ access violation was caused by transient CPU Vdroop on an i9-12900KS under dynamic loads, starving the Integrated Memory Controller (IMC) during high background threading. I adjusted CPU Load-line Calibration (LLC) to Level 6 in ASUS BIOS to prevent voltage drop spikes during boost transitions. System now completely passes extended XTU Memory Stress Tests and Factorio stress sessions with XMP active without throwing memory pointer exceptions or crashing.
Post Reply

Return to “1 / 0 magic”