Development version / 3.0alpha crashes after splashscreen (potentially an issue portaudio)

• Sep 26, 2018 - 15:39
Reported version
3.0
Type
Functional
Severity
S2 - Critical
Status
closed
Project
MuseScore

Hi,

I'm currently trying to build run and test the latest musescore version on Win10 (build 17134.285) using a freshly installed VisualStudio environment and a .
The project appears to build fine, but it crashes during/after the splashscreen.
This happens with the nightly builds as well as with my own build.
With my own build it appears that there is an issue with portmidi (which is strange as it appears to be the same codebase that is used for musescore 2.3 which runs fine).
When running in debug mode from VisualStudio I get an Access violation exception during initialization of portaudis portmidi. at the "midiInOpen" call.
More specifically there appears to be an issues with the winmm_in_callback pointer passed to the winmm system library.
(winmmbase.dll!DriverCallback() appears to try calling to 0x0000000017d86b20, while the value of winmm_in_callback that is passed into midiInOpen is 0x00007ff617d86b20)
Could it be that there is some typecasting issue that truncates the correct callback address? But then again since the portmidi codebase is the same as in version 2.3 that appears unlikely to me.
Or could it be some issue with my build environment? If so has someone encountered similar problems and could point me towards what could be the issue here?
But then again the nightly builds appear to crash at the same point, which speaks against it being an issue with the build environment.

During linking I get a link warning "LNK4098: defaultlib 'LIBCMT' conflicts with use of other libs; use /NODEFAULTLIB:library", I'm not sure if that is pointing to a potential cause for the problem though.

Comments

• Sep 26, 2018 - 17:15

thanks for unbanning.

If looked around a bit and it really appears to be some kind of 64bit/32bit addressing issue.

Removing the cast to DWORD from winmm_in_callback in midiInOpen allows the callback to properly jump into the callback routine.
But then the cast to DWORD has to also be removed from the "midi" pointer and the type for the dwInstance argument in the winmm_in_callback has to be changed to something like unsigned long long.

All in all this should be a patch in the portmidi project, if it's not just some strange quirk of my system that leads to this error.

Reply

• Sep 26, 2018 - 17:28

Is our copy of portmidi on par with the current version of the portmidi project? Maybe it is fixed there since long?
I do remember quite a few MSVC compiler warnings in thirdparty/portmidi, we switched them off (COMPILE_FLAGS "/wd4028 /wd4189 /wd4267 /wd4311 /wd4312"), as we don't want to do anything about those warnings anyway, fixing a real bug though definitely is a different issue

BTW: seems we can scratch /wd4189 from the list of warnings to disable.

Reply