ການສະໜອງຮ່ອງຮອຍການເຮັດວຽກ (Stack Trace)

Michael Schwendt, Rahul Sundaram, Ankur Sinha Version unspecified Last review: 2014

ໜ້ານີ້ຖືກຄັດລອກມາຈາກເອກະສານ Fedora Wiki ສະບັບກ່ອນ.

ມັນໄດ້ຖືກປັບປຸງເພື່ອເຜີຍແຜ່ຢູ່ທີ່ນີ້ໃນ Fedora Docs Portal, ແຕ່ຍັງບໍ່ທັນໄດ້ຮັບການກວດສອບຄວາມຖືກຕ້ອງທາງດ້ານເຕັກນິກເທື່ອ.

ມັນອາດຈະ

  • ມີບັນຫາເລື່ອງຮູບແບບ

  • ຫຼ້າສະໄໝ

  • ຕ້ອງການການປັບປຸງເພີ່ມເຕີມ

ການກວດສອບຄວາມຖືກຕ້ອງທາງດ້ານເຕັກນິກແມ່ນເປັນສິ່ງທີ່ດີຫຼາຍ. ຖ້າທ່ານຕ້ອງການຊ່ວຍ, ໃຫ້ເບິ່ງທີ່ ໄຟລ໌ README ໃນຄັງເກັບຂໍ້ມູນຕົ້ນສະບັບສຳລັບຄຳແນະນຳ.

ຍອມຮັບການດຶງຂໍ້ມູນການປ່ຽນແປງ (Pull requests) ທີ່ https://forge.fedoraproject.org/docs/quick-docs

ເມື່ອທ່ານແກ້ໄຂໜ້ານີ້ແລ້ວ, ໃຫ້ລຶບແຈ້ງການນີ້ອອກ.
ຮ່ອງຮອຍການເຮັດວຽກ (Stack trace) ແມ່ນຂໍ້ມູນທີ່ສຳຄັນທີ່ສຸດຢ່າງໜຶ່ງທີ່ທ່ານສາມາດສະໜອງໃຫ້ເພື່ອຊ່ວຍໃຫ້ຜູ້ອື່ນແກ້ໄຂຈຸດບົກພ່ອງຂອງແອັບພລິເຄຊັນທີ່ຢຸດເຮັດວຽກທີ່ຜິດພາດ. ໜ້ານີ້ຈະລົງລາຍລະອຽດກ່ຽວກັບຄວາມສຳຄັນຂອງຮ່ອງຮອຍການເຮັດວຽກ ແລະ ແນະນຳຫຼາຍວິທີໃນການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກ.

ຖ້າທ່ານພົບກັບບັນຫາແອັບພລິເຄຊັນຢຸດເຮັດວຽກ, ຂັ້ນຕອນພື້ນຖານໃນການສ້າງຮ່ອງຮອຍການເຮັດວຽກທີ່ມີປະໂຫຍດ ສຳລັບແອັບພລິເຄຊັນ Gnome desktop ທົ່ວໄປມີດັ່ງນີ້:

  • ຕິດຕັ້ງ -debuginfo RPM(s) ທີ່ເໝາະສົມກ່ອນທີ່ຈະເກີດການຢຸດເຮັດວຽກ (ເບິ່ງພາກ "RPMs debuginfo ແມ່ນຫຍັງ, ແລະ ຂ້ອຍຈະເອົາມັນໄດ້ແນວໃດ?" ທາງລຸ່ມ).

  • ລໍຖ້າໃຫ້ເກີດການຢຸດເຮັດວຽກ ຫຼື ເຮັດຕາມຂັ້ນຕອນທີ່ເຮັດໃຫ້ມັນເກີດຂຶ້ນຄືນໃໝ່.

  • ABRT (Automatic Bug Reporting Tool) ໃນ Fedora ຈະກວດຫາການຢຸດເຮັດວຽກໂດຍອັດຕະໂນມັດ ແລະ ດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກມາໃຫ້.

  • ລວມເອົາຮ່ອງຮອຍການເຮັດວຽກໃນລາຍງານຈຸດບົກພ່ອງຂອງທ່ານ (ເບິ່ງເອກະສານ "ວິທີການລາຍງານຈຸດບົກພ່ອງ" ສຳລັບຄຳແນະນຳທັງໝົດ).

ຖ້າ ABRT ບໍ່ເລີ່ມເຮັດວຽກໂດຍອັດຕະໂນມັດ, ທ່ານຈະຕ້ອງເລີ່ມໂປຣແກຣມດ້ວຍວິທີພິເສດ ໂດຍໃຊ້ເຄື່ອງມືແກ້ໄຂຈຸດບົກພ່ອງ (ເຊັ່ນ gdb). ເບິ່ງພາກ ການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກໂດຍໃຊ້ GDB ພຽງຢ່າງດຽວ ທາງລຸ່ມ.

ມີຄຳແນະນຳພິເສດສຳລັບ ໂປຣແກຣມ Java ແລະ Firefox.

ຮ່ອງຮອຍການເຮັດວຽກ (Stack trace ຫຼື backtrace) ແມ່ນຫຍັງ?

