Mixxx crashes when using the track list windows ( 1.11 )

[Krysstof]

okay, I have an annoying bug with mixxx 1.11

everytime Ido something on the track list, mixxx crashes, except when I do a double clic to load a track or a simple clic to select a track. every thing else crashes
 - sorting the list,
 - right clic
 - drag and drop

It also crashes when going to "analyse ==> analyse all)

this happens with all the win64 static build I made or got from Pegasus on IRC

the last "official" setup I got was packging a 3310 build, this one uses dynamic libs and QT 4.7.4

all the one that crashes use static libs (not really an issue I think) and QT 4.8.2

I tried rebuilding from a revert to 3310, it crashes the same.

[Albert Santoni (gamegod)]

Thanks for reporting this. If someone's been changing the libraries
we're using for the Windows builds on our build server, it's their
fault.

These types of crashes on Windows are a classic symptom of mixing
different flavours of the MSVC runtime within one build. All
dynamically linked libraries must use the same runtime flavour
otherwise you get weird crashes like these ones due to differences in
the way memory allocation works.

By runtime flavour, I mean all the DLLs must be compiled with the same
runtime library flags:
http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.71).aspx

For example, every single one of these libraries was compiled with
MSVC 9 (2008), with /MD (release):
https://code.launchpad.net/~mixxxdevelopers/mixxx/mixxx-win32lib-msvc90-release

The DLLs you link with must also match the release and debug
configuration of your executable (/MD vs. /MDd), so make sure you're
linking with the right DLLs for your Mixxx build.

On Thu, Jul 19, 2012 at 2:21 PM, Krysstof <email address hidden> wrote:
> Public bug reported:
>
> okay, I have an annoying bug with mixxx 1.11
>
> everytime Ido something on the track list, mixxx crashes, except when I do a double clic to load a track or a simple clic to select a track. every thing else crashes
> - sorting the list,
> - right clic
> - drag and drop
>
> It also crashes when going to "analyse ==> analyse all)
>
>
> this happens with all the win64 static build I made or got from Pegasus on IRC
>
>
> the last "official" setup I got was packging a 3310 build, this one uses dynamic libs and QT 4.7.4
>
> all the one that crashes use static libs (not really an issue I think)
> and QT 4.8.2
>
>
> I tried rebuilding from a revert to 3310, it crashes the same.
>
> ** Affects: mixxx
> Importance: Undecided
> Status: New
>
>
> ** Tags: 1.11 build qt
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1026592
>
> Title:
> Mixxx crashes when using the track list windows ( 1.11 )
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1026592/+subscriptions

--
Albert Santoni
Developer, Mixxx
http://www.mixxx.org
http://www.oscillicious.com

[Sean M. Pappalardo (pegasus-renegadetech)]

Thanks for clarifying that, Albert. I read some stuff that alluded to that being a problem but it's good to hear someone declare it. :)

That's likely what's going on because in the libs package the OP is using, I built all of the dependencies as static libs with /MT, but Qt had to be built as DLLs due to us requiring WebKit (it is excluded if you do a static Qt build,) so naturally used the /MD option. Do you happen to know if it's feasible to build DLLs using the /MT option (or static libs using /MD) so that everything is consistent? I know it's possible to do both, but do you know if either will work?

That said, using the same bunch of libraries and Qt DLLs, I _do not_ get the problem on my system. (Is there a certain amount of randomness with this that can affect when things crash?)

[Albert Santoni (gamegod)]

On Thu, Jul 19, 2012 at 10:14 PM, Sean M. Pappalardo
<email address hidden> wrote:
> Thanks for clarifying that, Albert. I read some stuff that alluded to
> that being a problem but it's good to hear someone declare it. :)
>
> That's likely what's going on because in the libs package the OP is
> using, I built all of the dependencies as static libs with /MT, but Qt
> had to be built as DLLs due to us requiring WebKit (it is excluded if
> you do a static Qt build,) so naturally used the /MD option. Do you
> happen to know if it's feasible to build DLLs using the /MT option (or
> static libs using /MD) so that everything is consistent? I know it's
> possible to do both, but do you know if either will work?

Yes, this is possible. The /MD and /MT flags _only_ refer to the
static and dynamic linking of the C runtime.

I know it's confusing, so I'll say it again - /MD and /MT only tell
the linker how it should link your application or library against the
MSVC runtime. It doesn't have anything to do with whether or not
you're building an application, a static library, or a dynamic
library. You can do any of those with any combination of the above
flags. But you have to be consistent in which runtime you use (/MD and
/MT) otherwise you end up in this mess.

