Absurdes Programmverhalten

[Jonathan]

Ah das sieht gut aus. Hast du auch irgendwelche Tipps, wie ich einen boost-Debug build bekomme, der trotzdem /MD und nicht /MDd benutzt? Das ist ja Voraussetzung für Dr Memory, aber ich finde in der b2 Doku keinen Flag dazu.

[eXile]

Das müsstest du als cxxflags angeben können. Wenn du damit auf die Schnauze fliegst, weil Boost vielleicht doch im Debug-Build Features aus der Debug-CRT braucht, musst du wohl gegen die Release-Version von Boost im deinem Debug-Build zum Testen mit Dr. Memory linken.

Der Vollständigkeit halber mal meine nunmehr erweiterte Suppression-Datei:

Code: Alles auswählen

UNINITIALIZED READ
...
nvwgf2um.dll!*

POSSIBLE LEAK
...
nvwgf2um.dll!*

LEAK
...
nvwgf2um.dll!*

WARNING
...
nvwgf2um.dll!*



UNINITIALIZED READ
...
d3d11.dll!D3D11CreateDevice 

POSSIBLE LEAK
...
d3d11.dll!D3D11CreateDevice

LEAK
d3d11.dll!*



UNINITIALIZED READ
...
d3d11SDKLayers.dll!*



UNINITIALIZED READ
...
d3d10warpNoD3D9.dll!Ordinal50

LEAK
...
d3d10warpNoD3D9.dll!SetInfoQueue  

LEAK
d3d10warpNoD3D9.dll!D3D10RefGetLastCreation



UNINITIALIZED READ
...
d3d11ref.dll!OpenAdapter10_2

UNINITIALIZED READ
d3d11ref.dll!D3DKMTCreateContext



UNINITIALIZED READ
...
dxgi.dll!*

POSSIBLE LEAK
...
dxgi.dll!*

LEAK
dxgi.dll!*



UNINITIALIZED READ
...
D3DCOMPILER_43.dll!D3DDisassemble10Effect



UNINITIALIZED READ
...
XINPUT1_3.dll!XInputGetKeystroke



UNINITIALIZED READ
USER32.dll!GetClassLongW



UNINITIALIZED READ
ntdll.dll!RtlAllocateHeap
MSVCR100.dll!malloc
MSVCR100.dll!operator new
*!std::_Tree_val<*

LEAK
ntdll.dll!RtlRunOnceBeginInitialize



INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<std::locale>
*!std::basic_streambuf<char,std::char_traits<char> >::~basic_streambuf<char,std::char_traits<char> >

INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<_RTL_CRITICAL_SECTION>
*!std::_Mutex::~_Mutex
*!std::basic_streambuf<char,std::char_traits<char> >::~basic_streambuf<char,std::char_traits<char> >

INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<std::locale>
*!std::ios_base::_Ios_base_dtor

INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<std::locale::facet>
*!std::_Fac_node::~_Fac_node

INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<std::_Fac_node>
*!_Fac_tidy

INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<void>
*!std::numpunct<char>::_Tidy

INVALID HEAP ARGUMENT
*!std::_DebugHeapDelete<std::locale::facet>
*!_Deletegloballocale

Da fragt man sich so langsam, warum Computer überhaupt noch booten. :|

[Jonathan]

Danke. Nach endlosen rumprobieren, aufgeben und wieder neu Anfangen hab ich es jetzt geschafft. Die hätten ja ruhig dabei schreiben können, das vor den Falgs ein - stehen muss... So gings jedenfalls:

b2 serialization cxxflags=-MD link=static variant=debug,release

[Jonathan]

Ich hänge leider immer noch fest. Ich konnte jetzt mein Programm mit allen Abhängigkeiten so kompilieren, dass die Release Runtime (/MD) benutzt wird. Allerdings kann ich es immer noch nicht Debuggen und DependencyWalker zeigt mir an, dass mein programm sowohl die Debug als auch die Release Runtime benötigt.
Jetzt habe ich also zum einen sichergestellt, dass die Releasebibliotheken von boost benutzt werden (hattest ja erwähnt, es könnte da Abhängigkeiten geben) und zum anderen die Linkereingabe angeschaut. Da wird jetzt eigentlich nichts mehr in der Debugversion gelinkt, was ich vorher nicht selber mit /MD kompiliert habe, aber trotzdem bleibt die Abhängigkeit zur Debugruntime.
Irgendwelche Ideen, wie ich herausfinden kann, wie diese Abhängigkeit zustande kommt?

[edit]Hat sich erledigt: Man musste für alle Projekte /Md einstellen und sichergehen, dass _Debug nicht definiert ist. Eigentlich habe ich ersteres in CMake für alle Projekte global eingestellt, letzteres für jedes Projekt eingestellt. Aber irgendwie hatte glew trotzdem die Debugruntime. Naja, jetzt scheint es zu gehen.[/edit]

[Jonathan]

Nochmal ein kurzer Nachtrag:
Das mit glew lag daran, dass es ein C-Programm ist. In CMake hatte ich aber nur die CXXFlags gesetzt. Zur Übersicht:

CMAKE_CXX_FLAGS_DEBUG : "/D_DEBUG" löschen und aus "/MDd" ein "/MD" machen
CMAKE_C_FLAGS_DEBUG : genau das selbe