Chrisoft

The visualization plugin for QMidiPlayer in Linux has suffered from a dbus-related bug for a long time: after you have opened the visualization window, close it and try to bring it up again, it will either result in several lines of dbus warning which suggests there's a bug in the program (on Debian sid), or simply a crash (on Arch Linux).

Well, I have to admit the design of QMidiPlayer's visualization architecture is pretty weird: the visualization plugin spawns its own thread and do almost everything in it. After doing some research on the Internet, I realized that everyone suggests that Qt and SDL shouldn't be used together, "use QtOpenGL instead". However I thought that will hang the main UI thread and I just don't believe in the myth.

So I started my investigation in early May. I even opened an related issue on github. Unfortunately nobody offered help. So I had to solve the issue myself. First I had a look into the dbus warnings:

process <PID>: arguments to dbus_connection_unref() were incorrect, assertion "connection->generation == _dbus_current_generation" failed in file ../../dbus/dbus-connection.c line 2822.
This is normally a bug in some application using the D-Bus library.

Qt definitely uses dbus. After spitting these into stderr, QMidiPlayer crashes instantly in the QDBusConnection thread. Googling the warning turned out nothing. Then I came across with this blog post from a KDE developer:
https://blogs.kde.org/2009/03/26/how-crash-almost-every-qtkde-application-and-how-fix-it-0

Unfortunately, after applying the "fix", the bug didn't change even a little bit. So I had to move on.

UPD 2016-10-28

After several months' idleness of the investigation due to the lack of idea, I suddenly decided to have a look at all dbus calls when QMidiPlayer crashes. Then I found the following dbus call:

path=/org/freedesktop/ScreenSaver; interface=org.freedesktop.ScreenSaver; method=Inhibit;
string "My SDL application"
string "Playing a game"

Apparently SDL is also using dbus to do some dirty work -- disabling the screen saver! So I appended SDL_EnableScreenSaver in SMELT's init function. Unfortunately, nothing happened again. However I've guessed out the cause to the problem: both Qt and SDL try to initialize a dbus connection in one process, which is not allowed. So I have to get rid of either one of them.

Therefore I began to port the SMELT engine to GLFW. After two days of work, the port was finished and it worked like a charm -- I have solved the problem!

BUT THAT'S NOT THE END OF THE STORY.

Driven by the unstoppable merriness after fixing a long-existed bug, I started to build GLFW version of SMELT for Windows. The process was painful but finally I managed to do it successfully. After that it's time to compile the visualization library. A beautiful DLL file, sized 1096192 bytes, was produced. This build is almost 4x smaller than the previous failed mingw build and I regarded this as a omen of fortune.

I put the DLL file into the plugin folder of QMidiPlayer and launched the application. No errors occured as the mingw build once caused and the plugin showed up correctly in the plugin manager. I was so excited that I turned on the plugin immediately and I couldn't wait to announce the result to my friends. However when I hit the visualization I was greeted by a déjà vu scene.

And this nasty little dialog from the Windows 2000 era.

So another tale of a battle between a fierce bug and me is due to happen. Stay tuned and watch the fight!

UPD@2016-12-28

So the bug has been (mostly) fixed by the following two commits!
b79c4b7e3cab3711e87ba9e28fa8423a84ea7efa@QMidiPlayer
b13f72857af93489f535b84d62882f681dc84a73@SMELT

Basically the most tough part to debug is caused by the stupidest typo...

@@ -62,7 +62,7 @@ bool SMELT_IMPL::smInit()
  		else if(i==0x80000004)
  		memcpy(cpuName+32, CPUInfo, sizeof(CPUInfo));
  	}
 -	while(*cpuName=' ')++cpuName;
 +	while(*cpuName==' ')++cpuName;
  	smLog("%s:" SLINE ": CPU: %s\n", SYS_SDL_SRCFN,cpuName);
  	free(loced);

This naïve mistake screwed up the memory and this should be the cause that made the debugger report different stack traces in different build modes... (that reminds me of the experience of screwing up the call stack, in which the backtrace was filled up by "0x0000000000000000 in ??()"...)

After having fixed this, it was much easier to debug the application. Soon afterwards the first working visualization plugin for QMP on Windows came out.

Finally I have to make more complaints about the develop environment for a cross-platform C++ application developer in Microsoft Windows. It's bloated, complicated and confusing. I wonder whether Microsoft is deliberately making it difficult in order to force more developers to migrate to C#/.Net. What a big ambition Microsoft is bearing!