Jammer-Thread

[Krishty]

COLLADASaxFrameworkLoader/src/generated15/COLLADASaxFWLColladaParserAutoGen15PrivateValidation.cpp

[antisteo]

Ich war zu feige, vor einem Jahr in Bitcoins zu investieren.

[Artificial Mind]

Not Quite Unignorable Warnings

For some warning numbers, specification in a /ignore option is accepted but not necessarily acted upon. Should the warning occur while the /wx option is not active, then the warning message is still displayed, but if the /wx option is active, then the warning is ignored. It is as if the warning is thought important enough to override an attempt at ignoring it, but not if the user has put too high a price on unignored warnings.

The following warning numbers are affected:

4200, 4203, 4204, 4205, 4206, 4207, 4208, 4209, 4219, 4231 and 4237

Und nun stellt euch das mal mit einem Buildserver vor, der auch auf Warnings achtet.

[Helmut]

Windows 8 hat mir jetzt zwei Nächte den Schlaf geraubt, indem es mitten in der Nacht den Ruhezustand unterbricht und dann die Musik fortsetzt.
Hab jetzt herausgefunden, dass das ein Feature ist und "Wartung" nachts durchgeführt wird. Um's abzuschalten siehe hier.

[antisteo]

Die machen dasselbe wie ich in meiner Masterarbeit http://llvm.org/devmtg/2013-11/slides/W ... oudera.pdf

Naja, ich steck's einfach mit in die Literaturliste. Ich bau's ja für 'ne andere Datenbank, also ists ja legitim.

[antisteo]

Mit jedem Schritt in Richtung Spieleentwicklung kommen die Erinnerungen wieder hoch und die Motivation ist weg.
Jetzt habe ich ein OpenGL-ES-Dreieck auf dem Raspberry Pi laufen, das die Farben der Ecken rotiert. Daraus werden soll eigentlich ein Scenegraph-Streaming-Client, der Szenen aus verschiedenen Blickwinkeln wiedergeben kann, was vor allem in Simulatorparks interessant ist.

[antisteo]

Welche Probleme man bekommt, wenn man Programme für Windows-Server entwickelt ...


http://www.lazarusforum.de/viewtopic.php?f=55&t=7406

[dot]

Welche Probleme man bekommt, wenn man Programme für Windows-Server entwickelt ...


http://www.lazarusforum.de/viewtopic.php?f=55&t=7406

So wie ich das versteh, sitzen die dort angesprochenen "Probleme" zwischen Tastatur und Bildschirm!?

[antisteo]

Vielleicht ist es für mich auch eine andere Kultur, wenn Server GUIs haben, aber man läuft doch ständig in Gefahr, dass irgendein Admin das Fenster schließt und der Service dadurch nicht mehr läuft ....

[Chromanoid]

Das ist dann falsch programmiert. Es gibt ja nicht umsonst Windows Services. GUIs können/sollten dann natürlich nur mittels irgendeiner IPC Variante mit den Services quatschen. Siehe auch http://msdn.microsoft.com/en-us/library ... s.85).aspx

[antisteo]

Das ist dann falsch programmiert. Es gibt ja nicht umsonst Windows Services. GUIs können/sollten dann natürlich nur mittels irgendeiner IPC Variante mit den Services quatschen. Siehe auch http://msdn.microsoft.com/en-us/library ... s.85).aspx

Das ist doch viel zu viel Aufwand. Da kannst du ja gleich ein Web-Konfigurationsinterface bauen. wozu braucht man dann noch Windows Server? Der Vorteil von Windows Server ist doch gerade die Verwendung von GUIs, was so einiges in der Programmierung vereinfacht. Mann kann rein theoretisch sogar VisualStudio auf dem Server laufen lassen und über RDP coden.

[Chromanoid]

Nein, das ist kaum mehr Aufwand. Es verpflichtet einfach zu einem gewissen Standard. Es geht lediglich darum ein spezielles Interface zu implementieren, damit der Service von der Service-Verwaltung gesteuert werden kann. Das ist dann nämlich schon ein großer und wichtiger Teil der GUI. Genau das macht es doch so schön bequem Dienste unter Windows zu verwalten. Windows Server ist ein Windows für den Betrieb als Server und hat nichts damit zu tun, dass man dann plötzlich Dienste mittels Windows Forms o.Ä. zusammenklicken kann.

