Dalam pembangunan Linux terbenam, menganalisis fail coredump ialah kaedah biasa dan kami selalunya boleh mencari tutorial penggunaan yang berkaitan di Internet. Walau bagaimanapun, terdapat beberapa artikel tentang cara menganalisis fail coredump bagi aplikasi berbilang benang. Hari ini saya akan berkongsi beberapa kes yang saya temui dalam penggunaan sebenar, dengan harapan dapat memberikan sedikit bantuan kepada semua orang. Disebabkan oleh pengehadan kod dan ruang, saya hanya akan menerangkan masalah yang saya rasa lebih tersendiri, dan menggunakan pemikiran rangka kerja untuk menyelesaikan banyak situasi fail coredump yang dihadapi.
Penulis: Nurani masih wujud
Keizinan cetak semula dan penonton: Selamat datang untuk mengikuti akaun awam WeChat: Hamebayashi-kun
Atau tambah WeChat peribadi pengarang: become_me
Semasa menyahpepijat fungsi, saya menghasilkan beberapa fail coredump dan ralat program yang berbeza berlaku. Melalui peluang ini, saya ingin berkongsi dengan semua orang. Secara umumnya, fail coredump mungkin dijana disebabkan oleh penunjuk nol, tatasusunan di luar sempadan, berbilang keluaran oleh berbilang benang, limpahan tindanan, dsb. Di sini saya telah memilih beberapa masalah yang mewakili berdasarkan situasi yang saya hadapi dan berkongsi dengan anda beberapa penyelesaian mudah.
Pertama, untuk nyahpepijat sewajarnya, kita perlu menggunakan alat gdb. Sebelum mula menganalisis fail coredump, anda perlu biasa dengan pelbagai arahan gdb. Di bawah ialah dua artikel yang saya tulis sebelum ini tentang penyahpepijatan gdb:
Satu artikel untuk bermula dengan penyahpepijatan gdb di bawah Linux (1)
Satu artikel untuk bermula dengan penyahpepijatan gdb di bawah Linux (2)
Oleh itu, artikel ini tidak akan menerangkan secara terperinci tentang kandungan ini, tetapi hanya menumpukan pada operasi sebenar yang perlu kami lakukan semasa menganalisis fail coredump.
Pertama, kita perlu nyahpepijat menggunakan fail boleh laku dengan maklumat nyahpepijat.
gdb executable_file coredump_file
Perkara pertama selepas masuk ialah menggunakan arahan bt untuk melihat maklumat tindanan
Dalam fail coredump ini, kita boleh melihat dengan mudah bahawa terdapat perbezaan data yang jelas antara alamat masuk fungsi dan fungsi ahli kelas. Kita boleh membuat kesimpulan secara langsung pada bahagian yang jelas dan kemudian menyemak butirannya.
f n
Pilih bingkai mengikut nombor bingkai Nombor bingkai boleh dilihat melalui arahan bt.
我们查看对应的第 17帧的堆栈信息
通过上面截图我们可以看到在第17帧中 this这个类实体化的地址出现了问题。
为了对比我们又查看了对应20帧的堆栈信息以及对应帧的详细信息
然后我们需要确认该指针是什么什么出现问题的,进行第20帧数据的详细查看。其中我们用p命令查看该类下面的对应的和17帧this的关系,确认gyro_在这个函数执行的时候,地址是否正确。
从上面来看在此处函数执行的时候,对应的gyro的地址还没有变成错误的0x1388。
从这里我们基本可以确认到,函数从 第20帧对应位置执行之后再到17帧的函数的时候,执行函数的地址发生了改变 然后开始进入校对代码的环节。
这个时候校对不是看代码执行的具体情况,因为发生问题的部分已经是被修改了指针地址。所以我们需要从全局去看这个实体类被进行实体化和释放操作的地方。
最终找到了一个出现线程调用先后顺序导致变量没有准备好,出现的死机情况。
进入之后第一件事情 使用 bt命令查看堆栈信息
这个coredump文件在使用bt命令之后发现 此处的堆栈信息看上去都很正常,无法显示出代码在哪里了出现了问题。
这个时候我们就要考虑多线程时候,堆栈信息不一定直接捕获到对应线程,我们需要打开所有线程里面的堆栈信息。
thread apply all bt
除了bt大家也可以打印自己需要的其他信息
thread apply all command //所有线程都执行命令
对应打印出所有线程的堆栈信息之后,我们就进行一点点查看,但是如果你的代码定义了 信号处理函数,例如我使用了 handle_exit进行处理,然后我就在所有线程堆栈信息里面去搜索对应最后面信号处理的函数,再往回查看程序执行的过程。
此时我们发现led一个实体化类的的初始地址出现了问题,最后校验代码,发现了这个bug。
进入之后第一件事情 使用 bt命令查看堆栈信息
此时发现当前堆栈信息也无法进行定位到问题。
Kemudian kami menggunakan thread apply all bt
tetapi kami tidak melihat fungsi hand_exit yang sepadan pada kali pertama
Kemudian kami menggunakan info locals
untuk melihat maklumat pembolehubah setempat yang disimpan
info f addr
打印通过addr指定帧的信息。info args
Cetak nilai pembolehubah fungsi.
info locals
Cetak maklumat pembolehubah setempat.
info catch
Cetak maklumat pengendalian pengecualian dalam fungsi semasa.
Pembolehubah setempat juga tidak mempunyai sebarang petunjuk jelas tentang ralat penunjuk atau data di luar sempadan.
Jadi kami menggunakan arahan p
untuk mencetak maklumat pembolehubah yang disimpan dalam maklumat bingkai.
Dengan mencetak maklumat berubah-ubah ini yang kami fikir mempunyai kadar ralat yang tinggi, ia boleh membantu kami membuat pertimbangan. Walau bagaimanapun, tiada cara untuk mengesahkan lokasi masalah dengan percetakan ini.
Kemudian kami melihat semula maklumat tindanan semua benang. Akhirnya, saya melihat parameter tidak normal Nilai ini sangat besar dan agak tidak normal.
Kemudian kami menyemak lokasi kod sumber yang sepadan Kerana ia adalah perpustakaan C++, kami terus melihat kod di lokasi kompilasi.
Lihat maklumat yang dipaparkan dalam bingkai 7 dahulustl_algobase.h:465
Selepas membuka lokasi kod yang sepadan, kami mendapati bahawa parameter **__n** ialah parameter untuk jumlah ruang yang diperuntukkan.
Lihat sekali lagi sebelum dan selepas pelaksanaan stl_vector.h:343
__n yang diluluskan sekarang adalah lebih kurang nilai unit lebih daripada 100 juta, dan lokasi kerja sebenar kod tersebut tidak memerlukan peruntukan ruang yang begitu besar. Oleh itu, disahkan bahawa terdapat masalah di sini Selepas membandingkan lokasi pelaksanaan kod dan penggunaan global pembolehubah yang sepadan, pada dasarnya ditentukan bahawa baris gilir digunakan oleh berbilang benang dan kunci tidak digunakan dengan betul, mengakibatkan berbilang. benang dalam keadaan yang melampau, operasi output dan input Akan dijalankan di kawasan yang sama, menyebabkan kod ranap kali ini.
Ini adalah analisis fail coredump dalam projek yang saya kongsikan Jika anda mempunyai idea dan keperluan yang lebih baik, anda dialu-alukan untuk menambah saya sebagai rakan untuk berkomunikasi dan berkongsi.
Selain arahan yang digunakan dalam artikel saya, anda juga boleh menggunakan lebih banyak arahan untuk membantu penyahpepijatan gbd untuk menyemak fail coredump kami. Contohnya, lihat kod pemasangan dan sebagainya. Masih terdapat banyak artikel tentang arahan penyahpepijatan gdb di Internet Anda juga boleh membaca artikel lain untuk membantu anda menggunakan arahan tersebut.
Atas ialah kandungan terperinci Perkongsian praktikal analisis fail coredump pembangunan Linux. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!