WindowsMediaAudioFormat crash when compiling with /O2

Windows
#1

Hi Jules,

when compiling with optimization for speed (/O2) under Visual Studio 2008 (Windows 7/64), WindowsMediaAudioFormat will crash when creating a reader. The crash (access violation) happens inside line 145 of juce_WindowsMediaAudioFormat.cpp:

HRESULT hr = wmCreateSyncReader (nullptr, WMT_RIGHT_PLAYBACK, wmSyncReader.resetAndGetPointerAddress());

This can be easily reproduced by compiling the JuceDemo with /O2 and clicking on an mp3 file in the File Playback tab of the Audio demo page.

The crash doesn’t occure when I use the following code:

#pragma comment(lib, "wmvcore.lib") 

//==============================================================================
class WMAudioReader   : public AudioFormatReader
{
public:
    WMAudioReader (InputStream* const input_)
        : AudioFormatReader (input_, TRANS (wmFormatName)),
          wmvCoreLib ("Wmvcore.dll"),
          currentPosition (0),
          bufferStart (0), bufferEnd (0)
    {
        typedef HRESULT (*WMCreateSyncReaderType) (IUnknown*, DWORD, IWMSyncReader**);
        WMCreateSyncReaderType wmCreateSyncReader = nullptr;
        wmCreateSyncReader = (WMCreateSyncReaderType) wmvCoreLib.getFunction ("WMCreateSyncReader");

        if (wmCreateSyncReader != nullptr)
        {
            checkCoInitialiseCalled();

            //HRESULT hr = wmCreateSyncReader (nullptr, WMT_RIGHT_PLAYBACK, wmSyncReader.resetAndGetPointerAddress());
            HRESULT hr = WMCreateSyncReader (nullptr, WMT_RIGHT_PLAYBACK, wmSyncReader.resetAndGetPointerAddress());

Chris

#2

That doesn’t make any sense, and when I just tried it in VS2010, it was fine.

Are you sure it’s the optimisation level and not something else? For example, have you set a different default call type in your project? If so, does explicitly marking it as __stdcall help, like this:

typedef HRESULT (__stdcall *WMCreateSyncReaderType) (IUnknown*, DWORD, IWMSyncReader**);

I can’t think of any other reason why a valid function pointer would cause problems.

#3

All I did change was the optimisation, which also crashed on various projects with different versions of Juce.
The suggested change does fix the crash so it seems to have been related to a different call type. I assume that the optimisation for speed uses __fastcall (which also leads to the crash when declared explicitely) instead of __stdcall.

Thanks for the quick fix.

Chris

#4

Yes, I guess the call type must have been secretly changed… Thanks for letting me know!