QA/Bibisect/da

    From The Document Foundation Wiki
    < QA
    This page is a translated version of the page QA/Bibisect and the translation is 65% complete.
    Outdated translations are marked like this.

    Introduktion

    Bibisect står for ”binær bisektion“ Det er en procedure, der hjælper med at identificere tilsagn, der har forårsaget regressioner. Regressioner er den mest irriterende menneskelige efterladenskab, som uheldigvis dukker op med softwareudvikling og QA (kvalitetssikring). Vi vil behandle regressioner hurtigt og før tiden er gået og de bliver sværere og sværere at vurdere og ordne.

    If you are new to the topic of bisecting, it is recommended to first complete our tutorial and only then return to this article. Also, while you are free to study the topic independently, mentoring is available for all.

    Hvordan fungerer Bibisection?

    Hver Bibisect-pakke er et git-lager befolket med hundreder eller tusinder prototyper af LibreOffice. Tilføjet til lageret in kronologisk orden giver prototyperne en hurtig og enkel måde for os at teste en fejl mod imod mange forskellige versioner uden at skulle kompilere LibreOffice hver gang, vi skifter til en anden version.

    Vi kan geare værktøjerne, der er indbygget i git til binære søgninger gennem tilsagnene (”fx git bisect“) såvel som drage fordel af kompressionen og de-duplikeringsfunktioner, der inkluderet i git. Fx i en serie af prototyper, som hver kunne optage 500 MB diskplads, skal vi gennem de-duplikation potentielt kun bruge kun 25 MB til hver ekstra prototype.

    Detaljer

    En succesfuld bibisection vil overlade udviklerne kun nogle få tilsagn at gennemsøge for at finde det 'skyldige' tilsagn, som vi tror indførte en regression. Afhængigt af det bestemte bibisect-lager, kan samlingen være på 60, 100 eller bare 2 tilsagn. (Vi har også nogle meget 'grove' bibisect-lagre, som bruger frigivne versioner + beta + RC-prototyper, og disse har måske samlinger der spænder over flere hundreder tilsagn)

    QA kan tage det ekstra skridt, der består i en fuldstændig bibisection (der bestemmer det nøjagtige tilsagn) eller kan overlade det til udviklerne. Det er ofte let at at finde det tilsagn, som har forårsaget problemet, efter at fejlen er blevet bibisectet. Med omkring 10 GB vil du have hundreder af prototyper at arbejde med. En bibisect kan tage så lidt som 15 minutter.

    Aktuelt kan bibisect udføres på:

    Som det kan ses fra Commits i rækkevidde og antal builds, afhængigt af det specifikke bibisect-lager, kan dette interval være i gennemsnit 80 commits for gammelt "43max"-lager (når hundredvis af af kildebekræftelser i nogle builds) til kun 1 eller 2 commits for nyere repositories. (Vi har også nogle meget 'grove' bibisect-repositories, der bruger frigivne versioner + beta + RC-builds, og disse kan have intervaller, der spænder over flere hundrede af commits).

    Generelle Instruktioner

    Det kan være en god idé for begyndere at starte med at spore trinene i en bibisect, der allerede var gennemført med succes. Til dette formål har vi en bibisecting tutorial.

    Note pin.svg

    Bemærk:
    Each operating system is different, so please read the page that corresponds to your operating system (GNU/Linux, macOS or Windows) for more specific instructions, tips and troubleshooting.

    Før du bibiserer for første gang, skal du:

    The bibisecting articles for each operating system contain tables listing the available versions. In the "Download links" column of the table you will find links to pages explaining how to acquire the repositories. The repositories for old versions no longer receiving updates are offered as bundles. The repositories for still active versions can be periodically updated with the command git checkout master && git pull.

    If you are testing version 5.x or older, you have to read carefully the article for the operating system you are using and also check the comments column in the Version table. The older versions require various special considerations that this general article does not mention.

    Use the cd (change directory) command in your terminal to move between the different repositories. Jump to the oldest commit in a repository by saying git checkout oldest and to the newest by saying git checkout master. In some older repositories you have to use latest instead of master. Even if the bug report already points out the first version with the bug, always start by testing with both the oldest and the newest commits.

    The commands to launch LibreOffice from the bibisect repositories are as follows in the different operating systems:

    # Windows
    instdir\program\soffice
    </div>
    
    <div lang="en" dir="ltr" class="mw-content-ltr">
    # Linux
    instdir/program/soffice
    </div>
    
    <div lang="en" dir="ltr" class="mw-content-ltr">
    # macOS
    open LibreOffice.app/

    When you don't see the bug in oldest, but do see it in the newest commit, start bibisecting by saying git bisect start master oldest.

    After testing in LibreOffice and seeing the bug, say git bisect bad. If you don't see the bug, say git bisect good. If you were unable to test, say git bisect skip (note that there are various tips related to these scenarios in this and other articles).

    After the final step in the bibisecting process, you are presented with the first bad commit. Within the information given, you are interested in the source hash, which is a combination of letters and numbers. Now you can study the commit to see what it's about and who wrote it. If you have the LibreOffice source code on your computer, you can change to its directory and say git show 22fc8c634c5f9b09d45aff0403503f4d8226328d, the last part being the source hash. Otherwise you can examine the commit in a web browser by creating a URL like so: https://git.libreoffice.org/core/commit/22fc8c634c5f9b09d45aff0403503f4d8226328d

    Now update the bug report as follows (can be done in a single change):

    1. Write a comment mentioning the bibisect repository you used and the source hash (it will become a link in Bugzilla automatically). Any other useful information is welcome, of course.
    2. Update the Version field, if needed (see also #Finding the earliest version affected
    3. Replace the keyword bibisectRequest with bibisected and bisected (only include the last one, if you found the exact commit and not just a range of commits)
    4. Add the name of the commit author to the Regression By field (for this you need contributor rights in Bugzilla)
    5. Add the commit author to the CC List of the report

    Bemærk, at du kun bør tilføje den originale forfatter til CC ("forfatter" på git.libreoffice.org eller "ejer" på gerrit), ikke nogen anmeldere. Hvis en udvikler har trukket sig tilbage fra projektet (tjek datoen for deres sidste commits), er der ingen mening i at tilføje nogen til CC'en. I stedet for i dette tilfælde bør du støde fejlrapportens prioritet.

    Commit intervaller

    Nogle bibisect-depoter har rækker af kildeforpligtelser foldet sammen i en enkelt del. Hvis du efter at have fuldført en bibisect kun bliver præsenteret for en enkelt af disse chunk commits, kan du få intervallet ved først at kopiere hashen (bemærk: ikke kildehashen) og bruge den i en git log kommando som sådan:

    git log -2 c3f9dc54188b316a61dd871b63734d49b05f5d7f

    Nu kan du kopiere kildehasherne for den første og tidligere viste commit og adskille dem med .. for at konstruere en intervalforespørgsel som sådan:

    https://git.libreoffice.org/core/log/7c4d3ea6ba4d42b4dda5148a00c8c411b5d7703d..5b195fbcf7a441aeb193f6abd08b877e580938e0
    

    Dette giver dig mulighed for at skimme commit-beskeder på udkig efter relaterede emner. For en dybere undersøgelse, se afsnittet om detektivarbejde.

    At finde den tidligste berørte version

    Hvis du har en lokal kopi af kernelageret, kan du opdatere feltet Version i fejlrapporten takket være nogle git-kommandoer:

    1. Sørg først for, at du har alle tags:

    git fetch --tag

    2. Brug derefter 'name-rev' til at finde konteksten (mere præcist, efter hvor mange revisioner den gik forud for det tidligste tag, der indeholder commit):

    git name-rev <commit>

    3. Hvis det ikke gav et nyttigt tag, der matcher en LibreOffice-version, kan du liste alle tags, der indeholder commit og har "libreoffice" i navnet med:

    git tag --contains <commit> | grep libreoffice

    Begrænsninger

    Udførelse af en 'bibisect' er kun muligt, hvis vi har et tilgængeligt lager til det korrekte operativsystem, der dækker den korrekte samling af LibreOffice-tilsagn. Vi har meget god dækning af GNU/Linux og forbedrer vores dækning af Windowa og macOS.

    Nogle regressioner er vanskelige at genskabe og kræver måske flere testkørsler, før fejlen viser sig. Som du måske kan forestille dig, er det ”meget“ svært at bibisecte sådanne regressioner, og kræver at du foretager mange testkørsler efter hver udgivelse af en ny version af LibreOffice for at give nogen sikkerhed / statistik for, at fejlen faktisk findes eller ikke findes i den givne version.

    Vi har aktuelt ikke bibisect-understøttelse af

    Ikke Bibisectable

    Nogle fejl er ikke bibisect-bare. De omfatter

    • Fejl, der ikke viser sig på en understøttet platform (se #Begrænsninger)
    • Fejl, der er ældre en vores bibisect-prototyper ”(Vi arbejder på at udvide dækningsområdet)“
    • Fejl, der er afhængige af prototypeindstillinger, der ikke er aktiveret i TDF-prototyper ”(fx ”'-kde“')“
    • Bugs that don't show up on a supported platform (see #Limitations)
    • Bugs that predate our bibisect builds
    • Bugs that depend upon build options not enabled in the TDF builds

    Hvis du finder, at en fejl med nøgleordet bibisectRequest ikke er bibisectbar, skriv en kommentar om, hvorfor vi ikke kan bruge bibisect til at opspore begyndelsen af dette problem, og erstat nøgleordet bibisectRequest med notBibisectable. Hvis en fejl går forud for bibisect builds, skal du erstatte søgeord bibisectRequest med preBibisect.

    Fejlfinding

    Find fejl, der behøver bibisect

    If you are new to bibisecting, click the Id column header until the list is sorted from highest Id to lowest. Compared to newer ones, when bibisecting older issues you will run into more surprises and greater complexity.

    Følgende fejl med søgeordet bibisectRequest venter på en bibisect:

    Derudover kan alle uafklarede regressioner i LibreOffice have gavn af at bibisere.

    Specielle situationer

    Bibisecting sprogspecifikke fejl

    De leverede TDF bibisect-lagre inkluderer ikke nogen lang-packs.

    For at bibisectere fejl, som fungerer godt med engelsk UI, men dårligt med ikke-engelsk UI (som CJK'er): man skal kopiere og indsætte følgende filer, fra en udgivelsesbuild, som har dit sprog, til den samme placering af bibisect-repoen:

    1. program/ressource/<dit_lang_tag>
    2. share/registry/Langpack-<dit_lang_tag>.xcd
    3. share/registry/res/fcfg_langpack_<dit_lang_tag>.xcd
    4. share/registry/res/registry_<dit_lang_tag>.xcd

    De foreslåede sprogressourcer, du bør kopiere, er dem for den samme hovedgren. For eksempel, for bibisect-linux-64-6.0 repo, kan du kopiere fra 6.0.1.1 udgivelse.

    Kørsel med en separat brugerprofil

    For at oprette en mappe til separate profiler på /tmp/ (som vil blive fjernet automatisk under den næste maskinopstart):

    ./opt/program/soffice -env:UserInstallation=file:///tmp/soffice-bisect

    Hvis du vil begynde forfra på hver bisect-gentagelse, kan du tilføje nummeret på git-tilsagnet til mappens navn. For eksempel

    ./opt/program/soffice \
    -env:UserInstallation=file:///tmp/soffice-bisect-$(git rev-parse HEAD)

    Find en løsning

    Nogle gange er en fejl en sideskade af en anden (muligvis mindre) fejl, på en ikke indlysende måde. I sådanne tilfælde kan den anden fejl være rettet på master, men den blev ikke backporteret til udgivelsesgrenen. For at identificere en problem-fixing commit kan du bruge:

    git bisect start --term-new=fixed --term-old=unfixed
    git bisect fixed master
    git bisect unfixed <some-old-sha> # you can use "git log --reverse" to detect the first revision in the bibisected package

    Mens du tester, skal du sige

    git bisect fixed

    eller

    git bisect unfixed

    alt efter hvad der er relevant.

    Hvis rettelsen er lille og vigtig nok, kan den sandsynligvis nemt tilbageporteres til udgivelsesgrenen.

    Tjek en specifik commit ud baseret på kildehash

    Nogle gange ved du allerede, at en specifik kilde-commit har/ikke har den fejl, du jager.

    Kopier kildehashen fra LibreOffice git-historikken og brug den til at grep i bibisect-repo-loggen sådan:

    git log --all --grep='29a9f433c268414747d8ec7343fc2b5987971738'

    Kopiér commit-hashen for bibisect-reposen, og tjek den for at bekræfte din antagelse:

    git checkout 38758b70f5278d4d8292a2e857e80a9a1130f38e

    Du kan bruge repo-commit-hashen, når du bestemmer det dårlige-gode-interval, der skal opdeles:

    git bisect start 38758b70f5278d4d8292a2e857e80a9a1130f38e oldest

    At udføre detektivarbejde inden for et commit-område

    Hvis dit bibisect-resultat er række af forpligtelser, og du har problemer med at finde den krænkende forpligtelser, kan du måske gøre dit liv lettere ved at søge med et søgeord.

    Et eksempel på en sag, hvor vi kender problemet, er i Calcs Navigator-visning:

    git log --stat --pretty=short --graph 169bd7718264b0e312052757f9bbd2321e1399c2...ff8b873936aa72b17309da4bfc2775573a5b1f55 | grep -B 10 -A 10 --color=always "sc/source/ui/navipi" | less -R

    Juster -B og -A grep-parametrene for at kontrollere, hvor mange linjer før og efter det hit, du vil vise. Når piping til mindre, -R bevarer farven af ​​søgeresultater.

    This method can also be used as a shortcut in a situation, where you find yourself having to use git bisect skip over and over again due to some broken functionality.

    Hvis soffice fejler med en udgangskode, der ikke er nul - det betyder sandsynligvis et nedbrud - tilbyder en løsning under QA/Bibisect/Automation#Godbidder til effektivitet et script, der letter smerten ved gentagne gange at springe over fejlede prober.

    Især i de ældre depoter kan du nogle gange ende med en liste over snesevis af potentielle dårlige indsendinger. Indsendinger er muligvis ikke i orden, så det er ikke nemt at konstruere en intervalforespørgsel. Du kan gemme listen over indsendinger til en tekstfil og køre git show for dem alle og dirigere outputtet til en fil:

    while IFS="" read -r p || [ -n "$p" ]
    do
      git show --no-patch "$p" >> /path/to/bisectlog.txt
    done < /path/to/bisect_range.txt

    De ældre depoter inkluderer den originale indsendinger-meddelelse, så denne resulterende logfil vil være umiddelbart nyttig. Hvis det binære depot ikke indeholder de originale meddelelser, skal du først lave et pass med git show --oneline --no-patch, rydde op i listen over kildehash og derefter gøre det sidste looping mod LibreOffice kernelager.

    At finde kilden-commits fra bibisect

    Hvis bibisect blev udført, men sandsynligvis ikke er korrekt eller i et depot, der vides at have et stort udvalg af kilde-commits, kan vi kontrollere området ved at finde en tidligere build-commit fra den fundne og derefter finde kildeområdet.

    $ git log -1 1f14665c5624bc7a502738aa8f4f2bd70a211e72^
    $ git log --oneline b6c016da23d309b4ac7d154bc33a22397974ed73..d85fd8a85501547d5bb87822d2589a07aed7f2d6

    Problemløsning

    Beskriv venligst dine problemer og hvordan du løste dem. Dette afsnit dækker spørgsmål, som dækker mere end et OS. Om OS-specifikke spørgsmål se venligst de individuelle OS wikisider.

    Umuligt at udtrække filer

    Hvis du ikke kan udtrække filer (du skulle få en fejlmeddelelse). Prøv at omdøbe filen fra *.tar.lzma til *.tar.xz.

    Installeret LibreOffice blev uventet ændret

    Problem / Beskeder:

       error: Your local changes to the following files would be overwritten by checkout:
         opt/program/pythonloader.pyc
         opt/program/uno.pyc
         opt/program/unohelper.pyc
       Please, commit your changes or stash them before you can switch branches.
       Aborting
    

    'Løsninger'::

    git checkout .
    
    # <span lang="en" dir="ltr" class="mw-content-ltr">Sometimes this more specific command is needed:</span>
    find . | grep -E "(__pycache__|\.pyc|\.pyo$)" | xargs rm -rf;

    Ovenstående kommando vil reparere problemet. Derefter kan du starte den næste testkørsel som sædvanligt med

    git bisect good # or git bisect bad

    Hvis det ikke løser problemet, kan du prøve følgende kommandoer:

    git clean -fd
    git reset --hard

    Den ultimative reparation er at slette alt undtagen én skjult .git/-mappe, og gør

    git checkout oldest

    Umuligt at start soffice

    Problem 1: Efter forsøg på at køre soffice inde i bibisect får du fejlmeldingen "unexpected operator terminate called after throwing an instance of 'com::sun::star::uno::DeploymentException'“

    Løsning: Nulstil din LibreOffice-profil, der er placeret i ~/.config/libreoffice. Sørg for at tage sikkerhedskopi af mappen, hvis du har nogen som helst indstillinger, du vil bevare til brug med din stabile LibreOffice-udgave. Når du er færdig med bibisect kan du prøve at genskabe din sikkerhedskopi på dens oprindelige plads (dvs. slette den den nye profilmappe og erstatte den med den sikkerhedskopierede).

    Sådan bisect's RTL-fejl

    I tilfælde af at du har brug for at opdele en RTL ( Right-To-Left ) fejl, skal du importere denne variabel, før du kalder LibreOffice:

    SAL_RTL_ENABLED=1

    Sådan bisect filgendannelsesfejl

    Hvis du har brug for at opdele filgendannelsesfejl (fx tdf#129210), skal du kommentere linjen OOO_DISABLE_RECOVERY=1 i filen instdir/program/ooenv

    Du kan også bruge brugerkontrol:

    soffice --norestore file-that-recovers.ext

    Sådan bisects filhængende / CPU- eller hukommelsesudmattelsesfejl

    I tilfælde af at du har brug for at opdele filhængende/hukommelsesudmattelsesfejl, kan du begrænse hukommelsen eller CPU- eller tidsudførelsen.

    I Linux kan værktøjet timeout bruges. For at undgå forvirring med den indbyggede "timeout"-kommando, er den her omdøbt til "tmt".

    For eksempel, hvis LibreOffice 'good' commit åbner en fil med 1 GB hukommelse, kan du indstille soffice memory limit til 1.500.000 kilobyte for at undgå at 'dårlig' commit hænger din computer.

    tmt -m 1500000 instdir/program/soffice

    Eller for at begrænse CPU+SYS-tiden (hvor normal tid ses ved vellykket kørsel):

    tmt -t 20 instdir/program/soffice

    Mere avanceret mulighed er at bruge værktøjet benchexec. Brugeren skal føjes til den relevante gruppe (benchexec). Runexec kan bruges til at udføre en enkelt kommando, mens dens ressourceforbrug måles, på samme måde som værktøjet "tid", men med mere pålidelige tidsmålinger og med måling af hukommelsesforbrug.

    I Windows kan værktøjet process-governor bruges.

    Yderligere oplysninger

    Automatisering

    Se den separate artikel om automatisering af bisecting.

    Noter

    Se detaljer om, hvordan bibisect-arkiver genereres:

    Information om sammenfletning af alle vore bibisect-lagre, ser du på