sealing some leaks

[Daniel Schürmann]

Attached, I have a patch that seals some memory leaks.
Most of them are one time allocations.

There is still one I am worrying about:

==6192== 1,340,746 (32 direct, 1,340,714 indirect) bytes in 1 blocks are definitely lost in loss record 807 of 807
==6192== at 0x402641D: operator new(unsigned int) (vg_replace_malloc.c:255)
==6192== by 0x6964DD9: QMetaObjectPrivate::connect(QObject const*, int, QObject const*, int, int, int*) (qobject.cpp:2917)
==6192== by 0x6965934: QObject::connect(QObject const*, char const*, QObject const*, char const*, Qt::ConnectionType) (qobject.cpp:2597)
==6192== by 0x8281EE8: TrackDAO::getTrackFromDB(QSqlQuery&) const (trackdao.cpp:649)
==6192== by 0x8283A3C: TrackDAO::getTrack(int, bool) const (trackdao.cpp:742)
==6192== by 0x6855653: QMutex::unlock() (qmutex.cpp:368)
==6192== by 0x838C464: DlgAutoDJ::qt_metacall(QMetaObject::Call, int, void**) (moc_dlgautodj.cc:103)
==6192== by 0x69546B9: QMetaObject::metacall(QObject*, QMetaObject::Call, int, void**) (qmetaobject.cpp:237)
==6192== by 0x69644FE: QMetaObject::activate(QObject*, QMetaObject const*, int, void**) (qobject.cpp:3287)
==6192== by 0x8387BB6: ControlObjectThread::valueChanged(double) (moc_controlobjectthread.cc:91)
==6192== by 0x5D7BCFF: QApplicationPrivate::notify_helper(QObject*, QEvent*) (qapplication.cpp:4458)
==6192== by 0x5D808CD: QApplication::notify(QObject*, QEvent*) (qapplication.cpp:3862)
==6192== by 0x694E0BA: QCoreApplication::notifyInternal(QObject*, QEvent*) (qcoreapplication.cpp:731)
==6192== by 0x6951C78: QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) (qcoreapplication.h:215)
==6192== by 0x6951E0C: QCoreApplication::sendPostedEvents(QObject*, int) (qcoreapplication.cpp:1265)
==6192== by 0x697B3C3: postEventSourceDispatch(_GSource*, int (*)(void*), void*) (qcoreapplication.h:220)
==6192== by 0x75E0AA7: g_main_context_dispatch (in /lib/i386-linux-gnu/libglib-2.0.so.0.2800.6)
==6192== by 0x75E126F: ??? (in /lib/i386-linux-gnu/libglib-2.0.so.0.2800.6)
==6192== by 0x75E1523: g_main_context_iteration (in /lib/i386-linux-gnu/libglib-2.0.so.0.2800.6)
==6192== by 0x697B53B: QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventdispatcher_glib.cpp:422)
==6192== by 0x5E321E4: QGuiEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qguieventdispatcher_glib.cpp:204)
==6192== by 0x694D288: QEventLoop::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:149)
==6192== by 0x694D521: QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) (qeventloop.cpp:201)
==6192== by 0x6951ECB: QCoreApplication::exec() (qcoreapplication.cpp:1008)
==6192== by 0x5D798E6: QApplication::exec() (qapplication.cpp:3736)
==6192== by 0x8148E9D: main (main.cpp:299)
==6192==

[Daniel Schürmann (daschuer)]

In my first patch was a segfault at ~Soundmanager().
Fixed some memory issues at the library scanner.

[RJ Skerry-Ryan (rryan)]

These are great, thanks Daniel!

[Daniel Schürmann (daschuer)]

Attached you will find an updated patch for the current trunk lp:mixxx #2883

[RJ Skerry-Ryan (rryan)]

Hey Daniel,

Just going through the diffs. Is this one a typo?

mixxx/src/recording/defs_recording.h
-#define SIZE_4GB 4000000000 //bytes
+#define SIZE_4GB 4000000000l //bytes

[RJ Skerry-Ryan (rryan)]

Added the patch minus the SIZE_4GB edit. Thanks Daniel!

[Daniel Schürmann (daschuer)]

Hey RJ,

it was not a typo.

On some systems this macro causes this compiler warning:

"warning: this decimal constant is unsigned only in ISO C90"

It seems the warning is only issued with the 32 bit version of gcc.

[RJ Skerry-Ryan (rryan)]

Doh, I misread that as adding an additional 1 not 'l'. Sounds good --
I'll add that as well

2011/10/17 Daniel Schürmann <email address hidden>:
> Hey RJ,
>
> it was not a typo.
>
> On some systems this macro causes this compiler warning:
>
> "warning: this decimal constant is unsigned only in ISO C90"
>
> It seems the warning is only issued with the 32 bit version of gcc.
>
> --
> You received this bug notification because you are a member of Mixxx
> Development Team, which is subscribed to Mixxx.
> https://bugs.launchpad.net/bugs/816679
>
> Title:
>  sealing  some leaks
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/mixxx/+bug/816679/+subscriptions
>

[Jens Nachtigall (nachtigall)]

do
./mixxx -h
to see what I mean. puts adds an \n to a string but printf does not.

due to http://bazaar.launchpad.net/~mixxxdevelopers/mixxx/trunk/revision/2888#mixxx/src/main.cpp
printf was replaced by puts. This is probably a due to some warning by valgrind?! because the above commit fixes https://bugs.launchpad.net/mixxx/+bug/816679

I do not know what's valgrind's problem with printf? After googling a bit, I think it is a valgrind bug, but I do not know.

anyway, attached a patch to revert the replacement of puts --> printfs (I do not know bzr in detail maybe you can also simply revert the changes what witch the above commit to main.cpp.

[Jens Nachtigall (nachtigall)]

valgrind and puts and printf
http://stackoverflow.com/a/8024540
but as said before I am not totally sure

[Swiftb0y (swiftb0y)]

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