C++


C++DebuggingProgrammierenMartin Richter - Do 05 Dez 2013 18:33

… oder auch: Es gibt Tage, da könnte man sich in der Tischplatte verbeißen…

Wir haben vor ein paar Wochen einen sehr mystischen Fehler in unserer Software gefunden.
Das Problem war eine Funktion, die einen (const) Zeiger auf einen Datenblock bekam.
Die Funktion hat aber unter Umständen eine UI-Interaktion (Dialog) ausgelöst und die entsprechende offene Nachrichtenschleife hat es wiederum einen Hintergrundthread erlaubt (unter bestimmten Umständen) Nachrichten an den Mainthread zu senden, der wiederum die Anzeige aktualisierte und auch den Datenblock, der eben noch als Zeiger übergeben wurde, ungültig machte.

Die Funktion sah in etwa so aus:

bool CSomeClass::SomeAction(const S_FOO *pData)
{
...

pData war nun ungültig und wurde verändert, war aber immer noch gültiger Speicher in dem ein paar Ids aus einer Datenbank standen. Das Programm stürzte nicht ab. Tat aber aufgrund der falschen Ids auch nicht das, was es eigentlich sollte.

Der Code wurde dann wie folgt geändert und ein entsprechender Kommentar geschrieben:

bool CSomeClass::SomeAction(const S_FOO &data)
{
// We use a copy of the result object. There is a chance that the
// global result gets replaced while we are inside this routine and 
// the storage where our pointer points gets deleted and replaced 
// by a new result object.
...

Oha. Aber was passierte hier. Anstatt wirklich eine Kopie zu verwenden, wurde wieder nur ein Zeiger verwendet. Nur diesmal in Form einer Referenz.

Es wird nun niemanden wundern., dass mir die selbe Fehlebeschreibung wieder auf den Tisch flatterte. Im Debugger  wurden die selben Probleme festgestellt und ich musste dreimal auf die Code-Zeile schauen und den Kommentar dreimal lesen, bevor ich verstand was hier geändert wurde.

  • Fehler erkannt.
  • Fehler dokumentiert.
  • Fehler aber nicht gefixed.

So hätte es aussehen müssen:

bool CSomeClass::SomeAction(const S_FOO data)
{
...

PS: Ich oute mich mal. Der Trottel war ich…

C++ProgrammierenVS 2013Martin Richter - Do 17 Okt 2013 22:47

Heute ist Visual Studio 2013 verfügbar gemacht worden.

Weitere Infos finden sich im VC++ Blog und in Somasegar’s Blog:
http://blogs.msdn.com/b/vcblog/archive/2013/10/17/visual-studio-2013-available-now.aspx
http://blogs.msdn.com/b/somasegar/archive/2013/10/17/visual-studio-2013-available-for-download.aspx

 

C++DebuggingMFCVista / Windows 7Windows APIMartin Richter - Sa 24 Aug 2013 12:08

Bei der Entwicklung von neuen Funktionen in einem Modul bekam ich irgendwann einen ASSERT. Diesen ASSERT hatte ich in einem Cache eingebaut. Der ASSERT sprang an, wenn bei Programmende der Cache nicht sauber aufgeräumt wurde. Also eigentlich in der Entwicklungsphase nichts ungewöhnliches. Irgendwo wurde also eine Funktion zum Aufräumen nicht aufgerufen.

Aber was mich in diesem Moment extrem stutzig machte, war, dass in der Debugausgabe meines VisualStudios keine Memory Leaks angezeigt wurden ❗ Das machte irritierte mich nun schon sehr. Erster Verdacht. Evtl. hat ja jemand die Leakprüfung für den Cache ausgeschaltet (siehe AfxEnableMemoryTracking). Aber eine kurze Prüfung ergab, dass dem nicht so ist.

Also den Test noch mal ausgeführt. Diesmal wieder der ASSERT und zusätzlich der Dump. „Oha“ dachte ich „Hier ist aber was richtig faul!“

Nachdem ich immer wieder andere Testszenarien verwendet habe, erschienen mal die Leaks und mal erschienen sie nicht. Und nach einiger Zeit kaum ich dahinter, dass immer wenn PlaySound in meiner Debug Version der Anwendung verwendet wurde, kein Leak-Check erfolgte. Wurde PlaySound nicht verwendet war alles gut und die Leaks wurden ausgegeben.

Jetzt ging es ans eingemachte. Schnell isolierte ich folgende DLLs die zusätzlich beim ersten PlaySound geladen wurden.

'xyz.exe': Loaded 'C:\Windows\SysWOW64\MMDevAPI.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\propsys.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\wdmaud.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\ksuser.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\avrt.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\setupapi.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\cfgmgr32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\devobj.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\AudioSes.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.drv', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\msacm32.dll', Symbols loaded (source information stripped).
'xyz.exe': Loaded 'C:\Windows\SysWOW64\midimap.dll', Symbols loaded (source information stripped).

Und nach etwas weiter debuggen kam ich dahinter, dass der DllMain Code von setupapi.dll beim DETACH_PROCESS den Prozess sofort terminiert und nicht alle DLLs einen DETACH_PROCESS Aufruf erhalten. Aber der Code für die Leak-Detection der MFC liegt in der MFCx.DLL und wird durch eine statische Variable ausgelöst, die beim Entladen der MFCx.DLL dann zur Ausgabe der Speicherlecks führt. (Siehe PROCESS_LOCAL(_AFX_DEBUG_STATE, afxDebugState) und AfxDiagnosticInit).

Eine genauere Analyse des Stacktraces ergab folgendes Bild:

ntdll.dll!_ZwTerminateProcess@8()  + 0x5 bytes	
ntdll.dll!_RtlpWaitOnCriticalSection@8()  + 0x1d38f bytes	
ntdll.dll!_RtlEnterCriticalSection@4()  + 0x16a38 bytes	
setupapi.dll!_pSetupInitGlobalFlags@4()  + 0x1fc bytes	
setupapi.dll!_pSetupGetGlobalFlags@0()  + 0xe2 bytes	
setupapi.dll!_FlushWVTCache@0()  + 0x2f bytes	
setupapi.dll!_DestroyDeviceInfoSet@8()  + 0x3f bytes	
setupapi.dll!_SetupDiDestroyDeviceInfoList@4()  + 0x44 bytes	
MMDevAPI.dll!CDeviceEnumerator::FinalRelease()  + 0x78 bytes	
MMDevAPI.dll!ATL::CComObjectCached::~CComObjectCached()  + 0x3c bytes	
MMDevAPI.dll!ATL::CComObjectCached::`scalar deleting destructor'()  + 0xd bytes	
MMDevAPI.dll!ATL::CComObjectCached::Release()  + 0xf0c6 bytes	
MMDevAPI.dll!ATL::CComClassFactorySingleton::~CComClassFactorySingleton()  + 0x18 bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::`scalar deleting destructor'()  + 0x1a bytes	
MMDevAPI.dll!ATL::CComObjectNoLock<ATL::CComClassFactorySingleton >::Release()  + 0xe0e3 bytes	
MMDevAPI.dll!ATL::CAtlComModule::Term()  + 0x27 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x26e6 bytes	
MMDevAPI.dll!__CRT_INIT@12()  + 0x2588 bytes	
ntdll.dll!_LdrpCallInitRoutine@16()  + 0x14 bytes	
ntdll.dll!_LdrShutdownProcess@0()  + 0x141 bytes	
ntdll.dll!_RtlExitUserProcess@4()  + 0x74 bytes	
kernel32.dll!75eb7a0d() 	
msvcr100d.dll!__crtExitProcess(int status=0)  Line 709	C
msvcr100d.dll!doexit(int code=0, int quick=0, int retcaller=0)  Line 621 + 0x9 bytes	C
msvcr100d.dll!exit(int code=0)  Line 393 + 0xd bytes	C
xyz.exe!__tmainCRTStartup()  Line 568	C

Ursache war, dass MMDevAPI.DLL in seinem DllMain Code ausführt in der setupapi.dll, die aber bereits den DETACH_PROCESS abgearbeitet hat. Das grundsätzliche Problem wird hier in diesem Blog Artikel geschildert: http://blogs.msdn.com/b/oldnewthing/archive/2005/05/23/421024.aspx
Mit eigenen Worten: Die MMDevAPI.dll ruft Funktionen in einer DLL auf, die bereits alle Ihren Speicher und Ressourcen freigegeben hat. Und wie es hier im Code so aussieht, versucht die SetupAPI.DLL wieder Ressourcen zu akquirieren, die eben bereits schon freigegeben wurden, weil eine DLL sie erneut benutzt.

Die Folge ein „Crash“ in DllMain, die der Windows-Lader aber abfängt und sofort mit einer Terminierung des Prozesses ahndet. D.h. nun aber, dass nicht alle DLLs, die noch einen DllMain Aufruf mit DETACH_PROCESS erhalten müssten,  auch an die Reihe kommen.

Etwas weitere Recherche ergab, dass dieses Problem auch in den MSDN Foren bereits diskutiert wurde inkl. einer möglichen Lösung.
http://social.msdn.microsoft.com/Forums/vstudio/en-US/8cb1847d-3218-4610-9cb8-6905bd255ff5/no-dllprocessdetach-after-calling-playsound-on-windows-7-64bit

Die Lösung ist erstaunlich einfach: Wenn vor der Benutzung von PlaySound explizit die SetupAPI.DLL geladen wird, dann verläuft der Rest der Deinitialisierung vollkommen normal. SetupAPI.DLL wird nicht entladen, weil die DLL durch den LoadLibrary Aufruf die DLL im Speicher sperrt. MMDevAPI.DLL kann erfolgreich selbst aufräumen und der Code läuft nicht mehr ins Nirvana.

Hier handelt sich offensichtlich um einen Bug in Windows 7 (Windows 8 konnte ich dies bzgl. nicht testen).
Dieser Bug kann natürlich auch empfindlichere Probleme mit sich bringen, wenn Ressourcen betroffen sind, die nicht automatisch mit Prozessende freigegeben werden und wenn diese Ressourcen ausschließlich in der DllMain bei einem DETACH_PROCESS behandelt werden.

ATLC++CRTMFCProgrammierenVS 2013Martin Richter - Mi 21 Aug 2013 17:32

Im Microsoft C++ Team Blog kann nachgelesen werden was sich in ALT+MFC in VS-2013 tun wird:
http://blogs.msdn.com/b/vcblog/archive/2013/08/20/atl-and-mfc-changes-and-fixes-in-visual-studio-2013.aspx

Wer hätte es gedacht…, ja es gibt wieder etwas „Neues“, auch wenn es mehr oder weniger nur Bugfixes sind.

Besonders erwähnenswert ist der Wegfall des MBCS Supports in der MFC, siehe auch hier.
Das die ATL jetzt nur noch als statische Bibliothek mit sehr kleinem Footprint existiert ist nett. Warum eigentlich nicht gleich so?

Nachtrag und Korrektur durch den aufmerksamen Blog-Leser Sasche:

Wie auch im verlinkten Artikel beschrieben, fällt der MBCS Support in VS-2013 noch nicht weg, sondern ist erst mal nur “deprecated” (und die entsprechenden Libs nur noch als separater Download verfügbar). Erst in einer Folgeversion soll der Support für MBCS ganz wegfallen.

 

C++ProgrammierenVS 2012Martin Richter - Do 27 Jun 2013 18:07

Das Update 3 für VisualStudio 2012 wurde gestern veröffentlicht.

http://support.microsoft.com/kb/2835600/en-us
http://blogs.msdn.com/b/vcblog/archive/2013/06/27/what-s-new-for-visual-c-developers-in-vs2013-preview.aspx
http://blogs.msdn.com/b/visualstudio/archive/2013/06/26/visual-studio-2013-preview-available-now.aspx
http://visualstudiomagazine.com/articles/2013/06/26/update-3-of-visual-studio-2012-released.aspx

Damit ist die Regression aus dem Update 2 endgültig behoben. Mit Update 1 konnte man wieder Programme bauen, die auch auf Windows XP laufen. Update 2 machte dies wieder zunichte.

Siehe auch:
http://connect.microsoft.com/VisualStudio/feedback/details/783137/visual-studio-2012-update-2-rtw-breaks-xp-targeting-with-c-when-statically-linking-mfc-and-atl
http://tedwvc.wordpress.com/2013/04/14/how-to-get-visual-c-2012-update-2-statically-linked-applications-to-run-on-windows-xp/
http://blogs.msdn.com/b/vcblog/archive/2013/05/07/fix-visual-studio-2012-update-2-breaks-windows-xp-targeting-with-atl-and-or-statically-linking-mfc.aspx

Zeitgleich wurde auch ein Preview auf VS-2013 veröffentlicht.
http://blogs.msdn.com/b/visualstudio/archive/2013/06/26/visual-studio-2013-preview-available-now.aspx

C++CRTProgrammierenMartin Richter - Do 20 Jun 2013 21:15

Mathe ist ja eigentlich ganz einfach. Die nachfolgende Routine berechnet die kürzeste Distanz zwischen zwei Punkten auf der Erde unter der Berücksichtigung, dass die Erde eine perfekte Kugel ist.
Benutzt wird diese Routine um die Luftlinie zwischen zwei geokodierten Adressen zu ermitteln.

double DistanceBetweenCoordinates(
          double dLatitude1, double dLongitude1, 
          double dLatitude2, double dLongitude2)
{
  // Convert to radient
  dLatitude1 *= M_PI / 180;
  dLongitude1 *= M_PI / 180;
  dLatitude2 *= M_PI / 180;
  dLongitude2 *= M_PI / 180;
 
  // Get distance
  double dDistance;
  dDistance = sin(dLatitude1) * sin(dLatitude2) + cos(dLatitude1) * 
        cos(dLatitude2) * cos(dLongitude2-dLongitude1);
  // Ohne diese Zeile haben wir ein Problem... dDistance ist evtl. >1
  // dDistance = min(dDistance,1.0);
  dDistance = acos(dDistance) * EARTH_RADIUS;
  return dDistance;
}

Eigentlich ganz einfach. Aber dieser Code hat ein massives Problem, denn dDistance kann vor dem acos durch Rundungsfehler größer als 1 werden.

Für die folgenden Werte passiert etwas Übles:

dLatitude1 0.86208095750908087 
dLongitude1 0.15333764167657613 
dLatitude2 0.86208095750908087 
dLongitude2 0.15333764167657613

Eigentlich müsste glatt 1 herauskommen, denn die Koordinaten sind gleich, aber dDistance wird bei diesen Werten 1.0000000000000002. Der Sinus bzw. Cosinus ergibt eben doch leicht abweichende Werte. Der folgende acos scheitert dann aber und das Resultat wird NaN (Not a Number). Erlaubt sind natürlich nur Werte <=1.0 und >=-1.0. Die Folge ist, dass die Distanz nicht 0.0 ist.

Also muss hier eine kleine Sicherung eingebaut werden, die Aufgrund der Rundungs-Genauigkeitsfehler, das überschreiten von 1 verhindert.
Eigentlich ist Mathe ganz einfach, aber auf einem Rechner ist das alles manchmal ganz anders.

PS: Ich weiß schon warum ich noch nie Fließkommaarithmetik auf PCs mochte.

C++CommunityProgrammierenMartin Richter - Do 20 Jun 2013 17:35

<Ironie>Mittlerweile frage ich mich ob Microsoft überhaupt noch eine Community will.</Ironie>
Ja sicher wollen sie das und sagen und versichern tun das auch alle Offiziellen immer und überall. Das nehme ich Ihnen sogar ab. Aber mit der Umstellung der Forensoftware haben sie sich wohl eher einen Bärendienst geleistet. Und mit dieser „neuen“ eigenen MSDN-Forenplattform werden Sie kaum Bäume ausreißen.

Die HTTP Foren wurden nun ein weiteres Mal umgestellt und sind nun – aus meiner persönlichen Sicht – gar nicht mehr zu bedienen.
Weiterhin bezweifle ich stark, dass sich mit dieser neuen Forensoftware wirklich viele Nutzer anfreunden können. Es ist einfach auf den ersten, zweiten und dritten Blick viel zu undurchschaubar und chaotisch. Man findet alles mögliche, nur nicht das was man sucht. Die Übersicht über Meine Foren, ist kaum zu gebrauchen, alte nicht mehr existente Einträge lassen sich nicht entfernen. Meine Forenthreads fehlt ganz! Es ist extrem kompliziert zwischen den deutschen und englischen Forenbereichen zu wechseln. Ich verirre mich immer in den deutschen, englischen, Technet, MSDN Seiten. Tausend Foren und Bereiche aber keine Übersicht. Optische großflächige Schalter rauben den Raum für eigentliche Informationen. Es muss ja jetzt alles „flat“ sein.
Ich verstehe nicht, warum Filter den Vorzug vor klaren Baumstrukturen bekommen?

Von den Bugs will ich gar nicht reden: „Leider kann Ihre Anforderung nicht bearbeitet werden.“ , „Es wurden keine Ergebnisse gefunden.“, Links Führen ins leere, Administrative Funktionen melden Serverfehler. Die NNTP-Bridge arbeitet nicht. Es gehen wieder Gerüchte um, dass die Bridge ganz eingestellt wird. :(

DAS macht keinen Spaß. Ich muss mir stark überlegen, ob ich hier überhaupt noch vorbei schauen soll.
Aber da sich hier seit „Zerstörung“ der NNTP Foren auch keine neue Community gebildet hat, ist das wohl auch kein großer Verlust: Der letzte macht dann mal das Licht aus…

C++CRTProgrammierenVS 2012Martin Richter - Mo 20 Mai 2013 17:58

In einem Note in meinem Blog wurde es ja auch erwähnt, das Update 2 zu Visual Studio 2012 eine Regression hat. Mit Update 1 konnte man wieder Programme bauen, die auch auf Windows XP laufen. Update 2 machte dies wieder zunichte. Jetzt ist ein RC für Update 3 verfügbar gemacht worden mit dem dieser Fehler behoben wurde.

Hier die Ankündigung im C++ Blog:
http://blogs.msdn.com/b/vcblog/archive/2013/05/07/fix-visual-studio-2012-update-2-breaks-windows-xp-targeting-with-atl-and-or-statically-linking-mfc.aspx

C++ProgrammierenSoftwareToolsMartin Richter - Do 02 Mai 2013 18:11

Ich hatte ja schon mehrfach in meinem Blog auf CPPDepend hingewiesen. Ein tolles Tool für die Code Analyse.

Jetzt gibt es eine kostenlose Version für alle Open-Source-Entwickler.
Mehr dazu findet sich in diesem Link, schaut einmal selbst ob die Lizenzbedingungen für Euch in Frage kommen könnten.

Um in den Genuss einer solchen Lizenz zu kommen muss man eigentlich nur seinen Namen und den Link auf das Projekt an Support@cppdepend.com senden. Einfacher geht es nicht 😉

C++CommunityProgrammierenMartin Richter - So 28 Apr 2013 16:10

Sie steht schon vor der Tür, die Advanced C++ Conference 2013 in Bad Aibling vom 06. bis 08. Mai.

Leider bin ich diesmal nicht von der Partie, aber ich hoffe, dass es genug Teilnehmer geben wird.
Es wäre schade, wenn diese C++ Konferenz mangels Teilnahme wieder verschwinden würde.
Ich kann nur sagen, dass sich die letzten beiden Konferenzen gelohnt haben.

Ich hatte es anders geplant, aber man hat über bestimmte Ressourcen, wie Gesundheit und Familie oft nicht die 100%ige Kontrolle. :(

« Vorhergehende SeiteNächste Seite »