Kernel bugs git και μέθοδος bisection...

[firewalker]

Με ταλαιπωρεί στον 2.6.30 ένα bug. Έχω κάνει bug report και μου λένε να κάνω κάτι "κουλά" για να βοηθήσω στον εντοπισμό. Κάνει για μέθοδο bisection. Ξέρει κανείς να μου περιγράψει ποια είναι αυτή η μέθοδος εύρεσης και διόρθωσης bug;

 

http://bugzilla.kernel.org/show_bug.cgi?id=13681

 

>Yes, bisection is a technique for tracking down bugs.  In this case you would
use it with Git.  You'll have to install Git and download the kernel source
repository.  There are any number of tutorials and documents about using Git
and bisection; you can find some at www.kernel.org or you can ask Google.

 

Πρέπει να κάνω clone όλο το git του kernel?

 

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

 

Και μετά;

[NullScan]

Είναι λίγο μπακάλικη μέθοδος αλλά βοηθάει στο να αποφεύγεις να φορτώνεις kernels με kdb κλπ κλπ. Κατεβάζεις το tree του kernel και μετά ρωτάς το git repository να σου πει τις αλλαγές που είχε το rt73usb module μεταξύ των εκδόσεων 2.6.29 και 2.6.30.

Γυρνάς όλο το source code του module στην προηγούμενη έκδοση (2.6.29) και αρχίζεις και εφαρμόζεις τις αλλαγές μία πρός μία δοκιμάζοντας αν το πρόβλημα μπορεί να αναπαραχθεί. Μπορεί φυσικά να μήν γίνεται μία αλλαγή τη φορά, μπορεί να χρειαστεί να κάνεις μιά σειρά αλλαγών που έχουν τον ίδιο σκοπό αλλά και πάλι αυτό θα βοηθήσει να εντοπίσεις το σημείο του κώδικα που προκαλεί το oops.

Το καλό είναι οτι δεν θα χρειαστεί να κάνεις συνέχεια compile ολόκληρο τον kernel μόνο το συγκεκριμένο module.

Όταν το βρείς το bug μετά θα φανεί αν είναι μόνο στο module ή πάει και πιό βαθιά.

Άντε, δεν πιστεύω να έχεις τίποτα να κάνεις για τις επόμενες 48 ώρες

 

EDIT: άκυρο, το παραπάνω (όχι εντελώς αλλά anyway)

Αυτό που σου λένε να κάνεις είναι να πάρεις το tree του 2.6.29, να το κάνεις build και να δείς αν είναι όλα ΟΚ.

Μετά μέσω του git αρχίζεις και κάνεις update το tree σε κάθε revision που βγήκε μέχρι να βγεί η έκδοση 2.6.30. Μόλις εντοπίσεις σε ποιό rev δημιουργείται το πρόβλημα, τότε βλέπεις τις αλλαγές στον κώδικα του kernel που έγιναν και εντοπίζεις (στο περίπου ) το πρόβλημα.

 

EDIT2: Από εδώ:

One of the many nice tools offered by the git source code management system is called "bisect." The bisect feature helps the user perform a binary search through a range of patches until the one containing the bug is found. All that is needed is to specify the most recent kernel which is known to work (2.6.24, say), and the oldest kernel which is broken (2.6.25-rc9, perhaps), and the bisect feature will check out a version of the kernel at the midpoint between those two. Finding that midpoint is non-trivial, since, in git, the stream of patches is not a simple line. But that's the sort of task we keep computers around for. Once the midpoint kernel has been generated, the person chasing the bug can build and test it, then tell git whether it exhibits the bug or not. A kernel at the new midpoint will be produced, and the process continues. With bisect, the problematic patch can be found in a maximum of a dozen or so compile-boot-test cycles.

[gtroza]

καλή αρχή firewalker !

 

γειά σου Nullscan!

 

τώρα που λείπει ο κύριος (apoikos)