So I think both the possibilities you suggested (building DLLs with
/MT and static libs with /MD) should work. Try rebuilding Qt as DLLs
with the /MT option, and hopefully that'll solve the problem.

/MD and /MDd are typically the standard ones to us though. Any reason
why you picked /MT instead?

>
> That said, using the same bunch of libraries and Qt DLLs, I _do not_ get
> the problem on my system. (Is there a certain amount of randomness with
> this that can affect when things crash?)

Yeah, there is unfortunately, but if you're lucky it'll crash right
away. It's one of these things where you end up with loads of bad
pointers and it's just a matter of time before stuff starts to crash.

However, when you've got Mixxx built as a debug build (/Zi usually)
and linked with the debug C runtime (eg. /MDd), then it turns on a
load of extra asserts that usually catch the corruption early and
crash faster. This is probably what Krysstof is seeing.

Thanks!
Albert

>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/1026592
>
> Title:
> Mixxx crashes when using the track list windows ( 1.11 )
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/1026592/+subscriptions

--
Albert Santoni
Developer, Mixxx
http://www.mixxx.org
http://www.oscillicious.com

[Krysstof (c-niel)]

thanks for the answers

I'm using the win32 and win64 libs pushed here (and on download.mixxx.org/mess)

they were compiled with latest MS compiler (7.1 SP1)
I am not using this exact version, I'm using the 7.1 not SP1.

i"m gonna upgrade to this version, and retry.

I'm am not using debug at the moment as these libs were compiled without the debug information, and it prevent liking them.

As soon as I manage to upgrade to this compiler I'll retry.

[Krysstof (c-niel)]

ok, I successfully installed the latest compiler (7.1 SP1)
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64

I'm am rebuilding QT for the moment, with these options :
(from QT 4.8.2 everywhere)
configure -qt-zlib -qt-libpng -qt-libmng -qt-libtiff -qt-libjpeg -opensource -plugin-sql-sqlite -release -no-qt3support -no-dsp -mp -phonon -nomake demos -nomake examples

building x64 and x86, so it will take a few hours.

I'm leaving the command line here, if Pegasus_RPG (nick from irc) can check this and tell me if something is wrong, let me know.

I'll let you know when everything has been compiled with this version of the compiler.

[Krysstof (c-niel)]

builds done successfully

crashes are the same with QT 4.2.8.

Building 4.7.4 and will come back later

[Krysstof (c-niel)]

same with qt 4.7.4

[Sean M. Pappalardo (pegasus-renegadetech)]

Albert: I picked /MT because I thought it was required to build static libs. (And I _think_ it removed some unresolved externals on some of our deps.)

Kryssof: Hang on. I will rebuild the libs as Albert suggests and upload a new package for you to try.

[Krysstof (c-niel)]

All I know it the only working 1.11 was the beta 2 with a setup on the build server (can't remember build num)
but it was compiled with dynamic libs and QT 4.7.4

I noticed you could to a static build for QT, this does not work well when building mixxx with scons. default qt option is -shared

Anyway, yesterday I managed to have a working version by replacing the protoc.exe file that was in the path, and used the one in the lib folder
(unfortunately, I deleted and retry, then it crashed again)

A bit of info on QT, and maybe a way for you to upload your lib version :

For QT compilation, 342 or 64 : There is no need to tweak any files

setenv /x86 for 32 bits, setenv /x64 for 64 bits, that's all.

then I used the command line from the source only package. (there you may check what I did, and/or use your command line instead)

I saw a way to "lighten" the QT payload: do a "nmake install" that will sever links between the SRC and the compiled version. (mainly : that will populate the include folder)

then just copy the bin, plugin, include and lib folders in a new folder.

this folder is your new "QTDIR" (no need for a lot of stuff in there, but the size, zipped, is uploadable somewhere)
4.7.4 64 = 47 MB rar'ed
4.8.2 64 = 49MB

the 32 bit is smaller.
I think the debug version would be larger.

in the mean time I'm back to trying to make my successful compilation and runing work again.

[RJ Skerry-Ryan (rryan)]

Hi Krysstof,

We've done some shuffling and maybe have something workable now. Can you give it another try?

[RJ Skerry-Ryan (rryan)]

Try this build:
http://builds.mixxx.org/builds/release-1.11.x/r3407/

[RJ Skerry-Ryan (rryan)]

Any updates, Krysstof?

[Daniel Schürmann (daschuer)]

This effects an old version of Mixxx.
Please file a new bug if you can reproduce the issue in a recent version.

[Swiftb0y (swiftb0y)]

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