----- Original Message -----
>
>
> ----- Original Message -----
> > On 01/11/2012 06:53 AM, Petr Tesarik wrote:
> > > Dne Út 10. ledna 2012 19:23:24 Petr Tesarik napsal(a):
> > >> Dne Út 10. ledna 2012 19:14:32 Petr Tesarik napsal(a):
> > ... [ cut ] ...
> > >> crash> vtop f2800080
> > >> VIRTUAL PHYSICAL
> > >> f2800080 1fde00080
> > >>
> > >> PAGE DIRECTORY: c08ed000
> > >> PGD: c08ed018 => 8ea001
> > >> PMD: 8eaca0 => 80000001fde001e3
> > >> PAGE: 1fde00000 (2MB)
> > >>
> > >> PTE PHYSICAL FLAGS
> > >> 80000001fde001e3 1fde00000
> > >> (PRESENT|RW|ACCESSED|DIRTY|PSE|GLOBAL|NX)
> > >>
> > >> PAGE PHYSICAL MAPPING INDEX CNT FLAGS
> > >
> > > BTW the data from struct page is really missing here. I traced
> > > this down to an
> > > integer overflow in dump_memory_nodes():
> > ... [ cut ] ...
> > > David (Mair), could you address this, as already discussed in
> > > private mails,
> > > please?
> >
> > The attached patch fixes this for me.
>
> Hmmm, not so much for me...
>
> When I test the patch on RHEL5, RHEL6 and Fedora x86 kernels, the
> command always fails like this:
>
> crash> kmem -n
> NODE SIZE PGLIST_DATA BOOTMEM_DATA NODE_ZONES
> 0 262075 c0a3a680 c0aa5ce8 c0a3a680
> c0a3b1c0
> c0a3bd00
> c0a3c840
> MEM_MAP START_PADDR START_MAPNR
> Segmentation fault
> $
>
> I haven't look into it, and this is probably not related:
>
> cc -c -g -DX86 -m32 -D_FILE_OFFSET_BITS=64 -DGDB_7_3_1 memory.c
> -Wall -O2 -Wstrict-prototypes -Wmissing-prototypes -fstack-protector
> memory.c: In function 'dump_memory_nodes':
> memory.c:13410: warning: cast to pointer from integer of different
> size
> memory.c:13199: warning: 'node_start_paddr' may be used uninitialized
> in this function
>
> But from under gdb:
>
> crash> kmem -n
> [Detaching after fork from child process 16870.]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0809cd94 in mkstring (s=0xffe8a8bc " c0a3a680 ", size=16,
> flags=133, opt=0x1000 <Address 0x1000 out of bounds>)
> at tools.c:1620
> 1620 sprintf(s, "%llx", *((ulonglong *)opt));
> (gdb) bt
> #0 0x0809cd94 in mkstring (s=0xffe8a8bc " c0a3a680 ", size=16,
> flags=133, opt=0x1000 <Address 0x1000 out of bounds>)
> at tools.c:1620
> #1 0x080b1ad7 in dump_memory_nodes (initialize=0) at memory.c:13406
> #2 0x080d46cc in cmd_kmem () at memory.c:4221
> #3 0x080941b8 in exec_command () at main.c:751
> #4 0x08093fe6 in main_loop () at main.c:699
> #5 0x081db622 in current_interp_command_loop ()
> #6 0x081dbf01 in captured_command_loop ()
> #7 0x081db0a4 in catch_errors ()
> #8 0x081dce07 in captured_main ()
> #9 0x081db0a4 in catch_errors ()
> #10 0x081dce49 in gdb_main ()
> #11 0x081dce99 in gdb_main_entry ()
> #12 0x08116668 in gdb_main_loop (argc=2, argv=0xffe8d494) at
> gdb_interface.c:75
> #13 0x08093ce0 in main (argc=3, argv=0xffe8d494) at main.c:603
> (gdb) p opt
> $1 = 0x1000 <Address 0x1000 out of bounds>
> (gdb)
>
> I thought it might be just an x86 issue, but it also fails
> the same way on RHEL5, RHEL6 and Fedora x86_64 kernels.
>
> Dave
It's because of this:
- mkstring(buf2, strlen("START_PADDR"),
- CENTER|LONG_HEX|RJUST, MKSTR(node_start_paddr)),
+ mkstring(buf2, strlen(" START_PADDR "),
+ CENTER|LONGLONG_HEX|RJUST, MKSTR(node_start_paddr)),
When using MKSTR() with a longlong, it needs to be passed its address, i.e.:
+ mkstring(buf2, strlen(" START_PADDR "),
+ CENTER|LONGLONG_HEX|RJUST, MKSTR(&node_start_paddr)),
That fixes the SIGSEGV, but the formatting is still a bit unpredictable
because the 2nd and 3rd fields don't always line up correctly.
Dave
--
Crash-utility mailing list
Crash-utility@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/crash-utility
