আমার প্রোগ্রামটি এইভাবে পরিচালিত হয়:
exe -p param1 -i param2 -o param3
এটি ক্রাশ হয়ে একটি কোর ডাম্প ফাইল তৈরি করেছে core.pid,।
আমি কোর ডাম্প ফাইলটি বিশ্লেষণ করতে চাই
gdb ./exe -p param1 -i param2 -o param3 core.pid
তবে জিডিবি এক্সডি ফাইলের পরামিতিগুলিকে জিডিবির ইনপুট হিসাবে স্বীকৃতি দেয়।
এই পরিস্থিতিতে একটি কোর ডাম্প ফাইল কীভাবে বিশ্লেষণ করব?
উত্তর:
আপনি জিডিবি সহ কোরটি বিভিন্ন উপায়ে ব্যবহার করতে পারেন, তবে এক্সিকিউটেবলের কাছে জিডিবিতে যে পরামিতিগুলি প্রেরণ করা হবে তা মূল ফাইলটি ব্যবহার করার উপায় নয়। আপনি যে ত্রুটি পেয়েছিলেন এটিও এটি হতে পারে। আপনি নিম্নলিখিত পদ্ধতিতে মূল ফাইলটি ব্যবহার করতে পারেন:
gdb <executable> <core-file>বা gdb <executable> -c <core-file>বা
gdb <executable>
...
(gdb) core <core-file>
কোর ফাইলটি ব্যবহার করার সময় আপনাকে আর্গুমেন্টগুলি পাস করতে হবে না। ক্র্যাশ পরিস্থিতি জিডিবিতে দেখানো হয়েছে (উবুন্টুতে জিডিবি সংস্করণ 7.1 সহ চেক করা হয়েছে)।
উদাহরণ স্বরূপ:
$ ./crash -p param1 -o param2
Segmentation fault (core dumped)
$ gdb ./crash core
GNU gdb (GDB) 7.1-ubuntu
...
Core was generated by `./crash -p param1 -o param2'. <<<<< See this line shows crash scenario
Program terminated with signal 11, Segmentation fault.
#0 __strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)
আপনি যদি জিডিবিতে ডিবাগ করতে এক্সিকিউটেবলের কাছে প্যারামিটারগুলি পাস করতে চান তবে ব্যবহার করুন --args।
উদাহরণ স্বরূপ:
$ gdb --args ./crash -p param1 -o param2
GNU gdb (GDB) 7.1-ubuntu
...
(gdb) r
Starting program: /home/@@@@/crash -p param1 -o param2
Program received signal SIGSEGV, Segmentation fault.
__strlen_ia32 () at ../sysdeps/i386/i686/multiarch/../../i586/strlen.S:99
99 ../sysdeps/i386/i686/multiarch/../../i586/strlen.S: No such file or directory.
in ../sysdeps/i386/i686/multiarch/../../i586/strlen.S
(gdb)
ম্যান পেজগুলি অন্যান্য জিডিবি বিকল্পগুলি দেখতে সহায়ক হবে।
সোরডাম্প ফাইলগুলি ডিবাগ করার জন্য জিডিবি এর সহজ ব্যবহার:
gdb <executable_path> <coredump_file_path>
একটি "প্রক্রিয়া" এর জন্য একটি কর্ডাম্প ফাইলটি "কোর.পিড" ফাইল হিসাবে তৈরি হয়।
আপনি জিডিবি প্রম্পটে প্রবেশ করার পরে (উপরের কমান্ডটি কার্যকর করার সময়) টাইপ করুন:
...
(gdb) where
এটি আপনাকে স্ট্যাকের তথ্য সরবরাহ করবে, যেখানে আপনি ক্র্যাশ / ফল্টের কারণ অ্যানালাইজ করতে পারবেন। অন্যান্য আদেশ, একই উদ্দেশ্যে হ'ল:
...
(gdb) bt full
এটি উপরের মতোই। কনভেনশন অনুসারে, এটি পুরো স্ট্যাকের তথ্য তালিকাভুক্ত করে (যা শেষ পর্যন্ত ক্র্যাশের অবস্থানের দিকে নিয়ে যায়)।
কেবলমাত্র পরামিতিগুলি এড়িয়ে যান। জিডিবি তাদের দরকার নেই:
gdb ./exe core.pid
objdump+ + gdbন্যূনতম runnable উদাহরণ
টি এল; ডিআর:
objdump -s core মেশিনটি বাল্কে ফেলে দিতে ব্যবহার করা যেতে পারেএখন সম্পূর্ণ শিক্ষাগত পরীক্ষার জন্য:
main.c
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
int myfunc(int i) {
*(int*)(NULL) = i; /* line 7 */
return i - 1;
}
int main(int argc, char **argv) {
/* Setup some memory. */
char data_ptr[] = "string in data segment";
char *mmap_ptr;
char *text_ptr = "string in text segment";
(void)argv;
mmap_ptr = (char *)malloc(sizeof(data_ptr) + 1);
strcpy(mmap_ptr, data_ptr);
mmap_ptr[10] = 'm';
mmap_ptr[11] = 'm';
mmap_ptr[12] = 'a';
mmap_ptr[13] = 'p';
printf("text addr: %p\n", text_ptr);
printf("data addr: %p\n", data_ptr);
printf("mmap addr: %p\n", mmap_ptr);
/* Call a function to prepare a stack trace. */
return myfunc(argc);
}
সংকলন করুন, এবং কোর উত্পন্ন করতে চালান:
gcc -ggdb3 -std=c99 -Wall -Wextra -pedantic -o main.out main.c
ulimit -c unlimited
rm -f core
./main.out
আউটপুট:
text addr: 0x4007d4
data addr: 0x7ffec6739220
mmap addr: 0x1612010
Segmentation fault (core dumped)
জিডিবি আমাদের সঠিক লাইনের দিকে ইঙ্গিত করেছে যেখানে বিভাগের ত্রুটি ঘটেছে, এটি বেশিরভাগ ব্যবহারকারী ডিবাগ করার সময় যা চান:
gdb -q -nh main.out core
তারপর:
Reading symbols from main.out...done.
[New LWP 27479]
Core was generated by `./main.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000000000400635 in myfunc (i=1) at main.c:7
7 *(int*)(NULL) = i;
(gdb) bt
#0 0x0000000000400635 in myfunc (i=1) at main.c:7
#1 0x000000000040072b in main (argc=1, argv=0x7ffec6739328) at main.c:28
যা আমাদের বগি লাইন 7 এ সরাসরি দেখায়।
সিএলআই আর্গুমেন্টগুলি মূল ফাইলে সংরক্ষণ করা হয় এবং আবার পাস করার প্রয়োজন হয় না
নির্দিষ্ট সিআইএল আর্গুমেন্ট প্রশ্নের উত্তর দেওয়ার জন্য আমরা দেখতে পাই যে আমরা যদি ক্লাইট যুক্তিগুলি পরিবর্তন করি যেমন:
rm -f core
./main.out 1 2
তারপরে এটি আমাদের কমান্ডে কোনও পরিবর্তন ছাড়াই পূর্ববর্তী বাক্টরেসে প্রতিফলিত হবে:
Reading symbols from main.out...done.
[New LWP 21838]
Core was generated by `./main.out 1 2'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x0000564583cf2759 in myfunc (i=3) at main.c:7
7 *(int*)(NULL) = i; /* line 7 */
(gdb) bt
#0 0x0000564583cf2759 in myfunc (i=3) at main.c:7
#1 0x0000564583cf2858 in main (argc=3, argv=0x7ffcca4effa8) at main.c:2
সুতরাং এখন কিভাবে নোট করুন argc=3। সুতরাং এটির অর্থ অবশ্যই মূল ফাইলটি সেই তথ্য সঞ্চয় করে। আমি অনুমান করছি যে এটি এটিকে কেবল আর্গুমেন্ট হিসাবে সংরক্ষণ করে main, যেমন এটি অন্য কোনও ফাংশনের আর্গুমেন্ট সংরক্ষণ করে।
এটি বোঝা যায় যদি আপনি বিবেচনা করেন যে কোর ডাম্প অবশ্যই পুরো মেমরিটি সংরক্ষণ করবে এবং প্রোগ্রামটির স্থিতি রেজিস্টার করবে, এবং সুতরাং বর্তমান স্ট্যাকের উপর ফাংশন আর্গুমেন্টের মান নির্ধারণ করার জন্য প্রয়োজনীয় সমস্ত তথ্য এতে রয়েছে।
কম আবশ্যিক এনভায়রনমেন্ট ভেরিয়েবল পরিদর্শন কিভাবে হল: একটি কোর ডাম্প থেকে এনভায়রনমেন্ট ভেরিয়েবল পেতে কিভাবে এনভায়রনমেন্ট ভেরিয়েবল এছাড়াও মেমরি উপস্থিত তাই objdump যে তথ্য রয়েছে, কিন্তু আমি নিশ্চিত কিভাবে তাদের সব তালিকা করতে এক সুবিধামত যেতে নেই , একের পর এক আমার পরীক্ষাগুলিতে কাজ করেছে যদিও:
p __environ[0]
বিন্টিল বিশ্লেষণ
readelfএবং এর মতো বিন্টুলস সরঞ্জাম ব্যবহার করে objdumpআমরা coreমেমরি স্টেটের মতো ফাইলগুলিতে থাকা বিপুল পরিমাণে ডাম্প তথ্য জানাতে পারি।
এর বেশিরভাগ / এগুলি অবশ্যই জিডিবির মাধ্যমে দৃশ্যমান হওয়া উচিত, তবে সেই দ্বিপদী সরঞ্জামগুলি আরও বেশি বাল্ক পদ্ধতির প্রস্তাব দেয় যা নির্দিষ্ট ব্যবহারের ক্ষেত্রে উপযুক্ত, তবে জিডিবি আরও ইন্টারেক্টিভ অনুসন্ধানের জন্য আরও সুবিধাজনক।
প্রথম:
file core
আমাদের জানায় যে coreফাইলটি আসলে একটি ELF ফাইল:
core: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from './main.out'
যে কারণে আমরা সাধারণ বাইনুটিস সরঞ্জামগুলির সাহায্যে আরও সরাসরি এটি পরিদর্শন করতে সক্ষম হয়েছি।
ইএলএফ স্ট্যান্ডার্ডের একটি তাত্ক্ষণিক দৃষ্টিভঙ্গি দেখায় যে এটিতে উত্সর্গীকৃত কোনও ইএলএফ টাইপ রয়েছে:
Elf32_Ehd.e_type == ET_CORE
আরও ফর্ম্যাট তথ্য পাওয়া যাবে এখানে:
man 5 core
তারপর:
readelf -Wa core
ফাইল কাঠামো সম্পর্কে কিছু ইঙ্গিত দেয়। মেমরিটি নিয়মিত প্রোগ্রাম শিরোনামে উপস্থিত রয়েছে বলে মনে হয়:
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
NOTE 0x000468 0x0000000000000000 0x0000000000000000 0x000b9c 0x000000 0
LOAD 0x002000 0x0000000000400000 0x0000000000000000 0x001000 0x001000 R E 0x1000
LOAD 0x003000 0x0000000000600000 0x0000000000000000 0x001000 0x001000 R 0x1000
LOAD 0x004000 0x0000000000601000 0x0000000000000000 0x001000 0x001000 RW 0x1000
এবং একটি নোট অঞ্চলে আরও কিছু মেটাডেটা উপস্থিত রয়েছে , এতে উল্লেখযোগ্যভাবে prstatusপিসি রয়েছে :
Displaying notes found at file offset 0x00000468 with length 0x00000b9c:
Owner Data size Description
CORE 0x00000150 NT_PRSTATUS (prstatus structure)
CORE 0x00000088 NT_PRPSINFO (prpsinfo structure)
CORE 0x00000080 NT_SIGINFO (siginfo_t data)
CORE 0x00000130 NT_AUXV (auxiliary vector)
CORE 0x00000246 NT_FILE (mapped files)
Page size: 4096
Start End Page Offset
0x0000000000400000 0x0000000000401000 0x0000000000000000
/home/ciro/test/main.out
0x0000000000600000 0x0000000000601000 0x0000000000000000
/home/ciro/test/main.out
0x0000000000601000 0x0000000000602000 0x0000000000000001
/home/ciro/test/main.out
0x00007f8d939ee000 0x00007f8d93bae000 0x0000000000000000
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007f8d93bae000 0x00007f8d93dae000 0x00000000000001c0
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007f8d93dae000 0x00007f8d93db2000 0x00000000000001c0
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007f8d93db2000 0x00007f8d93db4000 0x00000000000001c4
/lib/x86_64-linux-gnu/libc-2.23.so
0x00007f8d93db8000 0x00007f8d93dde000 0x0000000000000000
/lib/x86_64-linux-gnu/ld-2.23.so
0x00007f8d93fdd000 0x00007f8d93fde000 0x0000000000000025
/lib/x86_64-linux-gnu/ld-2.23.so
0x00007f8d93fde000 0x00007f8d93fdf000 0x0000000000000026
/lib/x86_64-linux-gnu/ld-2.23.so
CORE 0x00000200 NT_FPREGSET (floating point registers)
LINUX 0x00000340 NT_X86_XSTATE (x86 XSAVE extended state)
objdump এর সাহায্যে সহজেই সমস্ত স্মৃতি ফেলে দিতে পারে:
objdump -s core
যেটা বহন করে:
Contents of section load1:
4007d0 01000200 73747269 6e672069 6e207465 ....string in te
4007e0 78742073 65676d65 6e740074 65787420 xt segment.text
Contents of section load15:
7ffec6739220 73747269 6e672069 6e206461 74612073 string in data s
7ffec6739230 65676d65 6e740000 00a8677b 9c6778cd egment....g{.gx.
Contents of section load4:
1612010 73747269 6e672069 6e206d6d 61702073 string in mmap s
1612020 65676d65 6e740000 11040000 00000000 egment..........
যা আমাদের রান স্টাডাউট মান সঙ্গে ঠিক মেলে।
এটি উবুন্টু 16.04 এএমডি 64, জিসিসি 6.4.0 এবং বাইনুটিলেস ২.২26.১ এ পরীক্ষা করা হয়েছিল।
থেকে আরএমএস এর gdb ডিবাগারে টিউটোরিয়াল :
prompt > myprogram
Segmentation fault (core dumped)
prompt > gdb myprogram
...
(gdb) core core.pid
...
আপনার ফাইলটি সত্যই একটি coreচিত্র - তা ব্যবহার করে পরীক্ষা করে দেখুন file।
কিছুটা ভিন্ন পদ্ধতির সাহায্যে আপনি জিডিবি সম্পূর্ণরূপে এড়িয়ে যেতে পারবেন। আপনার যা যা চান তা যদি ব্যাকট্রেস হয় তবে লিনাক্স-নির্দিষ্ট ইউটিলিটি 'ক্যাচসেগভ' SIGSEGV কে ধরবে এবং একটি ব্যাকট্র্যাস প্রদর্শন করবে।
এক্সিকিউটেবলের আর্গুমেন্ট আছে কি না তা বিবেচ্য নয়। উত্পন্ন কোর ফাইল সহ যে কোনও বাইনারিতে জিডিবি চালাতে, সিনট্যাক্সটি নীচে রয়েছে।
Syntax:
gdb <binary name> <generated core file>
Eg:
gdb l3_entity 6290-corefile
আরও বোঝার জন্য নীচের উদাহরণটি গ্রহণ করি।
bash-4.1$ **gdb l3_entity 6290-corefile**
**Core was generated** by `/dir1/dir2/dir3/l3_entity **Program terminated with signal SIGABRT, Aborted.**
#0
#1
#2
#3
#4
#5
#6
#7
#8
#9
#10
(gdb)
উপরের আউটপুট থেকে, আপনি মূল সম্পর্কে কিছু অনুমান করতে পারেন, এটি কোনও নল অ্যাক্সেস, সাইনবোর্ড ইত্যাদি whether
এই সংখ্যাগুলি 0 থেকে # 10 জিডিবির স্ট্যাক ফ্রেম। এই স্ট্যাক ফ্রেমগুলি আপনার বাইনারি নয়। উপরের 0 - 10 ফ্রেমে যদি আপনার কোনও ভুল সন্দেহ হয় তবে সেই ফ্রেমটি নির্বাচন করুন
(gdb) frame 8
এখন এটি সম্পর্কে আরও বিশদ দেখতে:
(gdb) list +
সমস্যাটি আরও তদন্ত করতে, আপনি এখানে এই সময়ে সন্দেহজনক পরিবর্তনশীল মানগুলি মুদ্রণ করতে পারেন।
(gdb) print thread_name
কেবল কমান্ডটি টাইপ করুন:
$ gdb <Binary> <codeDump>
অথবা
$ gdb <binary>
$ gdb) core <coreDump>
কোনও কমান্ড লাইন আর্গুমেন্ট সরবরাহ করার প্রয়োজন নেই। পূর্ববর্তী অনুশীলনের কারণে কোড ডাম্প উত্পন্ন হয়েছিল।
আপনি "gdb" কমান্ড ব্যবহার করে মূল ডাম্প ফাইল বিশ্লেষণ করতে পারেন।
gdb - The GNU Debugger
syntax:
# gdb executable-file core-file
example: # gdb out.txt core.xxx
exeশেল স্ক্রিপ্ট নয় (কিছু ভেরিয়েবল সেট করার জন্যfirefox? ) যেমন লিনাক্সে?