Re: [Crash-utility] About the use of 'gcore'

Hello all, First of all, I wish a Happy New Year (with less crash, but still enhanced tools...) Thanks for the links, they were very useful. I dig further in the way of analyzing the User Space, but it seems that I'm linked to a dead-end way. Below is a snapshot of kernel / userland stack dump. What I've done : - Crash is triggered by a page fault inside a kernel module (write 0 in 0xFFFFFFFF, classic). - Using gcore to create the 'core.<pid>.bash (which is the user task running at time of crash). - Evaluating an EBP (between { }) chaining value (hypothesis), EIP value (between [ ]) is then just pushed beside The purpose of this study is to find a method to analyze futur crashes from kernel space down to user space applications. Do you have an idea about the cause of this non-dumping of the memory in user-space ? Should I use other extension as 'gcore' ? Thank in advance. Best regards, Patrick Agrain ------- =============================================================================== --------------------- Go down into User Space Territory ----------------------- Last pt_regs of kernel stack is: | pt_regs 00000001 094a5408 00000003 ..~......TJ..... | bx cx dx c2699fc0: 00000003 094a5408 bfd1b704 00000004 .....TJ......... | si di bp ax c2699fd0: 0000007b ffff007b c07e0000 00000033 {...{.....~.3... | ds es fs gs c2699fe0: 00000004 b776a416 00000073 00000246 ......v.s...F... | orig_eax ip cs flags c2699ff0: bfd1b6d8 0000007b | sp ss v cccccccc cccccccc ....{........... | padding | |----------------------------------------------------------------| | (gdb) x/32xw 0xbfd1b680 | 0xbfd1b680: 0xbfd1b6d0 0x0000000f 0x094b4568 0x080c90b9 | 0xbfd1b690: 0x094b4568 0x080cd160 0x00001936 0x00000001 | 0xbfd1b6a0: 0x094ab9c8 0x00000000 0x094b4b48 0xbfd1b7c8 | 0xbfd1b6b0: 0x080ce9e8 0x094b4b48 0x094b4b48 0xbfd1b728 | 0xbfd1b6c0: 0x094aed28 0x00000020 0x00000000 0x00000070 | 0xbfd1b6d0: 0x094b4588 0x080cc080 | 0xb7698b43 <--| 0xb7757ff4 0xbfd1b6e0: 0xb76343b4 0x00000001 0x094a5408 0x00000003 0xbfd1b6f0: 0xb77584e0 0x080cc080 0xbfd1b728 0xb77584e0 |------------------------------------------ Hypothesis : this is an EBP value... v 0xbfd1b700: 0x00000003 {0xbfd1b72c} [0xb7635c90] 0xb77584e0 0xbfd1b710: 0x094a5408 0x00000003 0x094b4b48 0xbfd1b7c8 0xbfd1b720: 0xb7757ff4 0xb77584e0 0x0000000a {0xbfd1b750} 0xbfd1b730: [0xb7634e80] 0xb77584e0 0x094a5408 0x00000003 0xbfd1b740: 0x0000000a 0xb7757ff4 0xb77584e0 0x0000000a 0xbfd1b750: {0xbfd1b768} [0xb7637d2a] 0xb77584e0 0x0000000a 0xbfd1b760: 0xb7757ff4 0xb77584e0 {0xbfd1b788} [0xb76312b5]>-| 0xbfd1b770: 0xb77584e0 0x0000000a 0xb75c9940 0x094a3e48 | 0xbfd1b780: 0x00000001 0x00000000 0x00000000 0x0809b64b | | Disassemble Try: EIP@0xb76312b5 <---------------------------------------------| (gdb) disassemble 0xb7631200, 0xb7631300 Dump of assembler code from 0xb7631200 to 0xb7631300: 0xb7631200: Cannot access memory at address 0xb7631200 (gdb) ---------- Le 17/12/2013 19:12, Buland Kumar Singh a écrit :