Strange things happen in a Windows debug build

[Sean M. Pappalardo]

When building Mixxx 1.7 branch on Windows using the msvcdebug=1 build flag, I see the following problems:

- Crash on library operations (right-clicking a song twice)
- VU meters don't work
- MIDI output is unreliable (some data gets lost)

[Sean M. Pappalardo (pegasus-renegadetech)]

Fixed in 1.7 branch r2420

[Sean M. Pappalardo (pegasus-renegadetech)]

Oop, nope. Spoke too soon. The last thing fixed some of the problem, but it still crashes when you right-click a track, then right-click another.

[Sean M. Pappalardo (pegasus-renegadetech)]

There are no link errors now, but this is still a problem.

[Albert Santoni (gamegod)]

I'm pretty sure Adam had this bug before, and then it mysteriously
went away, which means he probably turned off msvcdebug. So I think we
can confirm that this happens on another PC too.

On Mon, May 25, 2009 at 7:35 PM, Pegasus <email address hidden> wrote:
> There are no link errors now, but this is still a problem.
>
> ** Attachment added: "Screen shot of the current error dialog"
>   http://launchpadlibrarian.net/27159408/DebugError.png
>
> --
> Windows debug build crash on library operations
> https://bugs.launchpad.net/bugs/380075
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Sean M. Pappalardo (pegasus-renegadetech)]

For (my) reference: search the sconscript for msvcdebug and see everything it does. Then search the code for any cflags that msvcdebug defines. I'm thinking one of these ifdef'ed code blocks is to blame for this and other debug-only strangeness.

[Sean M. Pappalardo (pegasus-renegadetech)]

Ok, scary: all msvcdebug=1 does is:
- compiles with /MDd (use the debug version of the LIBCMT library)
- links with /DEBUG
- and disables optimizations (doesn't use /O2 /GL compiler flags and /LTCG:STATUS link flag)

I'm thinking the secret is in those missing optimization flags, specifically the LTCG one...

[Sean M. Pappalardo (pegasus-renegadetech)]

No, it's the /MDd library. If I change that back to /MD it works fine. How badly do we need that?

[Adam Davison (adamdavison)]

It causes Mixxx to be linked against the debug msvc runtime libraries,
which allows you to debug to some extent what's going on if you crash
inside a windows call of some type. It's sort of equivalent to
building against the debug version of Qt but for Windows system stuff.

2009/6/25 Pegasus <email address hidden>:
> No, it's the /MDd library. If I change that back to /MD it works fine.
> How badly do we need that?
>
> --
> Windows debug build crash on library operations
> https://bugs.launchpad.net/bugs/380075
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Albert Santoni (gamegod)]

Sean, you confirm whether this is with 64-bit, 32-bit, or both?

On Thu, Jun 25, 2009 at 8:39 AM, Adam Davison<email address hidden> wrote:
> It causes Mixxx to be linked against the debug msvc runtime libraries,
> which allows you to debug to some extent what's going on if you crash
> inside a windows call of some type. It's sort of equivalent to
> building against the debug version of Qt but for Windows system stuff.
>
> 2009/6/25 Pegasus <email address hidden>:
>> No, it's the /MDd library. If I change that back to /MD it works fine.
>> How badly do we need that?
>>
>> --
>> Windows debug build crash on library operations
>> https://bugs.launchpad.net/bugs/380075
>> You received this bug notification because you are a member of Mixxx
>> Development Team, which is subscribed to Mixxx.
>>
>
> --
> Windows debug build crash on library operations
> https://bugs.launchpad.net/bugs/380075
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Sean M. Pappalardo (pegasus-renegadetech)]

Both.

[Sean M. Pappalardo (pegasus-renegadetech)]

So is there something screwy with my copies of the MSVC debug libraries?? Untargeting.

[Phillip Whelan (pwhelan)]

This is due to mix matching between libraries and programs which use different windows C/C++ runtimes. The implementation of the stack as well as stdio are different in all of them and so are their structures.

The end result is if you create a FILE pointer inside your program then a library calls fprintf with it, or if you allocate memory and pass it to a library which frees it and vice versa your program hangs.

Yet another advantage to the win32 platform, hurray!

Solution: all dependencies that are linked at build time and runtime must use the same MS C/C++ runtime.

[Sean M. Pappalardo (pegasus-renegadetech)]

If that's the case (I'll test later) should I commit debug versions of the dependencies to mixxx-win[64]lib too, Albert & Adam?

[Albert Santoni (gamegod)]

Yes, what Philip said is correct. If we're ever going to have separate
release and debug targets, it is necessary for us to have BOTH debug
and release builds of all precompiled libraries for Windows.

On Thu, Jul 23, 2009 at 2:39 PM, Pegasus<email address hidden> wrote:
> If that's the case (I'll test later) should I commit debug versions of
> the dependencies to mixxx-win[64]lib too, Albert & Adam?
>
> --
> Strange things happen in a Windows debug build
> https://bugs.launchpad.net/bugs/380075
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
>

[Sean M. Pappalardo (pegasus-renegadetech)]

Won't fix this in 1.7 anymore. This is going to seriously increase our mixxx-win*lib space if we commit all of the dependencies with debug libs as well. Do we really want to do that?

[RJ Skerry-Ryan (rryan)]

Since this one is ancient history I'm going to close it. We're pretty certain it was just a result of mixing runtimes.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5176