ຮ່ອງຮອຍການເຮັດວຽກ (ບາງຄັ້ງເອີ້ນວ່າ backtrace) ແມ່ນລາຍຊື່ຂອງການເອີ້ນຟັງຊັນທີ່ນຳໄປສູ່ຈຸດໃດໜຶ່ງໃນໂປຣແກຣມ. ເຄື່ອງມືແກ້ໄຂຈຸດບົກພ່ອງ ເຊັ່ນ gdb ຫຼື bug-buddy ສາມາດດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກຈາກແອັບພລິເຄຊັນທີ່ຢຸດເຮັດວຽກ ເພື່ອໃຫ້ຜູ້ພັດທະນາສາມາດຊອກຫາໄດ້ວ່າເກີດຫຍັງຂຶ້ນ.

ຮ່ອງຮອຍການເຮັດວຽກມີລັກສະນະຄືແນວໃດ?

ຮ່ອງຮອຍການເຮັດວຽກທົ່ວໄປຈະມີລັກສະນະຄ້າຍຄືກັບຕົວຢ່າງລຸ່ມນີ້:

[New Thread 8192 (LWP 15167)]

0x420ae169 in wait4 () from /lib/i686/libc.so.6
.
.
.

ຮ່ອງຮອຍການເຮັດວຽກທີ່ດີກວ່າ, ເຊິ່ງມີສັນຍະລັກ debuginfo (ເບິ່ງທາງລຸ່ມ) ຈະມີລັກສະນະດັ່ງນີ້:

0x000000350a6c577f in *__GI___poll (fds=0xe27460, nfds=9, timeout=-1) at ../sysdeps/unix/sysv/linux/poll.c:83
83          return INLINE_SYSCALL (poll, 3, CHECK_N (fds, nfds), nfds, timeout);

.
.
.

ສັງເກດເຫັນຊື່ໄຟລ໌ ແລະ ເລກແຖວທີ່ຟັງຊັນຖືກເອີ້ນປາກົດຂຶ້ນມາ.

ສັນຍະລັກການແກ້ໄຂຈຸດບົກພ່ອງ (Debugging symbols) ແມ່ນຫຍັງ, ແລະ ເປັນຫຍັງພວກມັນຈຶ່ງສຳຄັນ?

ເມື່ອໂປຣແກຣມຖືກຄອມໄພລ໌ (compiled) ດ້ວຍຄຳສັ່ງພິເສດເພື່ອສ້າງສັນຍະລັກການແກ້ໄຂຈຸດບົກພ່ອງ (ຄຳສັ່ງ -g), ຂໍ້ມູນເພີ່ມເຕີມຈະຖືກເກັບໄວ້ໃນໄຟລ໌ໂປຣແກຣມ. ຂໍ້ມູນນີ້ສາມາດຖືກນຳໃຊ້ເພື່ອສ້າງຮ່ອງຮອຍການເຮັດວຽກທີ່ມີຂໍ້ມູນຫຼາຍຂຶ້ນ, ເຊັ່ນ ເລກແຖວທີ່ແນ່ນອນຂອງໄຟລ໌ຕົ້ນສະບັບທີ່ເກີດບັນຫາ. ຖ້າບໍ່ມີຂໍ້ມູນນີ້, ມັນຈະຍາກຫຼາຍທີ່ຈະບົ່ງບອກໄດ້ວ່າເກີດຫຍັງຂຶ້ນຜ່ານການເບິ່ງຮ່ອງຮອຍການເຮັດວຽກ.

RPMs debuginfo ແມ່ນຫຍັງ, ແລະ ຂ້ອຍຈະເອົາມັນໄດ້ແນວໃດ?

Fedora ປະກອບມີ RPMs ປະເພດພິເສດທີ່ເອີ້ນວ່າ debuginfo RPMs. RPMs ທີ່ຖືກສ້າງຂຶ້ນໂດຍອັດຕະໂນມັດເຫຼົ່ານີ້ ປະກອບດ້ວຍຂໍ້ມູນການແກ້ໄຂຈຸດບົກພ່ອງຈາກໄຟລ໌ໂປຣແກຣມ, ແຕ່ຖືກຍ້າຍໄປໄວ້ໃນໄຟລ໌ພາຍນອກ. ເຄື່ອງມືທັງໝົດທີ່ຈັດການຂໍ້ມູນການແກ້ໄຂຈຸດບົກພ່ອງຮູ້ວິທີຊອກຫາຂໍ້ມູນໃນໄຟລ໌ເຫຼົ່ານີ້ໂດຍອັດຕະໂນມັດ. ສິ່ງນີ້ຊ່ວຍໃຫ້ທ່ານຕິດຕັ້ງຂໍ້ມູນການແກ້ໄຂຈຸດບົກພ່ອງໄດ້ງ່າຍເມື່ອຕ້ອງການ. ທ່ານຕ້ອງຕິດຕັ້ງ ເວີຊັນ (version) ແລະ ສະຖາປັດຕະຍະກຳ (architecture) ຂອງ debuginfo ໃຫ້ກົງກັນກັບແອັບພລິເຄຊັນທີ່ທ່ານກຳລັງພະຍາຍາມແກ້ໄຂ.

ຕົວຢ່າງ: ການກວດສອບເວີຊັນ ແລະ ສະຖາປັດຕະຍະກຳ ໃຫ້ກົງກັນ

$ rpm -q --qf '%{name}-%{version}-%{release}.%{arch}\n' gaim gaim-debuginfo
gaim-2.0.0-0.26.beta5.i386
gaim-debuginfo-2.0.0-0.26.beta5.i386

