Still would help to narrow the possibilities.
It is likely more than one segfault source exists in PrBoom and SDL mixer. Two people getting a segfault does not mean it is the same cause. Unless you are exchanging information privately, there has not been enough to exclude these possibilities.
I find the report that it went away and then came back again later to be most suspicious. Software faults do not react that way without some environment change (changing your config settings would do it though, or selecting different options).
Tests for the SDL mixer suspect.
1. Faults in the mixer should vary with different music and sound (long vrs short) because that affects contention for mixer resources.
The fault should vary with different wads.
2. Software draw mode should not affect software faults in the sound mixer.
3. Can be tested by turning off sound effects and music. Does the segfault stop ?
4. If the SDL mixer faults this much, it should also fault the same with other SDL mixer programs. Try DoomLegacy, it uses SDL mixer too.
(It might also segfault if there is a memory failure just due to similarity to PrBoom layout). Try other SDL games too.
5. A debugger can verify the segfault is in SDL mixer code.
Tests for drawer faults.
1. Usually caused by releasing a texture from memory while status bar drawing is still using it. Some textures have multiple uses.
In DoomLegacy, I had to resort to locking all status bar textures so they cannot be released.
2. Test by disabling in code all the releasing and purging of memory allocation. Mostly, this can be done by modifying Z_Free (or the equivalent). Does the segfault stop ?
3. Some other user gets the same fault on a different machine.
4. Run the program in a debugger and record the exact failure location for three failures. Software failures will be consistent in some way, like the address, or the instruction that fails.
Tests for memory failure faults.
1. Unfortunately, the existence of only one program, or even just software draw triggering the segfault does not prove anything. It is a matter of putting a memory pointer in the failing location while toggling the neighbor bits in a contrary way.
The particular program that fails due to a particular memory fault is not related to its size, nor is it predictable.
2. Memory test programs cannot find all kinds of memory failure.
I have more than once written a memory test program to try to find a fault. None of them ever found anything. In one case it was an operating system problem, and for the other I changed the memory chips.
3. If anyone can verify the same segfault on a different machine, then cannot be memory failure. Just having segfaults (like due to SDL mixer) by itself does not prove this segfault is not memory failure. It wastes time to try chasing down in software a fault that is hardware based. However, software modifications can move the fault location around and temporarily mask memory failure.
Same fault, different machines, is the best discriminant.
4. Make sure all your memory is the same brand. With mixed brands must adjust memory settings by hand (some BIOS do not do this well).
5. Swap the memory chip locations and retest. Does the segfault change character ?
6. Run with only one memory enabled at a time. Test for segfault.
7. Alter the BIOS memory settings, wait states, and retest.
8. Disable cache and retest.
9. Change all the memory out and retest. Most drastic.
One person reported that all his chips had same failure pattern, and that swapping positions did not affect failure. Swapping out all chips did cure it.
10. Start another execution intensive program first, leave it running, and retest PrBoom.
This moves the PrBoom execution location (but not so much in cache).
Does the segfault change in anyway ? If it is software, it should not be affected in any way. If it is memory failure, it should change. I might still segfault, but in a different location.
Last edited by wesleyjohnson on Jun 27 2013 at 21:36