QA/BugReport/Debug Information/nl
TDF LibreOffice Document Liberation Project Blogs gemeenschap Weblate Nextcloud Redmine Ask LibreOffice Doneren
Deze pagina beschrijft de informatie van het debuggen die u mogelijk wilt aanleveren aan de ontwikkelaars bij het maken van een BugReport.
Dit is zelfs voor ons ingewikkeld
Voel u niet verplicht om deze informatie te verstrekken, tenzij
- U een ontwikkelaar / programmeur bent en weet wat dit betekent
- Een ontwikkelaar of iemand in QA u expliciet heeft gevraagd om deze informatie te verstrekken
- U maakt deel uit van het QA-team
Debug-informatie per besturingssysteem
Deze instructies zijn allemaal vrij OS-specifiek, dus we zullen de rest van deze pagina opsplitsen per besturingssysteem.
GNU/Linux
Om deze verschillende foutopsporingslogboeken te produceren, moet u eerst de foutopsporingspakketten installeren. Raadpleeg de foutopsporingsgids van uw Linux-distributie:
Een andere optie is om uw eigen debug build te gebruiken met behulp van --enable-debug of -- enable-symbols. Dit laatste verandert de programmalogica niet, schakelt optimalisaties niet uit en maakt geen extra beweringen/controles mogelijk die de schakeloptie -- enable-debug wel doet.
Een derde optie is om een dagelijks gebouwde debug-build te downloaden en uit te voeren. Deze zijn hier te vinden, in mappen die eindigen op -dbg. Houd er rekening mee dat de download 1,6 GB + is, na het uitpakken neemt het circa 5 GB in beslag.
GNU/Linux: Een backtrace krijgen
De backtrace is handig voor het analyseren van de redenen waarom een toepassing crasht of vastloopt. De backtrace kan worden uitgevoerd zonder de foutopsporingspakketten, maar het zal niet zo nuttig zijn, maar kan nog steeds mogelijk op zijn minst enige informatie opleveren. U kunt de volgende stappen uitvoeren:
NB: Voordat u LibreOffice in de foutopsporingsmodus start, moet u ervoor zorgen dat gdbtrace.log niet bestaat in de map van waaruit u LibreOffice start, verwijder eerst het bestand!
- start een terminal / shell (in sommige distributies kunt u dit men Ctrl + Alt + T doen)
- run '
$soffice --backtrace' - Als u de cursor ziet knipperen op een regel die begint met '`
(gdb)`, typ dan 'Run' en voer vervolgens in (dit gebeurt wanneer een gebruikersprofiel niet aanwezig is) - reproduceer de crash of het probleem. Als het vastloopt, moet u een crash forceren, dus open een andere console en typ `
$ pkill -15 soffice.bin` of typ als alternatief `$ xkill` en klik op het hangende libreoffice-venster. - als u niet terugkeert naar de standaardprompt en zich op een regel met een knipperende cursor bevindt, als er een regel wordt weergegeven die eindigt op '?? ()' typ "C", zo niet typ "BT" en voer vervolgens in. Als u zich in plaats daarvan op een regel bevindt die begint met `
(gdb)`, typt u 'quit' om terug te keren naar de prompt. - Een bestand
gdbtrace.logwordt gemaakt in dezelfde map. - voeg gdbtrace.log toe aan het bugrapport.
U kunt de waarschuwingen over geweigerd automatisch laden van .py bestanden negeren. Deze mooie printers zijn alleen nuttig in interactieve debug sessies. De optie --backtrace van het soffice-script voert gdb uit met de optie -nx, die alle gdbinit-bestanden en de auto-load-opdrachten die ze kunnen bevatten, negeert.
U kunt ook gdb koppelen aan het proces soffice.bin na het starten van LibreOffice. Als u slechts één LibreOffice-proces hebt uitvoert, kunt u er snel als volgt aan koppelen: gdb --pid `pgrep soffice`
GNU/Linux: Een strace log krijgen
strace traceert de systeemaanroepen die een proces doet. Als er een probleem is rond file-I/O, kan dit een geweldige manier zijn om precies te detecteren wat er op het niveau van het besturingssysteem gebeurt. Het is ook een snelle manier om te zien of het programma doorgaat met uitvoeren en / of hangt, en het vinden van informatie over het systeem waarop LibreOffice wordt uitgevoerd.
- start een terminal
soffice --strace- reproduceer uw probleem
- Comprimeer het logboek:
bzip2 strace.log - Voeg nu het aangemaakte bestand code>strace.log.bz2 toe aan het bugrapport.
GNU/Linux: Een ld.so log krijgen
Voor problemen die worden veroorzaakt door gedeelde bibliotheken die niet worden gevonden, niet worden geladen, verkeerde bibliotheken worden geladen of vastlopen als gevolg van geëxporteerde symboolbotsingen in de globale namespace ELF, is het vaak handig om een logboek van ld.so te hebben. De handigste optie is LD_DEBUG=libs, maar LD_DEBUG=files is ook handig in zeldzamere gevallen.
rm lddebug*- verwijder alle verouderde logboeken van de vorige keer
LD_DEBUG=libs LD_DEBUG_OUTPUT=lddebug soffice- reproduceer uw probleem
ls -l lddebug*- er zal één bestand per proces zijn; De interessante is die voor het hoofd soffice.bin proces, dat meestal veruit het grootste in omvang is
- Voeg het grootste bestand
lddebug.Ntoe aan het bugrapport
GNU/Linux: Een Valgrind log krijgen
Het logboek valgrind is van onschatbare waarde voor het opsporen van obscure geheugenbeschadigingsfouten die anders uiterst moeilijk te vinden kunnen zijn. Het bereikt dit door een CPU te emuleren. Het kleine nadeel daarvan is dat de code zo'n tachtig (80x) langzamer draait, wat erg traag zal lijken. De positieve kant is dat het ons problemen laat zien die op een andere manier niet vindbaar zijn, en dat de geproduceerde sporen het probleem heel vaak op zo'n manier lokaliseren dat het voor een ontwikkelaar vrij gemakkelijk is om op te lossen: uw geduld wordt zeer op prijs gesteld. Valgrind kan ook een aantal vals-positieven produceren.
- installeer het pakket
valgrind - start een terminal
soffice --valgrind >& /tmp/valgrind.log- heb geduld... 80x is een stuk trager... reproduceer het probleem.
- voeg
/tmp/valgrind.logtoe aan het bugrapport.
Als u enkele extra opties voor valgrind wilt opgeven, kunt u omgevingsvariabele VALGRIND_OPTS gebruiken.
GNU/Linux: Een callgrind krijgen
Een callgrind-tracering wijst onmiddellijk de slecht presterende stukjes code aan en gebruikt valgrind om een CPU te modelleren, het vereist dus de installatie van het valgrind-pakket. Dit type trace biedt een hiërarchische, navigeerbare histogramweergave van waar de tijd wordt doorgebracht in de code, die kan worden bekeken in apps zoals kcachegrind. Callgrind-traces zijn een CPU-intensief proces en LibreOffice zal vele malen langzamer werken dan normaal, dus het moet niet worden uitgevoerd door een gebruiker met een trage pc. Naast een snelle pc moet LibreOffice worden gebouwd met --enable-symbols en niet --enable-dbgutil of --enable-debug, omdat debug-builds zich zeer abnormaal gedragen met betrekking tot prestaties.
- start een terminal in de LibreOffice-programmamap (bijv.
~/core/instdir/program) - `
$ VALGRIND=callgrind ./soffice`
Als het probleem dat u traceert de trage openingstijd van een document is, kunt u deze omgevingsvariabele zo instellen dat deze onmiddellijk wordt afgesloten na het openen:
`$ export OOO_EXIT_POST_STARTUP=1`
Nadat u de trace hebt uitgevoerd en netjes hebt afgesloten (druk in extremen slechts één keer op ctrl + c in de terminal), vindt u een groot bestand genaamd: callgrind.out.12345 waarbij 12345 de PID is. Comprimeer dit bestand en voeg het toe aan het bugrapport of upload het ergens waar een ontwikkelaar toegang toe heeft.
Een --enable-symbols build van LibreOffice voegt een extra ~10GB toe aan een bestaand build-systeem omdat de symbolen worden toegevoegd aan .so-bestanden in de map instdir en .o-bestanden in de workdir. De symbolen kunnen uit deze bestanden worden verwijderd door strip op de bestanden uit te voeren of door de mappen instdir en workdir te verwijderen en een rebuild te doen.
Er is een manier om de tracering te versnellen en ervoor te zorgen dat deze alleen relevante gegevens bevat:
- Starten met
VALGRIND="callgrind --instr-atstart=no" ./soffice - Bereid u voor om het ding te doen dat u wilt traceren in LibreOffice
- Geef in een andere terminal het commando
callgrind_control -i on - Doe wat u wilt traceren
- Geef in de andere terminal het commando
callgrind_control -d - Stop de tracering en stop LibreOffice met
callgrind_control -k
Een alternatief voor callgrind is perf. De uitvoer is niet zo gedetailleerd als die van callgrind, maar omdat het veel sneller werkt, geeft u er in veel gevallen de voorkeur aan boven callgrind.
Windows
Windows: Een backtrace krijgen
Als u LibreOffice 4.2.0 of hoger hebt geïnstalleerd en uw versie functionaliteit voor debuggen bevat, is er een testsymboolserver met de bijbehorende symbolen. Lees met Window debuggen om de omgeving in te stellen, u kunt ook deze video bekijken voor een uitleg van het proces.
Windows: hoe de uitvoer van de OpenGL-foutopsporing te krijgen
- Download en installeer een build met debug-functies, bijvoorbeeld: https://dev-builds.libreoffice.org/daily/master/Win-x86@39/current/
- Download en installeer cygwin (alleen de minimale standaardbasis): https://cygwin.com/setup-x86_64.exe
- Geef in de opdrachtregel van cygwin deze opdracht om een omgevingsvariabele voor logboekregistratie in te stellen:
set SAL_LOG=+INFO.vcl.opengl+WARN - Misschien wilt u de map wijzigen in de LibreOffice-programmamap zoals:
cd "/cygdrive/c/Program Files (x86)/LibreOfficeDev 6/program" - Start LibreOffice vanuit hetzelfde opdrachtregelvenster met deze opdracht (voeg het volledige pad toe, als u buiten de programmamap start):
./soffice.exe --calc 2> soffice.log
Probeer nu uw OpenGL-probleem te reproduceren. De foutopsporingsuitvoer wordt naar het bestand soffice.log geschreven, dat u vervolgens aan een bugrapport kunt toevoegen.
Windows: hoe de uitvoer van de OpenGL-foutopsporing te krijgen
Zie hierboven, gebruik nu set SAL_LOG=+INFO.opencl+INFO.sc.opencl+WARN als de variabele voor de omgeving.
U kunt dit programma ook gebruiken om OpenCL-informatie af te drukken naar een bestand: http://dev-www.libreoffice.org/opencl/Windows/Opencl%20Info.exe
Windows: Debugging van een GDI Resource Leak ( vcl::Window::dispose() )
Standaard is de limiet van unieke GDI-objecten in het geheugen tegelijkertijd 10.000 en als LibreOffice dit bereikt, kunnen we een vcl::Window::dispose() crash ervaren. Het kan vooral problematisch zijn bij het opslaan, wanneer LibreOffice duizenden VirtualDevices kan maken. Om te controleren of we de limiet van het GDI-object in het geheugen hebben bereikt, kunnen we stap 1 volgen in deze pagina of een toepassing gebruiken met de naam GDI-handles.
Als we bevestigen dat de limiet is bereikt, kunnen we stap 2, 3 en 4 van deze pagina volgen om verdere informatie voor het debuggen te verstrekken.
Voorbeeld: Bug 102688
Windows: hoe een geheugencorruptie op te sporen met DrMemory
Lees de sectie in het artikel over debuggen bij het ontwikkelen.
Windows: hoe u een ETW-performance-tracering kunt krijgen
Event Tracing voor Windows (ETW) is een krachtig hulpmiddel voor het onderzoeken van prestatieproblemen. UIforETW maakt het gemakkelijk te gebruiken. Lees er meer over op blog van Bruce Dawson.
Voor prestatieprofilering moet u een release-build gebruiken of uw eigen build met --enable-symbols. Builds gedaan met --enable-debug of --enable-dbgutil mogen NIET worden gebruikt. Gebruik daarom niet de dagelijkse builds van Tinderbox 39.
Instructies voor het instellen van UIforETW:
- Download de nieuwste release van UIforETW
- Pak de release ergens uit
- Voer bin/UIforETW.exe of UIforETW32.exe uit afhankelijk van uw LibreOffice-build
- Klik op Tracering starten
- Voer LibreOffice uit en doe wat u wilt onderzoeken
- Sla de traceerbuffers op een gegeven moment op in UIforETW
- Klik met de rechtermuisknop op de tracering die wordt weergegeven in het gedeelte Traces onderaan en selecteer Trace openen in WPA 10
- Open in WPA het menu-item Trace - Symboolpaden configureren
- Klik op + en voer dit in bij het gebruik van een release build:
CACHE*C:\symbols;SRV*http://dev-downloads.libreoffice.org/symstore/symbols;SRV*http://msdl.microsoft.com/download/symbols
of dit, bij gebruik van een zelfgemaakte build:CACHE*C:\symbols;SRV*http://msdl.microsoft.com/download/symbols
- Trace - Laad symbolen. Houd er rekening mee dat dit tijd en enkele gigabytes aan opslagruimte kost.
- Klik in het onderste deelvenster naast CPU-gebruik (Sampled). Standaard is "Randomascii inclusive (stack)". Stel het in op Flame by Process, Stack*
- Zoek naar het soffice.bin proces: Klik met de rechtermuisknop -> Filter naar selectie
- Druk op Ctrl + Shift + G (alleen Display Graph)
- Klik op het maximalisatiepictogram
- Vanuit het pictogram "Select chart type" (tussen "Select view preset" en "Quick search"), kunt u het type wijzigen in Flame
De traces kunnen zeer grondig zijn, let op deze functionaliteit in UIforETW: Invoertracering: Als dit is ingesteld op Privé of Volledig, worden alle muisbewegingen en muisklikgebeurtenissen vastgelegd in de tracering en weergegeven in de grafiek Algemene gebeurtenissen. Als deze optie is ingesteld op Volledig, worden alle toetsaanslagen volledig geregistreerd, terwijl als deze is ingesteld op Privé alle letters worden geregistreerd als 'A' en alle cijfers worden geregistreerd als '0'.
De opgeslagen traceerbuffers worden weergegeven als .etl-bestanden in de map C:\Users\gebruikersnaam\Documents\etwtraces De bestanden kunnen worden gedeeld in Bugzilla zodat anderen ze kunnen onderzoeken in Windows Performance Analyzer.
macOS
macOS: Het verkrijgen van debug informatie
De foutopsporingsinformatie is nuttig voor het analyseren van de reden waarom een toepassing stuk of vast loopt. Op macOS kunt u de standaard foutopsporingsinformatie heel eenvoudig ontvangen, zonder extra software te installeren. (Deze informatie bevat zelfs een eenvoudige stapeltracering, die volledige symbolen mist, maar toch zeer nuttig kan zijn.)
De exacte stappen variëren afhankelijk van uw macOS-versie en de configuratie, maar over het algemeen krijgt u de foutopsporingsinformatie als volgt:
- Wanneer een toepassing crasht, vraagt macOS u een dialoogvenster met de tekst "LibreOffice wordt onverwacht afgesloten." en wordt u gevraagd of u een rapport naar Apple wilt verzenden. Klik op de knop met het label "Melden...". Nu wordt een groter venster met de titel "Probleemrapport voor LibreOffice" geopend; onder "Probleemdetails en systeemconfiguratie" vindt u een bewerkingsveld met een lange tekst met veel technische details. U kunt gewoon in deze lange tekst klikken, op drukkenCmd + a om alle tekst te selecteren en druk vervolgens op ⌘ Cmd + c om het te kopiëren en vervolgens over te schakelen naar een teksteditor (bijvoorbeeld Apple's TextEdit) en druk op ⌘ Cmd + v om de tekst in te voegen. Vervolgens kunt u de tekst opslaan als een bestand; Het beste zou zijn om het platte tekst (.txt) formaat te gebruiken. Voeg dat bestand toe aan uw bugrapport. (U hoeft het rapport niet naar Apple te sturen, dus klik op 'Niet verzenden' in het venster 'Probleemrapport'.)
- Wanneer een toepassing stuk of vast loopt, kunt u deze geforceerd afsluiten met ⌘ Cmd + alt + Esc. macOS toont dan een dialoogvenster met de titel "Toepassingen geforceerd afsluiten", waarin u wordt gevraagd welke toepassing (en) u wilt afsluiten; In die lijst kunt u de toepassing die vaak hangt of bevriest herkennen aan de hint "(reageert niet)". Selecteer het en klik op de knop "Forceer stop". Afhankelijk van uw systeemconfiguratie wordt u gevraagd of u daar een rapport over naar Apple wilt sturen; Als u dit bevestigt, krijgt u hetzelfde venster "Probleemrapport" als hierboven beschreven en kunt u de tekst met foutopsporingsinformatie op dezelfde manier kopiëren en opslaan.
NB: Afhankelijk van uw systeemconfiguratie en gebruikersinstellingen wordt u al dan niet gevraagd om een rapport naar Apple te sturen; Mogelijk moet u zijn aangemeld als beheerder om deze dialoogvensters te kunnen zien.
Als het rapportdialoogvenster al eerder is weergegeven, kan men eerdere crashrapporten vinden in:
~/Library/Logs/DiagnosticReports/
Het bestand ziet er ongeveer zo uit:
soffice-YYYY-MM-DD-155234.ips
Een alternatieve manier is het gebruik van de toepassing Activity Monitor.
Wat de gekoppelde instructies betreft, is de enige wijziging in nieuwere versies van macOS dat de werkbalkknop voorbeeldproces is verplaatst. Nu is er een ... werkbalkknop. Klik op die knop en selecteer Voorbeeldproces in de pop-upr die verschijnt.
Problemen met plakken en klembord
Als er een plakprobleem is van een externe, niet gemakkelijk te verkrijgen app, zoals een enorm commercieel programma, zullen QA en ontwikkelaars nauwelijks een specifieke app krijgen om te testen. De oplossing is om klembordbeheer te gebruiken om informatie op te slaan wanneer deze uit dat programma wordt gekopieerd, zodat plakken op elk gewenst moment kan worden getest zonder het oorspronkelijke programma. Aanbevolen is klembordbeheer dat op meerdere besturingssystemen werkt, met name CopyQ. Resultaat van.cpq moet worden toegevoegd aan het bugrapport.