ແຕ່ລະແພັກເກດທີ່ມີໄຟລ໌ binary ໃນຊຸດຊອບແວ (distribution) ຈະມີແພັກເກດ debuginfo ທີ່ກົງກັນ.

ການຕິດຕັ້ງ RPMs debuginfo ໂດຍໃຊ້ DNF

debuginfo-install ແມ່ນປລັກອິນ (plugin) ທີ່ສະດວກ, ເປັນສ່ວນໜຶ່ງຂອງແພັກເກດ dnf-plugins-core, ເຊິ່ງຈະເປີດໃຊ້ຄັງເກັບ debuginfo ໂດຍອັດຕະໂນມັດ ແລະ ດາວໂຫຼດທຸກແພັກເກດ debuginfo ທີ່ຈຳເປັນ. ທ່ານສາມາດໃຊ້ຄຳສັ່ງ:

$ sudo dnf debuginfo-install <pkg-spec>

ເພື່ອຕິດຕັ້ງທຸກແພັກເກດ debuginfo ທີ່ຈຳເປັນສຳລັບແພັກເກດ <pkg-spec>.

ເພື່ອຕິດຕັ້ງສະເພາະແພັກເກດ debuginfo ທີ່ຈຳເປັນແທ້ໆ, ໃຫ້ໃຊ້ຄຳສັ່ງລາຍຊື່ແພັກເກດ (ໂດຍທີ່ຍັງບໍ່ທັນຕິດຕັ້ງແທ້) ເພື່ອເບິ່ງຊື່ແພັກເກດ debuginfo ແລະ ຄັງເກັບຊອບແວທີ່ກ່ຽວຂ້ອງ. ຈາກນັ້ນສ້າງຄຳສັ່ງຕິດຕັ້ງຕາມຕົວຢ່າງລຸ່ມນີ້:

$ sudo dnf --enablerepo=fedora-debuginfo --enablerepo=updates-debuginfo install <pkg-spec>-debuginfo

ສິ່ງນີ້ມີປະໂຫຍດເມື່ອທ່ານບໍ່ຕ້ອງການຕິດຕັ້ງ debuginfo ສຳລັບທຸກໆສ່ວນທີ່ກ່ຽວຂ້ອງ (dependencies) ຂອງແພັກເກດທີ່ກຳລັງແກ້ໄຂ, ເນື່ອງຈາກ debuginfo ຂອງພວກມັນມັກຈະບໍ່ຈຳເປັນ.

ການຕິດຕັ້ງ RPMs debuginfo ໂດຍໃຊ້ yum

debuginfo-install ແມ່ນເຄື່ອງມືທີ່ສະດວກ, ເປັນສ່ວນໜຶ່ງຂອງແພັກເກດ yum-utils, ເຊິ່ງຈະເປີດໃຊ້ຄັງເກັບ debuginfo ໂດຍອັດຕະໂນມັດ ແລະ ດາວໂຫຼດທຸກແພັກເກດ debuginfo ທີ່ຈຳເປັນ. ທ່ານສາມາດໃຊ້ຄຳສັ່ງ:

$ sudo debuginfo-install foo

ເພື່ອຕິດຕັ້ງທຸກແພັກເກດ debuginfo ທີ່ຈຳເປັນສຳລັບແພັກເກດ foo.

ເພື່ອຕິດຕັ້ງສະເພາະແພັກເກດ debuginfo ທີ່ຈຳເປັນແທ້ໆ, ໃຫ້ໃຊ້ຜົນໄດ້ຮັບຈາກ debuginfo-install (ໂດຍທີ່ຍັງບໍ່ທັນຕິດຕັ້ງແທ້) ເພື່ອເບິ່ງຊື່ແພັກເກດ debuginfo ແລະ ຄັງເກັບຊອບແວທີ່ກ່ຽວຂ້ອງ. ຈາກນັ້ນສ້າງຄຳສັ່ງຕິດຕັ້ງຕາມຕົວຢ່າງລຸ່ມນີ້:

$ sudo yum --enablerepo fedora-debuginfo,updates-debuginfo install foo-debuginfo

ສິ່ງນີ້ມີປະໂຫຍດເມື່ອທ່ານບໍ່ຕ້ອງການຕິດຕັ້ງ debuginfo ສຳລັບທຸກໆສ່ວນທີ່ກ່ຽວຂ້ອງ (dependencies) ຂອງແພັກເກດທີ່ກຳລັງແກ້ໄຂ, ເນື່ອງຈາກ debuginfo ຂອງພວກມັນມັກຈະບໍ່ຈຳເປັນ.

ການຕິດຕັ້ງ RPMs debuginfo ດ້ວຍຕົນເອງ

ແພັກເກດເຫຼົ່ານີ້ສາມາດດາວໂຫຼດໄດ້ຈາກ fedora mirrors ປົກກະຕິ ໃນໂຟນເດີຍ່ອຍ "debug" ຂອງໂຟນເດີສະຖາປັດຕະຍະກຳ. ຕົວຢ່າງ, ແພັກເກດ debuginfo ສຳລັບເວີຊັນພັດທະນາຫຼ້າສຸດແມ່ນມີໃຫ້ຢູ່ທີ່ http://mirrors.fedoraproject.org/publiclist/Fedora/development/ . ກະລຸນາໃຊ້ mirror ທີ່ຢູ່ໃກ້ທ່ານທີ່ສຸດໃນການດາວໂຫຼດ.

