10:45 p.m.
Hi all,
Recently I found an slub related problem(kmalloc-1024 objects eat tons of memory):
# ./slabinfo -l | grep "t-0001024"
:t-0001024 46448117 1024 47.5G 4074/505/11608097 4 0 0 99 *
Then I make the memroy coredump trying to find out why, it seems something wrong with
the slub's cpu_slab(kmem_cache_cpu) list. But as I want to walk through the page list
like following, crash seems can't identify:
crash> struct page.next,pages,pobjects 0xffffea0049e85140
next = 0xffffea0014533c40
pages = 13511054
pobjects = -545576266
crash> list page.next 0xffffea0049e85140
list: invalid argument: page.next
While my usage case is similar to the case in the 'help list' man page:
crash> p file_systems
file_systems = $1 = (struct file_system_type *) 0xc03adc90
crash> list file_system_type.next -s file_system_type.name,fs_flags c03adc90
So what is wrong, is there a way that I can walk through the page list?
thanks in advance~
linfeng
7:23 a.m.
New subject: crash help: using list for traversing pages through page.next
----- Original Message -----
Hi all,
Recently I found an slub related problem(kmalloc-1024 objects eat tons of
memory):
# ./slabinfo -l | grep "t-0001024"
:t-0001024 46448117 1024 47.5G 4074/505/11608097 4 0 0
99 *
Then I make the memroy coredump trying to find out why, it seems something wrong with
the slub's cpu_slab(kmem_cache_cpu) list. But as I want to walk through the page
list
like following, crash seems can't identify:
crash> struct page.next,pages,pobjects 0xffffea0049e85140
next = 0xffffea0014533c40
pages = 13511054
pobjects = -545576266
crash> list page.next 0xffffea0049e85140
list: invalid argument: page.next
While my usage case is similar to the case in the 'help list' man page:
crash> p file_systems
file_systems = $1 = (struct file_system_type *) 0xc03adc90
crash> list file_system_type.next -s file_system_type.name,fs_flags
c03adc90
So what is wrong, is there a way that I can walk through the page list?
I'm not sure -- I can't reproduce the problem:
crash> kmem -p | grep mapped
fffffc97c41cc840 107321000 ffff9d5d65a12c88 52 1 17ffffc0020036
referenced,uptodate,lru,active,mappedtodisk
fffffc97c41ce4c0 107393000 ffff9d5d65a12c88 0 1 17ffffc0020036
referenced,uptodate,lru,active,mappedtodisk
^C
crash> list page.next fffffc97c41cc840
fffffc97c41cc840
fffffc97d090fac8
fffffc97c41cc848
fffffc97d092a988
fffffc97d08f6bc8
fffffc97d090e608
fffffc97d0923308
fffffc97d09fd548
fffffc97d090cd48
fffffc97d09bc448
fffffc97d0994208
fffffc97d0994348
...
For some reason, the "page.next" argument is not being resolved by
arg_to_datatype(),
here in tools.c, line 3454:
3452 while (args[optind]) {
3453 if (strstr(args[optind], ".") &&
3454 arg_to_datatype(args[optind], sm, RETURN_ON_ERROR) > 1) {
3455 if (ld->flags & LIST_OFFSET_ENTERED)
3456 error(FATAL,
3457 "offset value %ld (0x%lx) already
entered\n",
3458 ld->member_offset,
ld->member_offset);
3459 ld->member_offset = sm->member_offset;
3460 ld->flags |= LIST_OFFSET_ENTERED;
3461 } else {
What happens if you just enter this:
crash> page.next
struct page {
[8] struct page *next;
}
crash>
Or for that matter, what does "page -o" show?
You can always use the "-o offset" argument as a replacement for
"page.next":
crash> list -o 8 fffffc97c41cc840
fffffc97c41cc840
fffffc97d090fac8
fffffc97c41cc848
fffffc97d092a988
fffffc97d08f6bc8
fffffc97d090e608
fffffc97d0923308
fffffc97d09fd548
fffffc97d090cd48
fffffc97d09bc448
fffffc97d0994208
...
Dave
thanks in advance~
linfeng
--
Crash-utility mailing list
Crash-utility(a)redhat.com
https://www.redhat.com/mailman/listinfo/crash-utility
1620
days inactive
1620
days old
devel@lists.crash-utility.osci.io
1 comments
2 participants
participants (2)
-
Dave Anderson -
Lin Feng