2010-05-20 20 views
7

Ich habe eine Quelldatei in meinem Projekt, die mehr als 65.536 Code-Zeilen (112.444 um genau zu sein). Ich verwende eine "sqlite-Verschmelzung", die in einer einzigen großen Quelldatei enthalten ist.riesige C-Datei Debugging-Problem

Ich benutze MSVC 2005. Die Probleme kommen während des Debuggens. Alles kompiliert und verlinkt ok. Aber dann, wenn ich versuche, mit dem Debugger in eine Funktion zu treten - es zeigt eine falsche Codezeile.

Interessant ist, dass der Unterschied zwischen der richtigen Zeilennummer und dem, den der Debugger zeigt, genau 65536 ist. Dies lässt mich vermuten (fast sicher) einige unsigned kurzen Überlauf.

Ich vermute auch, dass es kein Fehler in der MSVC selbst ist. Vielleicht ist es die Begrenzung des Debug-Informationsformats. Das heißt, das von MSVC verwendete Debug-Informationsformat speichert die Zeilennummern als 2-Byte-Kurzschlüsse.

Kann man etwas dagegen tun (abgesehen davon, die riesige Datei in mehrere kleinere zu schneiden)?

+4

warum debug die sqlite Verschmelzung? sqlite hat eine richtige Verteilung, die viele separate Dateien enthält. –

+0

Wenn es nicht kaputt ist, fusionieren Sie es nicht. –

Antwort

8

Laut einem MS-Moderator ist dies ein bekanntes Problem nur mit dem Debugger (der Compiler scheint es gut zu handhaben, wie Sie darauf hingewiesen haben). Es gibt offenbar keine Problemumgehung, außer dass kürzere Quelldateien verwendet werden. Siehe offizielle Antwort auf sehr ähnliche Frage here

0

Wenn Sie sich die Dokumentation für die symbolischen Debugging-Informationen ansehen, sehen Sie den für Zeilennummern verwendeten Typ. Zum Beispiel sind sowohl line als auch column Parameter für IDiaSession::findLinesByLinenum vom Typ DWORD.

Bearbeiten: Wie @ Valdo darauf hinweist, bedeutet das immer noch nicht, dass der Debugger ordnungsgemäß mit großen Zeilennummern funktioniert. Sie müssen also kürzere Dateien verwenden. Es ist bedauerlich, dass eine solche Beschränkung existiert, aber selbst wenn es nicht wäre, würde ich immer noch empfehlen, dass Sie Ihre Quelle aufteilen.

+0

Nun, lass mich widersprechen. Die Tatsache, dass IDiaSession/IDialSession-Schnittstellen mit DWORD-Parametern deklariert sind, bedeutet nicht, dass die * tatsächlichen * Debug-Informationen mit DWORD-Zeilennummern gespeichert werden. Die Schnittstelle kann nur so ausgelegt sein, dass sie größere Zeilennummern unterstützt, nicht notwendigerweise ist sie implementiert. – valdo

0

Wenn Sie SQLite nicht ändern, sollten Sie nur darauf vertrauen, dass es seine Aufgabe erfüllt. Keine Notwendigkeit, überhaupt einzugreifen. SQLite wird vor der Veröffentlichung einer großen Anzahl von Tests unterzogen.

+2

Eine solche Ausrichtung sollte wohl ein Kommentar zu der Frage sein. Damit wird nicht versucht, die Frage des OP oder die damit verbundene allgemeine Frage zu beantworten. –

0

Haben Sie sich stattdessen mit WinDBG befasst? Es ist ziemlich gut, da das Windows-Team es zum Debuggen des O/S verwendet, und da sind einige kleine Dateien drin, oder zumindest gab es sie, als ich das letzte Mal geschaut habe.

+0

Noch nicht. Wie ich bereits sagte, scheint es die Begrenzung des Debug-Informationsformats zu sein, nicht irgendein Fehler im Debugger. – valdo

1

Nun, wenn ich sehen wollte, wie SQLite funktioniert, nahm ich die letzten 60000 Zeilen, zog sie in eine andere Datei und dann # include'd es. Das war einfach und hat den Trick für mich gemacht. Wenn du das tust, pass auf, dass du dich nicht in #ifdef aufteilst.

+1

Der Beitrag sagt "(abgesehen davon, die riesige Datei in mehrere kleinere zu schneiden)". –

+0

Der Post sagt das tatsächlich, aber es ist vollkommen in Ordnung zu behaupten, dass die Vorraussetzungen oder Annahmen eines Posters modifiziert werden sollten. Das Schneiden der Datei in drei Teile (benötigt jetzt, da die Verschmelzung mehr als 2 * 2^16 Zeilen hat) ist eine perfekte Lösung für das eigentliche Problem, nämlich das Debuggen in SQLite-Code unter Verwendung eines symbolischen Debuggers. Ich musste das nur selbst tun (warum? Weil ich den Grund herausfinden musste und nirgendwo in der SQLite Dokumentation und nirgendwo sonst erwähnt wurde, dass eine bestimmte SQLite Funktion fehlschlug; ich fand es in 5 Minuten heraus). –

0

Für alle, die Probleme mit falschen Zeilennummern für Dateien haben < 65536 Zeilen: Ich fand mein Problem wegen inkonsistente Zeilenenden in der Quelldatei. Es gab 129 \r Zeilenumbrüche, wo der Rest der Datei \r\n Stil war. Der Unterschied zwischen der Debugger-Zeile und der korrekten Zeile betrug ebenfalls 129.