ຜູ້ສ້າງແພັກເກດ

ຖ້າທ່ານເປັນຜູ້ສ້າງແພັກເກດທີ່ກຳລັງຊອກຫາຂໍ້ມູນກ່ຽວກັບ RPMs debuginfo, ໃຫ້ເບິ່ງເອກະສານ ແພັກເກດ Debuginfo.

ຂ້ອຍຈະສ້າງ backtrace ໄດ້ແນວໃດ?

ທຳອິດ ໃຫ້ແນ່ໃຈວ່າທ່ານໄດ້ຕິດຕັ້ງແພັກເກດ debuginfo ສຳລັບແອັບພລິເຄຊັນທີ່ທ່ານກຳລັງແກ້ໄຂ ແລະ ຫ້ອງສະໝຸດ (libraries) ທີ່ກ່ຽວຂ້ອງທັງໝົດ. ຜູ້ພັດທະນາມັກຈະບອກໃຫ້ທ່ານຕິດຕັ້ງແພັກເກດ debuginfo ສະເພາະໃດໜຶ່ງ ເພາະວ່າເຂົາເຈົ້າ ສາມາດບອກໄດ້ຈາກຮ່ອງຮອຍການເຮັດວຽກວ່າຫ້ອງສະໝຸດໃດມີສ່ວນກ່ຽວຂ້ອງກັບການຢຸດເຮັດວຽກ. ເບິ່ງທາງລຸ່ມສຳລັບແພັກເກດທີ່ແນະນຳສຳລັບແອັບພລິເຄຊັນທົ່ວໄປ.

ມີຫຼາຍວິທີໃນການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກ:

ຂ້ອຍຄວນຕິດຕັ້ງແພັກເກດ debuginfo ໃດແດ່?

ຢ່າງໜ້ອຍທີ່ສຸດ ທ່ານຈະຕ້ອງຕິດຕັ້ງແພັກເກດ debuginfo ສຳລັບແອັບພລິເຄຊັນທີ່ຢຸດເຮັດວຽກ. ທ່ານສາມາດຊອກຫາໄດ້ວ່າແອັບພລິເຄຊັນນີ້ຢູ່ໃນແພັກເກດໃດໂດຍການພິມ rpm -qf path-of-program.

ສຳລັບໂປຣແກຣມບາງປະເພດ, ມັນມີປະໂຫຍດຫຼາຍທີ່ຈະຕິດຕັ້ງແພັກເກດມາດຕະຖານບາງຢ່າງທີ່ມີປະໂຫຍດ ສຳລັບເກືອບທຸກຮ່ອງຮອຍການເຮັດວຽກ:

  • ແອັບພລິເຄຊັນ Gnome ແລະ ແອັບພລິເຄຊັນທີ່ໃຊ້ Gtk+: glib2-debuginfo, pango-debuginfo, gtk2-debuginfo

  • ແອັບພລິເຄຊັນ KDE: qt-debuginfo, kdelibs-debuginfo

ການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກໂດຍໃຊ້ GDB ພຽງຢ່າງດຽວ

ຖ້າທ່ານກຳລັງໃຊ້ໂປຣແກຣມ Java ເຊັ່ນ Eclipse ຫຼື Tomcat, ສະຖານະການຈະສັບສົນຂຶ້ນເລັກນ້ອຍ - ເບິ່ງ ໂປຣແກຣມ Java ສຳລັບລາຍລະອຽດ.

ທຳອິດ, ໃຫ້ໃຊ້ຄຳສັ່ງລຸ່ມນີ້ເພື່ອເລີ່ມ gdb:

$ gdb name-of-program

ໂດຍທີ່ name-of-program ແມ່ນຊື່ຂອງໂປຣແກຣມທີ່ຢຸດເຮັດວຽກ (ຕົວຢ່າງ: /usr/bin/gnome-panel).

ຈາກນັ້ນ, ຢູ່ທີ່ໜ້າຈໍຄຳສັ່ງ gdb, ໃຫ້ພິມ:

run

ຖ້າທ່ານຕ້ອງການໃສ່ພາຣາມິເຕີ (arguments) ໃຫ້ກັບໂປຣແກຣມ, ໃຫ້ໃສ່ພວກມັນຫຼັງຄຳສັ່ງ run ເຊັ່ນ:

run --argument

ເມື່ອໂປຣແກຣມກຳລັງເຮັດວຽກ, ໃຫ້ເຮັດໃຫ້ເກີດການຢຸດເຮັດວຽກຄືນໃໝ່ ແລ້ວກັບໄປທີ່ terminal ທີ່ທ່ານເປີດ gdb ໄວ້. ໜ້າຈໍຄຳສັ່ງ gdb ຄວນຈະປາກົດຂຶ້ນ - ຖ້າບໍ່, ໃຫ້ກົດ Control+C ເພື່ອຢຸດການເຮັດວຽກເຂົ້າສູ່ debugger. ຢູ່ທີ່ໜ້າຈໍຄຳສັ່ງ gdb debugger, ໃຫ້ພິມ:

thread apply all bt full