[Krishty]

Diese Leute, die in C++ Speicheranforderungen so verfolgen:

  #define new new (__FILE__, __LINE__)
  void * operator new (size_t size, char const * file, int line) { …

… haben alles völlig verfehlt. (I'm looking at you, MFC!)

Zuerst einmal zerstört dieses kack #define alles: Fremde Header (wie etwa <d3dx9.h>), Placement new, eigene new-Überladungen. Es ist eine Massenvernichtungswaffe.

Zum anderen ist es nutzlos. Das new steckt selten an der Stelle wo das Speicherleck auftritt, sondern in einer Hilfsfunktion – in einer Smart-Pointer-Implementierung, in einer Containerklasse, usw usf. Was bringt es mir, zu wissen, dass Property::Property(int *) leckt, wenn ich 200 Aufrufe davon im Quelltext verstreut habe?! Absolut garnichts.

Hier ist, wie man es richtig® macht:

1. Kein #define. Schmeißt diesen Scheiß weg.

2. In eurem Operator new speichert ihr nicht wie sonst Dateinamen und Zeilennummer vor dem eigentlichen Speicherinhalt, sondern die Aufrufliste:

  struct CallStack {
    void const * callees[16];
  };

Die füllt ihr durch einen Aufruf von RtlCaptureStackBackTrace(). Weil diese Funktion in Kernel32.dll liegt, und das unter Windows sowieso immer eingebunden wird, braucht ihr sie einfach nur deklarieren und nicht etwa das Driver SDK installieren:

  unsigned short __stdcall RtlCaptureStackBackTrace(
    unsigned long   FramesToSkip,
    unsigned long   FramesToCapture,
    void const * *  BackTrace,
    unsigned long * BackTraceHash
  );

  …

  CallStack const currentCallStack(
    unsigned const howManyCalleesToSkip
  ) {
    CallStack result = { }; // zero unused slots

    RtlCaptureStackBackTrace(
      howManyCalleesToSkip,
      unsigned(sizeof result.callees / sizeof result.callees[0]), result.callees,
      nullptr // no need to hash anything
    );

    return result;
  }

Dabei sollten die höchsten beiden Aufrufe übersprungen werden (howManyCalleesToSkip == 2), weil die sonst immer currentCallStack und operator new wären, und das ist uns sowieso klar.

3. Wenn ihr am Ende eure Speicherlecks auflistet, gebt ihr die Aufrufliste aus. Und zwar als Verweise auf Quelldateien in den Debugger. Denn dann könnt ihr via Klick auf die IDE einfach so durchspringen. Daran kommt ihr via SymGetLineFromAddrW64():

  for(auto const callee : callStack.callees) {
    if(nullptr == callee) { // Bottom of call stack?
      break;
    }
    IMAGEHLP_LINE64 information;
    information.SizeOfStruct = sizeof information;
    DWORD displacement = 0;
    if(1 == SymGetLineFromAddrW64(GetCurrentProcess(), address, &displacement, &information)) {
      wchar_t buffer[65536 + 10];
      sprintf(buffer, "      %s (%d)\n", information.FileName, information.LineNumber);
      OutputDebugStringW(buffer);
    }
  }

und jetzt ist eure Speicherleck-Ausgabe:

leaking 362 KiB through
    memory.cpp (96)
    memory.hpp (56)
    windows rawinput.cpp (1330)
    windows windowconcepts rawinput.hpp (195)
    windows windowwithcontext.hpp (162)
    session.cpp (708)
    main.cpp (106)

Wenn ich mich durchklicke sehe ich in drei Sekunden, dass ich einen Puffer für die Joystick-Eingaben nicht freigegeben habe. Und dabei habe ich nicht 50 Header zerstört oder globale #includes hinzugefügt.

Und vergesst nicht SymInitialize(GetCurrentProcess(), nullptr, TRUE); bevor ihr die Auflistung beginnt. Bitteschön!

[dot]

Sehr nice, sowas wollt ich mir schon ewig mal basteln um meinen Exceptions einen Stack Trace anzuhängen... :)

Ich nehme an, das Ganze benötigt .pdf Files, damit es funktioniert!? Funktioniert es auch mit Frame-Pointer Omission (/Oy)?

[Krishty]

.pdb? Ja. Jemand hat im Internet geschrieben, dass man dafür auch mit Profiling-Information kompilieren müsse, aber bei mir funktioniert es auch ohne (32- und 64-Bit Debug).

Bisher benutze ich es nur für Debugging; darum weiß ich nicht, wie es sich mit /Oy verhält. Ich nehme an, dass Visual Studio aber die gleiche Methode benutzt um den Call Stack anzuzeigen (es ist schließlich die Debugging-API); bestenfalls liefert es also immer dann einen Call Stack, wenn Visual Studio es auch schafft.

[eXile]

Die Erschaffer vom Visual Leak Detector haben etwas ähnliches implementiert, und zwar in zwei Varianten:

• FastCallStack::getStackTrace benutzt ebenfalls RtlCaptureStackBackTrace, aber via GetProcAddress aus der ntdll.dll geholt
• SafeCallStack::getStackTrace benutzt das wohl sehr viel lahmere StackWalk64 aus der dbghelp32.dll

Die Ausgabe des Dateinamens und der Zeilennummer erfolgt auch via SymGetLineFromAddrW64. Die Ausgabe der Funktion geht über SymFromAddrW, und die Ausgabe des Modulnamens über VirtualQuery.

Der VLD benutzt allerdings _CrtSetAllocHook (statt #defines) um die ::operator new abzufangen.

Übrigens sind mir auch keine anderen Möglichkeiten zum Memory-Logging bekannt, außer eben erstens der #define-Methode, zweitens der von VLD verwendeten _CrtSetAllocHook-Methode und drittens einfach dem Schreiben eines ersetzenden ::operator news (mit beispielsweise Callstack-Logging). Wer noch eine kennt, möge sie bitte hier bekanntgeben. ;)

[Jonathan]

Der englische Wikipediaartikel von Taylor Swift (den ich nur überflogen habe, weil ich wissen wollte, wer zum Geier das sein soll) hat unglaubliche 492 Literaturreferenzen. Als kleiner Vergleich: Der von Max Planck hat 26 Referenzen.

Ein bisschen beunruhigend ist es ja schon, wie detailliert Dinge dokumentiert sind, die in 5 Jahren für absolut niemanden mehr relevant sein werden.

[Chromanoid]

Wikipedia ist an vielen Stellen ziemlich schrecklich. Schau Dir mal den Artikel zur Spieleprogrammierung an: http://de.wikipedia.org/wiki/Spieleprogrammierung

[Krishty]

Im Debug-Build ist std::vector::operator[]() der Flaschenhals.

Wie schwer ist es für Microsoft, die Funktion sowohl sicher als auch schnell zu machen? Muss die so implementiert sein, dass die drei Iteratoren erzeugt, sperrt, wieder freigibt, und überprüft? Wirklich? m[

Zur Verteidigung: Ist ist VS 2012. Vielleicht haben sie das für 2013 verbessert. Wie Niki mir eben mitteilt, geht VS 2013 tatsächlich den kürzeren Weg und dürfte performanter sein :)

[antisteo]

Die Eclipse CDT sind so schlecht.
Wenn man in der Konsole hochscrollt, scrollt das Fenster runter, sobald eine neue Zeile kommt. Das nervt vor allem deshalb, weil ich nicht immer warten will, bis der Build-Prozess fertig ist.

Außerdem ist die Makefile-Generierung so grottig, dass man zig mal cleanen muss, bevor der Compiler alles so neu baut, dass auch die von mir gewollten Compilerfehler aufgrund von Code-Änderungen auftreten.

[Artificial Mind]

Folgender HLSL-Code:

Code: Alles auswählen

sin(x)

Für ca. x > 10000 gibt das auf der Intel HD4000 nur noch vier verschiedene Werte zurück (+-1 und ca. +- 0.3) während das auf NVIDIA Karten (auch low-end wie die 920 mobile) vernünftige Werte produziert.

Intel, Warum? :(

[Krishty]

Alle sin() und cos() der Welt sind falsch implementiert. Würde man vernünftige Ganzzahlparameter dafür benutzen käme die Problematik erst garnicht auf.

[Chromanoid]

Wenn man in der Konsole hochscrollt, scrollt das Fenster runter, sobald eine neue Zeile kommt. Das nervt vor allem deshalb, weil ich nicht immer warten will, bis der Build-Prozess fertig ist.

schon mal ausprobiert?

Bei Deinem anderen Problem gibt's bestimmt auch einen Trick.

[glassbear]

Die Eclipse CDT sind so schlecht.
Wenn man in der Konsole hochscrollt, scrollt das Fenster runter, sobald eine neue Zeile kommt. Das nervt vor allem deshalb, weil ich nicht immer warten will, bis der Build-Prozess fertig ist.

Da gibt es einen Scroll-Lock Button ;)

Außerdem ist die Makefile-Generierung so grottig, dass man zig mal cleanen muss, bevor der Compiler alles so neu baut, dass auch die von mir gewollten Compilerfehler aufgrund von Code-Änderungen auftreten.

Mhm, ich nutze hier Eclipse 3.7.2 mit CDT 8.0xx und das ist eines der wenigen Sachen, die wirklich funktionieren :oops:

[Krishty]

Ich wollte mir heute eine schlanke Windows-7-Installation zusammenstellen.

Für Windows XP gab es nLite – damit habe ich mir mal eine XP-Version zusammengestellt, die mit 42 MiB RAM und weniger als einem halben GiB Festplattenspeicher läuft.

Mit Windows 7 war das der totale Abschiss. Ich habe RT 7 Lite benutzt, das von einer Gruppe Vierzehnjähriger programmiert worden sein muss (man darf das Programm nicht abbrechen, sonst müssen stundenlang Temp-Ordner bereinigt werden; man will nur zum nächsten Bearbeitungsschritt, aber plötzlich wird eine Stunde lang die Festplatte umgeschichtet; …). Und nach dem vierten Anlauf (meine Einstellungen gingen immer verloren, trotz Speichern) hatte ich dann wirklich die absolut minimale Mini-Windows-7-Version ohne nutzlose Treiber, Dienste, Programme.

7,5 GiB statt 8,5.

CAPTAIN FANTASTIC DAS HAT SICH JA GELOHNT

[dot]

Ich wollte mir heute eine schlanke Windows-7-Installation zusammenstellen.

Gibt's schon fertig, heißt Windows 8 ;)

Edit: Ok 7.5 GiB sind nice, Windows 8 hat out of the box so in der Gegend von 20 iirc...

[Krishty]

Ich wollte mir heute eine schlanke Windows-7-Installation zusammenstellen.

Gibt's schon fertig, heißt Windows 8 ;)

DAS WAR NICHT WITZIG

[Sternmull]

Ich verstehe echt nicht was hier für seltsame Wege gegangen werden um Memory Leaks zu finden. Ich hab hier im Forum schon mehrmals darauf hingewiesen das man mit UMDH auch ohne speziellen Bibliothken oder sonstwie angepasstem Code oder Binaries die Leaks ohne großem Aufwand indentifizieren kann. Aber von mir aus bastelt euch den tausendsten Leak-Debugger...

[Krishty]

Vielleicht weil nicht jeder den Kernel-Debugger oder das Windows Driver Kit installiert hat?

[Sternmull]

Und weil man das nicht installieren will schreibt man sich lieber was eigenes? Das ist ja wirklich sehr produktiv. Soweit ich mich erinner kann man in dem Installer auch auswählen das man nur die Debugging-Tools installieren will. Da es ein "Web-Installer" ist, wird auch nur das runter geladen was man braucht. Kosten tut das Ding auch nichts.