GDB bozuk yığın çerçevesi - Nasıl hata ayıklanır?

Aşağıdaki yığın izlemesine sahibim. Bundan hata ayıklama için yararlı bir şey çıkarmak mümkün mü?

Program received signal SIGSEGV, Segmentation fault.
0x00000002 in ?? ()
(gdb) bt
#0  0x00000002 in ?? ()
#1  0x00000001 in ?? ()
#2  0xbffff284 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(gdb) 

Bir aldığımızda koda bakmaya nereden başlamalıyız Segmentation faultve yığın izleme o kadar kullanışlı değil?

NOT: Kodu postalarsam, SO uzmanları bana cevabı verecektir. SO'dan rehberlik almak ve cevabı kendim bulmak istiyorum, bu yüzden kodu buraya göndermiyorum. Özür.

Bu sahte adresler (0x00000002 ve benzeri) aslında SP değerleri değil, PC değerleridir. Şimdi, sahte (çok küçük) bir PC adresiyle bu tür bir SEGV aldığınızda, zamanın% 99'u sahte bir işlev işaretçisi aracılığıyla aramaya bağlıdır. C ++ 'daki sanal çağrıların işlev işaretçileri aracılığıyla uygulandığını unutmayın, bu nedenle sanal çağrı ile ilgili herhangi bir sorun aynı şekilde ortaya çıkabilir.

Dolaylı bir çağrı talimat sadece yığını üzerine çağrısından sonra PC iter ve daha sonra hedef değeri (bu durumda sahte) Bu takdirde, yani PC'yi ayarlar olduğunu olanları, kolayca el yığın kapalı PC kahpeden onu geri alabilirsiniz . 32 bit x86 kodunda yapmanız gerekenler:

(gdb) set $pc = *(void **)$esp
(gdb) set $esp = $esp + 4

64 bit x86 koduyla ihtiyacınız olan

(gdb) set $pc = *(void **)$rsp
(gdb) set $rsp = $rsp + 8

Ardından, bir yapıp btkodun gerçekte nerede olduğunu bulabilmelisiniz .

Zamanın diğer% 1'inde hata, genellikle yığında depolanan bir dizinin taşmasıyla yığının üzerine yazılmasından kaynaklanır. Bu durumda, valgrind gibi bir araç kullanarak durum hakkında daha fazla netlik elde edebilirsiniz.

Durum oldukça basitse, Chris Dodd'un cevabı en iyisidir. NULL göstericiden atlamış gibi görünüyor.

Bununla birlikte, programın çökmeden önce kendini ayak, diz, boyun ve gözle vurması mümkündür - yığının üzerine yazmış, çerçeve işaretçisini bozmuş ve diğer kötülükleri bozmuştur. Eğer öyleyse, esrarın çözülmesinin size patates ve et göstermesi pek olası değildir.

Daha verimli çözüm, programı hata ayıklayıcı altında çalıştırmak ve program çökene kadar işlevlerin üzerinden geçmek olacaktır. Bir çökme işlevi tanımlandıktan sonra, yeniden başlayın ve bu işleve adım atın ve hangi işlevi çağırdığının çökmeye neden olduğunu belirleyin. Tek sorunlu kod satırını bulana kadar tekrarlayın. Zamanın% 75'inde, düzeltme açık olacaktır.

Durumların diğer% 25'inde, sözde rahatsız edici kod satırı kırmızı ringa balığıdır. Daha önce çok sayıda satır (belki daha önce binlerce satır) ayarlanmış (geçersiz) koşullara tepki verecektir. Durum buysa, seçilen en iyi kurs birçok faktöre bağlıdır: çoğunlukla kodu anlayışınız ve onunla deneyiminiz:

• Belki de bir hata ayıklayıcı izleme noktası ayarlamak veya printfkritik değişkenler üzerine teşhisler eklemek gerekli A ha!
• Belki farklı girdilerle test koşullarını değiştirmek, hata ayıklamadan daha fazla bilgi sağlayacaktır.
• Belki ikinci bir çift göz sizi varsayımlarınızı kontrol etmeye veya gözden kaçan kanıtları toplamaya zorlar.
• Bazen tek gereken yemeğe gitmek ve toplanan kanıtları düşünmektir.

İyi şanslar!

Yığın işaretçisinin geçerli olduğunu varsayarsak ...

Geri izlemeden SEGV'nin tam olarak nerede oluştuğunu bilmek imkansız olabilir - ilk iki yığın çerçevesinin tamamen üzerine yazıldığını düşünüyorum. 0xbffff284 geçerli bir adres gibi görünüyor, ancak sonraki ikisi değil. Yığına daha yakından bakmak için aşağıdakileri deneyebilirsiniz:

gdb $ x / 32ga $ rsp

veya bir varyant (32'yi başka bir sayı ile değiştirin). Bu, adresler (a) olarak biçimlendirilmiş dev (g) boyutundaki yığın göstericisinden başlayarak birkaç kelimeyi (32) yazdıracaktır. Biçimle ilgili daha fazla bilgi için 'yardım x' yazın.

Bu durumda, kodunuzu bazı nöbetçi "printf" ler ile kullanmak kötü bir fikir olmayabilir.

Diğer yazmaçlarınızdan birinde yığın işaretçisinin önbelleğe alınmış olup olmadığını görmek için bazılarına bakın. Oradan bir yığını geri getirebilirsin. Ayrıca, eğer bu katıştırılmışsa, genellikle yığın çok özel bir adreste tanımlanır. Bunu kullanarak, bazen iyi bir yığın da elde edebilirsiniz. Tüm bunlar, hiperuzaya atladığınızda, programınızın yol boyunca tüm hafızayı kusmadığını varsayar ...

Yığın üzerine yazılmışsa, değerler program tarafından tanınan bir şeye karşılık gelebilir.

Örneğin, kendimi yığına bakarken buldum

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000000342d in ?? ()
#2  0x0000000000000000 in ?? ()

ve 0x342d13357, bunun için uygulama günlüklerini açtığımda bir düğüm kimliği olduğu ortaya çıktı. Bu, yığın üzerine yazma işleminin gerçekleşmiş olabileceği aday sitelerin hemen daraltılmasına yardımcı oldu.