ຖ້າຄຳສັ່ງນັ້ນໃຊ້ບໍ່ໄດ້ (ໝາຍຄວາມວ່າທ່ານບໍ່ໄດ້ຮັບຜົນໄດ້ຮັບໃດໆ—​ເຊິ່ງອາດຈະເກີດຂຶ້ນກັບໂປຣແກຣມທີ່ບໍ່ແມ່ນ multi-threaded), ໃຫ້ພິມ <code>bt</code> ແທນ. ຖ້າທ່ານຍັງບໍ່ໄດ້ຮັບຜົນໄດ້ຮັບໃດໆ, ໃຫ້ອ່ານ [[#special| ໝາຍເຫດນີ້]] ກ່ຽວກັບການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກພາຍໃຕ້ສະຖານະການພິເສດ. ຜົນໄດ້ຮັບທີ່ອອກມາແມ່ນຮ່ອງຮອຍການເຮັດວຽກ. ໃຫ້ຄັດລອກ ແລະ ວາງທັງໝົດລົງໃນໄຟລ໌ຂໍ້ຄວາມ.

ທ່ານສາມາດອອກຈາກ gdb ໄດ້ໂດຍການພິມ quit.

ບາງຄັ້ງ, ຮ່ອງຮອຍອາດຈະມີຂະໜາດໃຫຍ່ຫຼາຍ ແລະ ຍາກທີ່ຈະຄັດລອກ ແລະ ວາງ. ໃນສະຖານະການດັ່ງກ່າວ, ການບັນທຶກຮ່ອງຮອຍລົງໃນໄຟລ໌ແມ່ນສະດວກກວ່າ:

$ gdb
> run
# program crashes
> set logging file backtrace.log
> set logging on
> thread apply all bt full
> set logging off
> quit

ການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກຈາກ core dump

ຖ້າໂປຣແກຣມທີ່ຢຸດເຮັດວຽກປະ core dump ໄວ້, ທ່ານສາມາດໃຊ້ GDB ເພື່ອດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກໄດ້. Core dumps ຈະຖືກບັນທຶກໄວ້ໃນໄຟລ໌ເທິງຮາດດິດຂອງທ່ານ ແລະ ມັກຈະມີຊື່ຄ້າຍໆກັບ "core" ຫຼື "core.3124". ເພື່ອດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກຈາກໄຟລ໌ເຫຼົ່ານີ້, ໃຫ້ໃຊ້ຄຳສັ່ງລຸ່ມນີ້:

$ gdb name-of-program core-file-name

ໂດຍທີ່ name-of-program ແມ່ນຊື່ຂອງໂປຣແກຣມທີ່ຢຸດເຮັດວຽກ (ຕົວຢ່າງ: /usr/bin/gnome-panel), ແລະ core-file-name ແມ່ນຊື່ຂອງໄຟລ໌ core ທີ່ມີຂໍ້ມູນ core dump (ຕົວຢ່າງ: core.7812).

ຈາກນັ້ນ, ຢູ່ທີ່ໜ້າຈໍຄຳສັ່ງ gdb, ໃຫ້ພິມ:

thread apply all bt full

ຖ້າຄຳສັ່ງນັ້ນໃຊ້ບໍ່ໄດ້ (ໝາຍຄວາມວ່າທ່ານບໍ່ໄດ້ຮັບຜົນໄດ້ຮັບໃດໆ—​ເຊິ່ງອາດຈະເກີດຂຶ້ນກັບໂປຣແກຣມທີ່ບໍ່ແມ່ນ multi-threaded), ໃຫ້ພິມ bt ແທນ. ຖ້າທ່ານຍັງບໍ່ໄດ້ຮັບຜົນໄດ້ຮັບໃດໆ, ໃຫ້ອ່ານ ໝາຍເຫດນີ້ ກ່ຽວກັບການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກພາຍໃຕ້ສະຖານະການພິເສດ. ຜົນໄດ້ຮັບທີ່ອອກມາແມ່ນຮ່ອງຮອຍການເຮັດວຽກ. ໃຫ້ຄັດລອກ ແລະ ວາງທັງໝົດລົງໃນໄຟລ໌ຂໍ້ຄວາມ.

ທ່ານສາມາດອອກຈາກ gdb ໄດ້ໂດຍການພິມ quit.

ໝາຍເຫດ: ການສ້າງໄຟລ໌ core ຖືກປິດໄວ້ໃນ Fedora ໂດຍຄ່າເລີ່ມຕົ້ນ (ໃນ /etc/profile). ເພື່ອເປີດໃຊ້ງານພວກມັນສຳລັບ shell session, ໃຫ້ພິມທີ່ shell prompt:

$ ulimit -c unlimited

ວິທີການຕິດຕັ້ງ ABRT

ຖ້າທ່ານຕິດຕັ້ງ Fedora ຜ່ານຮູບພາບ LiveCD, ABRT ຄວນຈະຖືກຕິດຕັ້ງໄວ້ແລ້ວ. ທ່ານຄວນຈະສາມາດເລີ່ມມັນໄດ້ຢູ່ທີ່ Applications → System Tools → Automatic Bug Reporting Tool. ຖ້າ ABRT ບໍ່ຖືກຕິດຕັ້ງໄວ້ດ້ວຍເຫດຜົນໃດໜຶ່ງ, ທ່ານສາມາດຕິດຕັ້ງມັນດ້ວຍຕົນເອງໄດ້ໂດຍການເຮັດດັ່ງນີ້ຢູ່ໜ້າຈໍຄຳສັ່ງ:

$ sudo dnf install abrt

ຫຼື ໄປທີ່ System → Administration → Add/Remove Software ໃນ Gnome, ແລ້ວພິມ abrt ໃນຊ່ອງຊອກຫາ ແລະ ເລືອກ Find. ເລືອກແພັກເກດ abrt ແລະ ນຳໃຊ້ການປ່ຽນແປງ.

ການຕັ້ງຄ່າ ABRT ສຳລັບ Bugzilla

ໄປທີ່ Application → System Tools → Automated Bug Reporting Tool ແລະ ເລືອກມັນເພື່ອເລີ່ມເຮັດວຽກດ້ວຍຕົນເອງ. ເມື່ອປ່ອງຢ້ຽມ GUI ປາກົດຂຶ້ນ, ໃຫ້ເລືອກ Edit → Plugins ແລະ ຈາກປ່ອງຢ້ຽມ Settings, ໃຫ້ເລື່ອນລົງ, ເລືອກ Bugzilla ແລະ ເລືອກ Configure Plugin. Bugzilla URL ຄວນຈະເປັນ https://bugzilla.redhat.com ແລະ ປ້ອນຊື່ຜູ້ໃຊ້ ແລະ ລະຫັດຜ່ານ Bugzilla ຂອງທ່ານເອງລົງໃນຊ່ອງທີ່ເໝາະສົມ.

ຖ້າທ່ານຍັງບໍ່ມີບັນຊີ Bugzilla, ຕອນນີ້ແມ່ນເວລາທີ່ຈະສະໝັກ, ພຽງແຕ່ໄປທີ່ URL ທີ່ສະແດງຢູ່ໃນໜ້ານັ້ນ ແລ້ວ ສ້າງບັນຊີໃໝ່.

ໃນຄັ້ງຕໍ່ໄປທີ່ໂປຣແກຣມຢຸດເຮັດວຽກ ແລະ ABRT ເຮັດວຽກ, ເມື່ອທ່ານກົດ Report, ABRT ຈະສາມາດເຂົ້າສູ່ລະບົບ Bugzilla ໂດຍອັດຕະໂນມັດ ແລະ ສົ່ງລາຍງານຈຸດບົກພ່ອງໃຫ້ທ່ານ.

ການນຳໃຊ້ ABRT

(ສ່ວນຕໍ່ໄປນີ້ສົມມຸດວ່າໃຊ້ Gnome ເປັນ desktop …​ ສຳລັບ KDE ຫຼື ອື່ນໆ ຈະຕ້ອງມີການອັບເດດໃນພາຍຫຼັງ)

ຖ້າ ABRT ກວດພົບໂປຣແກຣມທີ່ຢຸດເຮັດວຽກ, ທ່ານຈະໄດ້ຮັບການແຈ້ງເຕືອນຈາກ ABRT. ເຊິ່ງຈະມີໄຟສີແດງກະພິບຢູ່ໃນ system tray. ໃຫ້ຄລິກຊ້າຍທີ່ໄຟແຈ້ງເຕືອນນັ້ນ, ແລ້ວ Automatic Bug Reporting Tool ຄວນຈະເລີ່ມເຮັດວຽກ ແລະ ສະແດງທຸກລາຍການ ການຢຸດເຮັດວຽກທີ່ມັນໄດ້ບັນທຶກໄວ້. ເພື່ອລາຍງານຈຸດບົກພ່ອງ, ໃຫ້ຄລິກຂວາທີ່ລາຍການນັ້ນ ແລ້ວເລືອກ report. ABRT ຈະຮວບຮວມຂໍ້ມູນບັນທຶກ (logs) ທີ່ຈຳເປັນຕ້ອງສົ່ງພ້ອມກັບຈຸດບົກພ່ອງ ແລະ ຈະແຈ້ງໃຫ້ທ່ານຊາບວ່າມັນກຳລັງຈະສົ່ງລາຍງານໃນນາມຂອງທ່ານ. ຖ້າທ່ານໄດ້ຕັ້ງຄ່າ ABRT ຕາມພາກສ່ວນກ່ອນໜ້ານີ້, ມັນຈະຖາມໃຫ້ທ່ານກວດສອບວ່າຈະລວມເອົາ logs ຕ່າງໆຫຼືບໍ່, ຈາກນັ້ນມັນຈະໄປທີ່ Bugzilla ໂດຍອັດຕະໂນມັດ ແລະ ເປີດລາຍງານຈຸດບົກພ່ອງ ພ້ອມທັງແນບ logs ເຂົ້າໄປນຳ. ຫຼັງຈາກນັ້ນ ມັນຈະສະແດງເລກລາຍງານຈຸດບົກພ່ອງເພື່ອໃຫ້ທ່ານສາມາດຕິດຕາມຄວາມຄືບໜ້າໄດ້.

ການຕັ້ງຄ່າ ABRT ເມື່ອຂາດ Debuginfos

ເມື່ອທ່ານຄລິກຂວາທີ່ລາຍການຈຸດບົກພ່ອງໃນ ABRT ແລະ ເລືອກ Report, ABRT ຈະພະຍາຍາມ ໄປດຶງເອົາ logs ທີ່ຈຳເປັນຕ້ອງສົ່ງເປັນສ່ວນໜຶ່ງຂອງລາຍງານ. ຜູ້ພັດທະນາໄດ້ເພີ່ມໂຄດ ເພື່ອຊອກຫາວ່າຮ່ອງຮອຍສັນຍະລັກ (symbolic traces) ໄດ້ຖືກລວມເຂົ້າໃນ backtrace ຫຼືບໍ່, ແລະ ຖ້າມັນກວດພົບວ່າບໍ່ມີ, ABRT ຈະແຈ້ງເຕືອນທ່ານ ແລະ ສະແດງຄຳສັ່ງໃຫ້ທ່ານໃຊ້. ເຊິ່ງແມ່ນຄຳສັ່ງດຽວກັນກັບທີ່ສະແດງຢູ່ໃນພາກສ່ວນ debuginfo.

ກໍລະນີພິເສດ

ໂປຣແກຣມທີ່ເຮັດວຽກໃນນາມຜູ້ໃຊ້ອື່ນ

ຖ້າທ່ານບໍ່ໄດ້ຮັບຜົນໄດ້ຮັບໃດໆຈາກ gdb ຫຼັງຈາກພິມ thread apply all bt ຫຼື bt, ມັນອາດຈະເປັນຍ້ອນວ່າໂປຣແກຣມຖືກເປີດໃຊ້ໃນນາມ root ຫຼື ຜູ້ໃຊ້ອື່ນ. ຕົວຢ່າງໃນ GNOME, ກໍລະນີນີ້ຈະເກີດຂຶ້ນເມື່ອໃຊ້ gnome-games. ໃນກໍລະນີດັ່ງກ່າວ, ທ່ານຈຳເປັນຕ້ອງເປັນ root ເພື່ອດຶງຂໍ້ມູນຮ່ອງຮອຍ. ດັ່ງນັ້ນ, ໃຫ້ອອກຈາກ gdb, ເຂົ້າສູ່ລະບົບເປັນ root, ແລ້ວເຮັດຕາມຂັ້ນຕອນ ເພື່ອດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກຄືນໃໝ່.

Firefox

  • Install Firefox and Xulrunner debug info packages - run debuginfo-install firefox xulrunner as root on the command line.

  • ພິມ firefox -g ທີ່ໜ້າຈໍຄຳສັ່ງ. ສິ່ງນີ້ຈະເຮັດໃຫ້ Firefox ເຮັດວຽກຢູ່ພາຍໃນ gdb debugger.

  • ໃນ gdb, ທ່ານຄວນຈະເຫັນໜ້າຈໍຄຳສັ່ງ (gdb). ໃຫ້ໃຊ້ຄຳສັ່ງ run -safe-mode. ປ່ອງຢ້ຽມຈະປາກົດຂຶ້ນມາ, ໃຫ້ປິດ add-ons ທັງໝົດຢູ່ບ່ອນນີ້ ແລະ ສືບຕໍ່ໃນ safe mode.

  • ເຮັດຫຍັງກໍໄດ້ທີ່ເຮັດໃຫ້ Firefox ຢຸດເຮັດວຽກ ແລະ ເຮັດຕາມຄຳແນະນຳຂ້າງເທິງສຳລັບການນຳໃຊ້ gdb.

  • ເມື່ອ Firefox ຢຸດເຮັດວຽກ, ໃຫ້ດຶງເອົາ backtrace ແລະ ແນບມັນເຂົ້າໃນ Bugzilla.

ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ ໃຫ້ເບິ່ງ ແນວທາງການແກ້ໄຂຈຸດບົກພ່ອງສຳລັບຜະລິດຕະພັນ Mozilla.

Thunderbird

ມັນເກືອບຈະຄືກັນກັບ Firefox, ພຽງແຕ່ແພັກເກດ debug info ຈະແຕກຕ່າງກັນ. ຕິດຕັ້ງພວກມັນໂດຍໃຊ້ຄຳສັ່ງ "debuginfo-install thunderbird" ໃນນາມ root ຢູ່ທີ່ໜ້າຈໍຄຳສັ່ງ.

ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ ໃຫ້ເບິ່ງ ແນວທາງການແກ້ໄຂຈຸດບົກພ່ອງສຳລັບຜະລິດຕະພັນ Mozilla.

ໂປຣແກຣມ Java

ໃຫ້ເບິ່ງເອກະສານ ການແກ້ໄຂບັນຫາໂປຣແກຣມ Java ສຳລັບຂໍ້ມູນກ່ຽວກັບການດຶງເອົາຮ່ອງຮອຍການເຮັດວຽກຈາກໂປຣແກຣມທີ່ເຮັດວຽກດ້ວຍ Java.

ເດມອນ (Daemons) ແລະ ຂະບວນການຍ່ອຍ

ທ່ານຈະຕ້ອງຮວບຮວມ backtrace ຈາກໄຟລ໌ core.

ໃຫ້ແນ່ໃຈວ່າ initscript ຂອງເດມອນບໍ່ໄດ້ຫ້າມການຂຽນໄຟລ໌ core ລົງໃນຮາດດິດ. ໃຫ້ເພີ່ມແຖວ DAEMON_COREFILE_LIMIT=unlimited ລົງໃນໄຟລ໌ກຳນົດຄ່າໃນ /etc/sysconfig. ຕົວຢ່າງ, Bluetooth daemon (hcid) ແມ່ນໃຊ້ /etc/sysconfig/bluetooth.

ຈາກນັ້ນຕັ້ງຄ່າ kernel ເພື່ອໃຫ້ core dump ຖືກຂຽນລົງໃນສະຖານທີ່ທີ່ກຳນົດໄວ້ ເຊັ່ນ /tmp. ໃນນາມ root, ໃຫ້ພິມ:

echo /tmp/core | sudo tee /proc/sys/kernel/core_pattern

ເພື່ອເຮັດໃຫ້ການປ່ຽນແປງນີ້ມີຜົນຖາວອນ, ໃຫ້ເພີ່ມແຖວດັ່ງກ່າວລົງໃນ /etc/sysctl.conf:

kernel.core_pattern = /tmp/core

ແລະ ພິມ sysctl -p ເພື່ອນຳໃຊ້ການປ່ຽນແປງທັນທີ.

ລາຍຊື່ຮູບແບບທັງໝົດທີ່ເປັນໄປໄດ້ສຳລັບໄຟລ໌ core ແມ່ນມີໃຫ້ເບິ່ງໄດ້ຢູ່ທີ່ ເອກະສານ kernel sysctl/kernel.txt .

ສຸດທ້າຍ, ຫຼັງຈາກທີ່ເຮັດໃຫ້ບັນຫາເກີດຂຶ້ນຄືນໃໝ່ແລ້ວ, ທ່ານສາມາດກວດສອບຄືນໄດ້ວ່າໄຟລ໌ binary ໃດ ເປັນຕົວສ້າງໄຟລ໌ core ດ້ວຍຄຳສັ່ງ file /tmp/core.1234. ຈາກນັ້ນໃຫ້ເປີດ gdb ກັບໄຟລ໌ນັ້ນ ເພື່ອສ້າງຮ່ອງຮອຍການເຮັດວຽກຫຼັງການຢຸດເຮັດວຽກ (post-mortem stack trace):

$ gdb /path/to/binary/file /tmp/core.1234

ແລະ ເຮັດຕາມຄຳແນະນຳຂ້າງເທິງສຳລັບການນຳໃຊ້ gdb.

ທ່ານສາມາດທົດສອບວ່າການສ້າງໄຟລ໌ core ຈະໃຊ້ໄດ້ຫຼືບໍ່ ໂດຍການໃຊ້ຄຳສັ່ງ kill -SEGV 1234 ໂດຍທີ່ 1234 ແມ່ນໝາຍເລກ PID ຂອງໂປຣແກຣມທີ່ທ່ານກຳລັງທົດສອບ.

ເຄື່ອງມືອື່ນໆ

Valgrind

ເຄື່ອງມືທີ່ຍອດຢ້ຽມ valgrind ມັກຈະສາມາດບອກລາຍລະອຽດໄດ້ຫຼາຍກວ່າ ກ່ຽວກັບສິ່ງທີ່ຜິດພາດ; ມັນສາມາດໃຫ້ຮ່ອງຮອຍການເຮັດວຽກໄປຈົນເຖິງຈຸດທີ່ເລີ່ມມີບັນຫາ, ເຊິ່ງອາດຈະເກີດຂຶ້ນກ່ອນທີ່ໂປຣແກຣມຈະຢຸດເຮັດວຽກແທ້ໆເປັນເວລານານ. ໂປຣແກຣມທີ່ໃຊ້ຜ່ານ valgrind ຈະເຮັດວຽກຊ້າລົງຫຼາຍ ແລະ ໃຊ້ໜ່ວຍຄວາມຈຳຫຼາຍຂຶ້ນ, ແຕ່ວ່າມັນຈະໃຫ້ຂໍ້ມູນທີ່ມີປະໂຫຍດຢ່າງຫຼວງຫຼາຍ.

ເມື່ອຕິດຕັ້ງ valgrind ແລ້ວ (dnf install valgrind), ທ່ານສາມາດໃຊ້ມັນກັບໂປຣແກຣມໄດ້:

valgrind name-of-program program-arguments

ຖ້າຕິດຕັ້ງ debuginfo ແລ້ວ, ຮ່ອງຮອຍການເຮັດວຽກຈະໃຊ້ຊື່ສັນຍະລັກ (symbolic names). ເບິ່ງ [http://valgrind.org/ valgrind.org] ສຳລັບຂໍ້ມູນເພີ່ມເຕີມ ແລະ ເຄັດລັບຕ່າງໆ.

strace

strace ສາມາດຕິດຕາມທຸກໆ system calls ທີ່ໂປຣແກຣມໃຊ້, ເຊິ່ງກໍມີປະໂຫຍດໃນການແກ້ໄຂບັນຫາ, ເຖິງແມ່ນວ່າມັນຈະບໍ່ສາມາດສ້າງຮ່ອງຮອຍການເຮັດວຽກ (stack traces) ໄດ້ກໍຕາມ. ຕິດຕັ້ງດ້ວຍຄຳສັ່ງ dnf install strace, ແລະ ເບິ່ງ man strace ສຳລັບລາຍລະອຽດ.

ສະຖານະການໄດ້ຮັບການປັບປຸງດີຂຶ້ນແດ່ແລ້ວ. ຕອນນີ້ມີຟີເຈີ stack trace ຖືກເພີ່ມເຂົ້າແລ້ວ (strace -k). ແຕ່ມັນຖືກປິດໄວ້ໃນຕອນສ້າງ (building) ເພາະວ່າການເຮັດວຽກຍັງບໍ່ທັນ ໝັ້ນຄົງເທິງລະບົບ i386.

ເອກະສານອ້າງອີງ

Want to help? Learn how to contribute to Fedora Docs ›