Chrisoft::Blog(r#"2-in-1")

-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!~~ -

-[1] -

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! -