Onlangs werd een project geïmplementeerd in een productieomgeving en werd ontdekt dat sommige methoden anomalistische berichten verstuurden
Er wordt echter alleen abnormale foutinformatie gegeven, en er is geen abnormaal regelnummer, alleen dat er een probleem is met de modelconversie in een bepaalde methode
Maar laat me ze één voor één vergelijken, het is te irritant, waarom niet het verkeerde lijnnummer noteren?
De log4net-logconfiguratie is als volgt:
Ik heb bewust een uitzonderingsbericht geschreven in de Home/Index-methode op mijn lokale computer om te zien of het regelnummer zou worden geregistreerd:
Ik heb gemerkt dat het foutlogbestand het regelnummer registreert, wat zeker geen probleem is met de log4net-configuratie, omdat de configuratie aan beide zijden hetzelfde is
Kan het een probleem zijn met de compilatiemodus???
Mijn lokale computer staat in debugmodus, en de dll die door de officiële server is gecompileerd staat in release-modus
Daarna heb ik het lokale project op release-modus gezet en ontdekte dat het nog steeds een recordregelnummer was.
Dan Baidu, de eerste zin:Je moet het .pdb-bestand kopiëren dat bij de dll hoort”
Is dit een probleem? Daarna ging ik direct naar de bin-map, verwijderde het .pdb-bestand dat bij de dll hoorde, en verververste vervolgens de website, en vond het uitzonderingslogboek als volgt:
En inderdaad, het abnormale regelnummer wordt niet geregistreerd!!!!
Is het echt een .pdb-probleem!! Je moet het .pdb-bestand bewaren zodat het lijnnummer wordt geregistreerd als het abnormaal is!!
Waar is een PDB-bestand voor?
PDB-bestanden: Wat elke ontwikkelaar moet weten
Wat is een PDB-bestand?
De meeste ontwikkelaars weten dat PDB-bestanden worden gebruikt om te helpen bij softwaredebugging. Maar hoe hij precies werkt, kennen we misschien niet goed. Dit artikel beschrijft de opslag en inhoud van PDB-bestanden. Het beschrijft ook hoe de debugger het PDB-bestand vindt dat overeenkomt met binay en hoe de debugger het broncodebestand vindt dat overeenkomt met binay. Dit artikel is bedoeld voor alle Native en Managed ontwikkelaars.
Voordat we beginnen, laten we twee termen definiëren: private build, wat wordt gebruikt om een build aan te duiden die op de eigen machine van de ontwikkelaar is gegenereerd; publieke build, wat betekent dat er een build wordt gegenereerd op een publieke buildmachine. Particuliere bouw is relatief eenvoudig, omdat PDB en Binay op dezelfde plek zitten, en meestal hebben we problemen met publieke bouw.
Het belangrijkste wat alle ontwikkelaars moeten weten is dat "PDB-bestanden net zo belangrijk zijn als broncode", zonder welke je niet eens kunt debuggen. Voor een publieke build moet de symbolserver alle PDB's opslaan, en wanneer de gebruiker een foutmelding meldt, kan de debugger automatisch het bijbehorende PDB-bestand in binay vinden, en weten zowel Visual Studio als Windbg hoe ze toegang moeten krijgen tot de symbolserver. Voordat je PDB en binay opslaat op de symboolserver, moet je ook de PDB-run source-indexeren, wat betekent dat je PDB en source koppelt.
Het volgende deel gaat ervan uit dat de Symbol Server en Source Server Indexing al zijn ingesteld. TFS2010 kan zo eenvoudig worden gedaan als bronindexering en het kopiëren van symbolservers voor een nieuwe build.
2. De inhoud van het PDB-bestand
Officieel startte de inhoud van PDB, PDB is geen openbaar beschikbaar bestandsformaat, maar Microsoft biedt een API om data van PDB te verkrijgen.
De native C++ PDB bevat de volgende informatie:
* publieke, private en statische functieadressen;
* De naam en het adres van de globale variabele;
* Parameter- en lokale variabelenamen en offsets op de stack;
* typedefinities van klasse, structuur en data;
* Frame Pointer weglatingsgegevens voor het doorlopen van de native stack op x86;
* De naam en het aantal regels in het broncodebestand;
De .NET PDB bevat slechts 2 delen informatie:
* Bestandsnaam van de broncode en aantal regels;
* en de naam van de lokale variabele;
* Alle andere gegevens zijn al opgenomen in de . NET Metadata;
|
Geplaatst op 03-08-2017 14:13:01
|
|
|
|