άρχισαν τα "μεταπτυχιακά" ;

μένει να συμπληρώσει ο nske!

 

καλό καλοκαίρι !

.

[alkisg]

Καλό το git bisect, μου το είχαν προτείνει κι εμένα για να εντοπίσω ακριβώς ένα regression του gpxe. Δεν είναι απαραίτητο· απλά διευκολύνει την αναζήτηση της έκδοσης που εισήχθηκε το πρόβλημα βοηθώντας σε να κάνεις δυαδική αναζήτηση αντί για σειριακή, έτσι ώστε να χρειάζονται μόνο log2(N) builds αντί για N builds για να εντοπίσεις το regression...

 

Πάει ως εξής:

git clone

git checkout master

git bisect start # Αρχίζει η δυαδική αναζήτηση του προβλήματος

git bisect bad # Δηλώνεις ότι το master είναι bad

git bisect good v0.9.6 # Δηλώνεις ότι κάποια version, π.χ. η v0.9.6, είναι καλή, ώστε να είναι το άλλο άκρο της αναζήτησης

 

Μετά από αυτά, κάνεις compile και μαρκάρεις κάθε έκδοση με "git bisect good" αν δουλεύει ή "git bisect bad" αν δεν δουλεύει.

 

Τελικά, μόλις τελειώσει η αναζήτηση, θα σου απαντήσει με κάτι σαν:

alkisg@alkis:~/tmp/gpxe$ git bisect bad

Bisecting: 0 revisions left to test after this

[f16668dd600c266ee573badc295745cbb0c0f879] [romprefix] Update ROM checksum even if PMM allocation fails

 

Σε αυτό το σημείο έχεις το συγκεκριμένο revision που έβγαλε το πρόβλημα και μπορείς να τους το στείλεις.

 

Καλημέρα firewalker, NullScan, gtroza!

[firewalker]

Καλημέρα παλικάρια! άντε να δούμε. Πρέπει να βρούμε χρόνο για διάβασμα πάλι...

 

Σε εμένα δούλευε μέχρι και τον kernel26-2.6.29.4 μπορώ να τραβήξω μόνο αυτό το branch ή πρέπει να κάνω

 

git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git

[gtroza]

καλημέρα

στους εθελοντές GNUistas και BSDistas

γειά σου alkisg

.

[firewalker]

Έκανα 16 απανωτά kernel compiles (από ~2,5 ώρες το καθένα)... Νομίζω όμως ότι τον βρήκα τον ένοχο.

[NullScan]

2.5 ώρες το καθένα? Σε τί το έκανες το compile, σε τοστιέρα ?

[firewalker]

2.5 ώρες το καθένα? Σε τί το έκανες το compile, σε τοστιέρα ?

 

Χα, χα, χα...

 

 

Βάζω και τις δοκιμές μέσα σε κάθε compile. Οπότε βγάλε κανα μισάωρο.

 

Σε έναν Pentium 4 @ 2,4 GHz με 768 Mbytes RAM σε 40 G δίσκο με 1,2 G ελεύθερα. Τον χρησιμοποιούσα κανονικά όταν έκανε το compile. Αν το έβαζα σε κονσόλα με τον X "κάτω" τελείωνε αρκετά ποιο γρήγορα. Σε καινούρια συστήματα (dual core κ.τ.λ.) πόσο κάνει;

[nske]

Με μόνο τα απαραίτητα στο .config, λίγο λιγότερο :-P

 

># make clean && time make -j3
real    3m49.158s
user    6m27.896s
sys     0m59.088s

(AMD 64 X2 5600+, 2GB RAM)

[firewalker]

Άμα το ξεβράκωσες όλο το .config... :-)

 

Βάζεις μόνο τους drivers που σε ενδιαφέρουν και καθαρίζεις.

 

Η μαλακία είναι ότι μάλλον άδικα τα έκανα. Δεν εντοπίστηκε το πρόβλημα.