libxmp / xmp-cli

Command-line mod player using libxmp
GNU General Public License v2.0
74 stars 22 forks source link

Segmentation fault on exit in Windows/MSYS2. #19

Closed AliceLR closed 3 years ago

AliceLR commented 3 years ago

I haven't been able to catch this one in GDB or otherwise diagnose it yet, but frequently xmp will crash on exit with a segmentation fault.

$ xmp /d/ModLand/ftp.modland.com/ftp.modland.com/pub/modules/Impulsetracker/TJ\ Technoiz/coop-Lyzzard/shorecrest\ pilgrimage.it
Extended Module Player 4.1.0
Copyright (C) 1996-2016 Claudio Matsuoka and Hipolito Carraro Jr
Using Windows WinMM sound output
Mixer set to 44100 Hz, 16bit, cubic spline interpolated stereo
Press 'h' for help

Loading D:/ModLand/ftp.modland.com/ftp.modland.com/pub/modules/Impulsetracker/TJ Technoiz/coop-Lyzzard/shorecrest pilgrimage.it (1 of 1)
Module name  : shorecrest pilgrimage
Module type  : OpenMPT 1.17 IT 8.88
Module length: 256 patterns
Patterns     : 22
Instruments  : 8
Samples      : 19
Channels     : 10 [ 8 8 8 ^ 0 f ^ ^ 3 d ]
Duration     : 3min01s
Speed[06] BPM[84] Pos[16/FF] Pat[15/15] Row[57/57] Chn[08/3D]      0:03:00.8
Segmentation fault
sezero commented 3 years ago

On i686-linux, no crashes with un-optimized builds of libxmp+xmp. Running under valgrind now to be sure.

sezero commented 3 years ago

Nothing bad reported by valgrind.

cmatsuoka commented 3 years ago

Also no problems with valgrind on x86_64-linux running current master. It could be something specific to MSYS2 or WinMM.

Module name  : shorecrest pilgrimage
Module type  : OpenMPT 1.17 IT 8.88
Module length: 256 patterns
Patterns     : 22
Instruments  : 8
Samples      : 19
Channels     : 10 [ 8 8 8 ^ 0 f ^ ^ 3 d ]
Duration     : 3min01s
Speed[06] BPM[84] Pos[16/FF] Pat[15/15] Row[57/57] Chn[08/3D]      0:03:00.8
==24157== 
==24157== HEAP SUMMARY:
==24157==     in use at exit: 0 bytes in 0 blocks
==24157==   total heap usage: 545 allocs, 545 frees, 415,833 bytes allocated
==24157== 
==24157== All heap blocks were freed -- no leaks are possible
==24157== 
==24157== For lists of detected and suppressed errors, rerun with: -s
==24157== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
AliceLR commented 3 years ago

So far no luck instrumenting it in MSYS2 with Dr. Memory (crashes on startup due to an internal bug) or ASan (ASan libraries for both GCC and Clang are missing despite it apparently being supported for MinGW now...).

AliceLR commented 3 years ago

This may be due to a missing waveOutReset. The Win32 documentation mentions it should be used prior to waveOutClose but doesn't specify re: waveOutUnprepareHeader. A StackOverflow answer here suggests it should be called before both though.

https://docs.microsoft.com/en-us/previous-versions/ms713744(v=vs.85) https://docs.microsoft.com/en-us/windows/win32/api/mmeapi/nf-mmeapi-waveoutunprepareheader

If I can get this consistently reproducible I'll try adding a waveOutReset call to see if it helps but this could just be a dead end.

edit: Alternatively it might be good enough to sleep if waveOutUnprepareHeader returns WAVERR_STILLPLAYING.

AliceLR commented 3 years ago

OK, I managed to reproduce the segmentation fault five times in a row with this OctaMED module.

Added a debug line to print the return code of waveOutUnprepareHeader and for most of the headers it's 33 (WAVERR_STILLPLAYING).

$ xmp /c/megazeuxtests/music/modfmt/pentium.med
Extended Module Player 4.1.0
Copyright (C) 1996-2016 Claudio Matsuoka and Hipolito Carraro Jr
Using Windows WinMM sound output
Mixer set to 44100 Hz, 16bit, cubic spline interpolated stereo
Press 'h' for help

Loading C:/megazeuxtests/music/modfmt/pentium.med (1 of 1)
Module name  : Pentium ???
Module type  : OctaMED 4.00 MMD1
Module length: 15 patterns
Patterns     : 31
Instruments  : 21
Samples      : 19
Channels     : 4 [ 4 b b 4 ]
Duration     : 2min18s
Speed[09] BPM[7D] Pos[0E/0E] Pat[0E/1E] Row[3F/3F] Chn[04/04]      0:02:18.0
33
33
0
33
33
33
33
33
33
33
Segmentation fault

edit: confirmed calling waveOutReset before any of the waveOutUnprepareHeader calls prevents this module from causing a segmentation fault but I want to test a little more before I submit my patch.