Hi, all:
I just want to use kmemleak, so I make the CONFIG_DEBUG_KMEMLEAK and
CONFIG_DEBUG_FS on, mount the debugfs.
But when I insmod mm/kmemleak-test.ko, echo scan >
/sys/kernel/debug/kmemleak and cat /sys/kernel/debug/kmemleak. I just
see this:
unreferenced object 0xffffc90012d21000 (size 64):
?comm "insmod", pid 13092, jiffies 4298369684
?hex dump (first 32 bytes):
? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
?backtrace:
? ?[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffffc90012d24000 (size 64):
?comm "insmod", pid 13092, jiffies 4298369684
?hex dump (first 32 bytes):
? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
?backtrace:
? ?[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffffc90012d27000 (size 64):
?comm "insmod", pid 13092, jiffies 4298369684
?hex dump (first 32 bytes):
? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
?backtrace:
? ?[<ffffffffffffffff>] 0xffffffffffffffff
There is no other backtrace except [<ffffffffffffffff>]
0xffffffffffffffff. Then I read the mm/kmemleak.c. In
kmemleak_seq_show(), I find that the object->trace_len is 1.
How can I get the full backtrace?
help~~~：） please ！thx！！
On Thu, May 12, 2011 at 10:06 AM, ttlxzz ccc <[email protected]> wrote:
> Hi, all:
>
>
>
> I just want to use kmemleak, so I make the CONFIG_DEBUG_KMEMLEAK and
> CONFIG_DEBUG_FS on, mount the debugfs.
>
> But when I insmod mm/kmemleak-test.ko, echo scan >
> /sys/kernel/debug/kmemleak and cat /sys/kernel/debug/kmemleak. I just
> see this:
>
> unreferenced object 0xffffc90012d21000 (size 64):
>
> comm "insmod", pid 13092, jiffies 4298369684
>
> hex dump (first 32 bytes):
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> backtrace:
>
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d24000 (size 64):
>
> comm "insmod", pid 13092, jiffies 4298369684
>
> hex dump (first 32 bytes):
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> backtrace:
>
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d27000 (size 64):
>
> comm "insmod", pid 13092, jiffies 4298369684
>
> hex dump (first 32 bytes):
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> backtrace:
>
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> There is no other backtrace except [<ffffffffffffffff>]
> 0xffffffffffffffff. Then I read the mm/kmemleak.c. In
> kmemleak_seq_show(), I find that the object->trace_len is 1.
>
>
>
> How can I get the full backtrace?
>
Hi,
Could you please share some more information about your setup ?
Regards,
Maxin
On Thu, May 12, 2011 at 4:13 AM, ttlxzz ccc <[email protected]> wrote:
> help~~~：） please ！thx！！
>
> On Thu, May 12, 2011 at 10:06 AM, ttlxzz ccc <[email protected]> wrote:
>> Hi, all:
>>
>>
>>
>> I just want to use kmemleak, so I make the CONFIG_DEBUG_KMEMLEAK and
>> CONFIG_DEBUG_FS on, mount the debugfs.
>>
>> But when I insmod mm/kmemleak-test.ko, echo scan >
>> /sys/kernel/debug/kmemleak and cat /sys/kernel/debug/kmemleak. I just
>> see this:
>>
>> unreferenced object 0xffffc90012d21000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> unreferenced object 0xffffc90012d24000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> unreferenced object 0xffffc90012d27000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> There is no other backtrace except [<ffffffffffffffff>]
>> 0xffffffffffffffff. Then I read the mm/kmemleak.c. In
>> kmemleak_seq_show(), I find that the object->trace_len is 1.
>>
>>
>>
>> How can I get the full backtrace?
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
Thx, Maxin :)
ok
I did steps below:
1 make oldconfig
2 vim .config
...
CONFIG_DEBUG_FS = y
CONFIG_DEBUG_KMEMLEAK = y
CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE = 1200
...
3 make ; make modules ; and replace the kernel; reboot
4 mount -t debugfs debugfs /sys/kernel/debug
4 I wrote a module like this
#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/vmalloc.h>
void myfunc(void)
{
char *ptr;
ptr = vmalloc(512);
ptr = vmalloc(512);
ptr = vmalloc(512);
}
int hello_init(void)
{
printk(KERN_ALERT "Hello World");
myfunc();
return 0;
}
static void hello_exit(void)
{
printk(KERN_ALERT "Goodbye World");
}
module_init(hello_init);
module_exit(hello_exit);
MODULE_LICENSE("GPL v2");
5 clear the kmemleak
Echo clear > /sys/kernel/debug/kmemleak
6 insmod the module
Insmod xxx.ko
7 echo scan > /sys/kenel/debug/kmemleak
8 watch it
Cat / sys/kenel/debug/kmemleak
>> unreferenced object 0xffffc90012d27000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
And I can only get the backtrace [<ffffffffffffffff>]
BTW the kernel's version is 2.6.32.
Thx to Maxin again~~~:)
-----邮件原件-----
发件人: [email protected] [mailto:[email protected]] 代表 Maxin B John
发送时间: 2011年5月12日 17:44
收件人: ttlxzz ccc
抄送: [email protected]
主题: Re: problem with kmemleak
Hi,
Could you please share some more information about your setup ?
Regards,
Maxin
On Thu, May 12, 2011 at 4:13 AM, ttlxzz ccc <[email protected]> wrote:
> help~~~：） please ！thx！！
>
> On Thu, May 12, 2011 at 10:06 AM, ttlxzz ccc <[email protected]> wrote:
>> Hi, all:
>>
>>
>>
>> I just want to use kmemleak, so I make the CONFIG_DEBUG_KMEMLEAK and
>> CONFIG_DEBUG_FS on, mount the debugfs.
>>
>> But when I insmod mm/kmemleak-test.ko, echo scan >
>> /sys/kernel/debug/kmemleak and cat /sys/kernel/debug/kmemleak. I just
>> see this:
>>
>> unreferenced object 0xffffc90012d21000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> unreferenced object 0xffffc90012d24000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> unreferenced object 0xffffc90012d27000 (size 64):
>>
>> comm "insmod", pid 13092, jiffies 4298369684
>>
>> hex dump (first 32 bytes):
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>
>> backtrace:
>>
>> [<ffffffffffffffff>] 0xffffffffffffffff
>>
>> There is no other backtrace except [<ffffffffffffffff>]
>> 0xffffffffffffffff. Then I read the mm/kmemleak.c. In
>> kmemleak_seq_show(), I find that the object->trace_len is 1.
>>
>>
>>
>> How can I get the full backtrace?
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
I am chenxi, too :)
On Thu, May 12, 2011 at 5:44 PM, Maxin B John <[email protected]> wrote:
> Hi,
>
> Could you please share some more information about your setup ?
>
> Regards,
> Maxin
>
> On Thu, May 12, 2011 at 4:13 AM, ttlxzz ccc <[email protected]> wrote:
>> help~~~：） please ！thx！！
>>
>> On Thu, May 12, 2011 at 10:06 AM, ttlxzz ccc <[email protected]> wrote:
>>> Hi, all:
>>>
>>>
>>>
>>> I just want to use kmemleak, so I make the CONFIG_DEBUG_KMEMLEAK and
>>> CONFIG_DEBUG_FS on, mount the debugfs.
>>>
>>> But when I insmod mm/kmemleak-test.ko, echo scan >
>>> /sys/kernel/debug/kmemleak and cat /sys/kernel/debug/kmemleak. I just
>>> see this:
>>>
>>> unreferenced object 0xffffc90012d21000 (size 64):
>>>
>>> comm "insmod", pid 13092, jiffies 4298369684
>>>
>>> hex dump (first 32 bytes):
>>>
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>
>>> backtrace:
>>>
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>
>>> unreferenced object 0xffffc90012d24000 (size 64):
>>>
>>> comm "insmod", pid 13092, jiffies 4298369684
>>>
>>> hex dump (first 32 bytes):
>>>
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>
>>> backtrace:
>>>
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>
>>> unreferenced object 0xffffc90012d27000 (size 64):
>>>
>>> comm "insmod", pid 13092, jiffies 4298369684
>>>
>>> hex dump (first 32 bytes):
>>>
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>
>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>>>
>>> backtrace:
>>>
>>> [<ffffffffffffffff>] 0xffffffffffffffff
>>>
>>> There is no other backtrace except [<ffffffffffffffff>]
>>> 0xffffffffffffffff. Then I read the mm/kmemleak.c. In
>>> kmemleak_seq_show(), I find that the object->trace_len is 1.
>>>
>>>
>>>
>>> How can I get the full backtrace?
>>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to [email protected]
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at http://www.tux.org/lkml/
>>
>
On Thu, May 12, 2011 at 12:59 PM, chenxi <[email protected]> wrote:
> Thx, Maxin :)
> ok
> I did steps below:
> 1 make oldconfig
> 2 vim .config
> ?...
> ?CONFIG_DEBUG_FS = y
> ?CONFIG_DEBUG_KMEMLEAK = y
> ?CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE = 1200
> ?...
> 3 make ; make modules ; and replace the kernel; reboot
> 4 mount -t debugfs debugfs /sys/kernel/debug
> 4 I wrote a module like this
> ?#include <linux/init.h>
> ?#include <linux/module.h>
> ?#include <linux/kernel.h>
> ?#include <linux/vmalloc.h>
>
> void myfunc(void)
> {
> ? ? ? ?char *ptr;
> ? ? ? ?ptr = vmalloc(512);
> ? ? ? ?ptr = vmalloc(512);
> ? ? ? ?ptr = vmalloc(512);
> }
>
> int hello_init(void)
> {
> ? ? ? ?printk(KERN_ALERT "Hello World");
> ? ? ? ?myfunc();
> ? ? ? ?return 0;
> }
>
> static void hello_exit(void)
> {
> ? ? ? ?printk(KERN_ALERT "Goodbye World");
> }
>
> module_init(hello_init);
> module_exit(hello_exit);
>
> MODULE_LICENSE("GPL v2");
>
> 5 clear the kmemleak
> ?Echo clear > /sys/kernel/debug/kmemleak
> 6 insmod the module
> ?Insmod xxx.ko
Can you please remove your module?
I think the memory is leaked at unload time.
thanks,
Daniel
Hi, Daniel:
I remove the module and didn't happen any exception. and U can see
that memory leak of insmod has been found int the kmemleak log. So I
think it doesn't happen in the rmmod.
Do you have other ideas, please?
thank you~~:)
On Thu, May 12, 2011 at 7:16 PM, Daniel Baluta <[email protected]> wrote:
> On Thu, May 12, 2011 at 12:59 PM, chenxi <[email protected]> wrote:
>> Thx, Maxin :)
>> ok
>> I did steps below:
>> 1 make oldconfig
>> 2 vim .config
>> ?...
>> ?CONFIG_DEBUG_FS = y
>> ?CONFIG_DEBUG_KMEMLEAK = y
>> ?CONFIG_DEBUG_KMEMLEAK_EARLY_LOG_SIZE = 1200
>> ?...
>> 3 make ; make modules ; and replace the kernel; reboot
>> 4 mount -t debugfs debugfs /sys/kernel/debug
>> 4 I wrote a module like this
>> ?#include <linux/init.h>
>> ?#include <linux/module.h>
>> ?#include <linux/kernel.h>
>> ?#include <linux/vmalloc.h>
>>
>> void myfunc(void)
>> {
>> ? ? ? ?char *ptr;
>> ? ? ? ?ptr = vmalloc(512);
>> ? ? ? ?ptr = vmalloc(512);
>> ? ? ? ?ptr = vmalloc(512);
>> }
>>
>> int hello_init(void)
>> {
>> ? ? ? ?printk(KERN_ALERT "Hello World");
>> ? ? ? ?myfunc();
>> ? ? ? ?return 0;
>> }
>>
>> static void hello_exit(void)
>> {
>> ? ? ? ?printk(KERN_ALERT "Goodbye World");
>> }
>>
>> module_init(hello_init);
>> module_exit(hello_exit);
>>
>> MODULE_LICENSE("GPL v2");
>>
>> 5 clear the kmemleak
>> ?Echo clear > /sys/kernel/debug/kmemleak
>> 6 insmod the module
>> ?Insmod xxx.ko
>
> Can you please remove your module?
> I think the memory is leaked at unload time.
>
> thanks,
> Daniel
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
Did anyone encountered problem like this?
On Thu, May 12, 2011 at 10:06 AM, ttlxzz ccc <[email protected]> wrote:
> Hi, all:
>
>
>
> I just want to use kmemleak, so I make the CONFIG_DEBUG_KMEMLEAK and
> CONFIG_DEBUG_FS on, mount the debugfs.
>
> But when I insmod mm/kmemleak-test.ko, echo scan >
> /sys/kernel/debug/kmemleak and cat /sys/kernel/debug/kmemleak. I just
> see this:
>
> unreferenced object 0xffffc90012d21000 (size 64):
>
> ?comm "insmod", pid 13092, jiffies 4298369684
>
> ?hex dump (first 32 bytes):
>
> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ?backtrace:
>
> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d24000 (size 64):
>
> ?comm "insmod", pid 13092, jiffies 4298369684
>
> ?hex dump (first 32 bytes):
>
> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ?backtrace:
>
> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d27000 (size 64):
>
> ?comm "insmod", pid 13092, jiffies 4298369684
>
> ?hex dump (first 32 bytes):
>
> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ?backtrace:
>
> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
>
> There is no other backtrace except [<ffffffffffffffff>]
> 0xffffffffffffffff. Then I read the mm/kmemleak.c. In
> kmemleak_seq_show(), I find that the object->trace_len is 1.
>
>
>
> How can I get the full backtrace?
>
On Thu, May 12, 2011 at 7:16 PM, Daniel Baluta <[email protected]> wrote:
>
> Can you please remove your module?
> I think the memory is leaked at unload time.
>
No, in kmemleak-test.c we have same examples.
chenxi, I assume you didn't edit the .config manually?
Thanks for Wangcong
I have test the kmemleak-test.ko and the result includes no backtrace
except fffffffff, too.
I'm compling the kernel by make menuconfig. :)
If it still doesn't make sense, please help me again. Thank you.:)
On Thu, May 12, 2011 at 10:18 PM, Am?rico Wang <[email protected]> wrote:
> On Thu, May 12, 2011 at 7:16 PM, Daniel Baluta <[email protected]> wrote:
>>
>> Can you please remove your module?
>> I think the memory is leaked at unload time.
>>
>
> No, in kmemleak-test.c we have same examples.
>
> chenxi, I assume you didn't edit the .config manually?
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at ?http://www.tux.org/lkml/
>
On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <[email protected]> wrote:
> Thanks for Wangcong
>
> I have test the kmemleak-test.ko and the result includes no backtrace
> except fffffffff, too.
> I'm compling the kernel by make menuconfig. :)
Odd, this looks like a bug, Cc Catalin Marinas <[email protected]>
I can't reach my test machine right now, I will try this tomorrow.
On Thu, May 12, 2011 at 5:49 PM, Am?rico Wang <[email protected]> wrote:
> On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <[email protected]> wrote:
>> Thanks for Wangcong
>>
>> I have test the kmemleak-test.ko and the result includes no backtrace
>> except fffffffff, too.
>> I'm compling the kernel by make menuconfig. :)
>
> Odd, this looks like a bug, Cc Catalin Marinas <[email protected]>
>
> I can't reach my test machine right now, I will try this tomorrow.
What architecture are you running on? Can you try it on a newer kernel?
Is there anything interesting in dmesg | grep kmemleak?
thanks,
Daniel.
On Thu, 2011-05-12 at 15:49 +0100, Américo Wang wrote:
> On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <[email protected]> wrote:
> > Thanks for Wangcong
> >
> > I have test the kmemleak-test.ko and the result includes no backtrace
> > except fffffffff, too.
> > I'm compling the kernel by make menuconfig. :)
>
> Odd, this looks like a bug, Cc Catalin Marinas <[email protected]>
Is STACKTRACE_SUPPORT enabled for this platform?
--
Catalin
I can't get my test machine, either:) thank you ~~
On Thu, May 12, 2011 at 10:49 PM, Am?rico Wang <[email protected]> wrote:
> On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <[email protected]> wrote:
>> Thanks for Wangcong
>>
>> I have test the kmemleak-test.ko and the result includes no backtrace
>> except fffffffff, too.
>> I'm compling the kernel by make menuconfig. :)
>
> Odd, this looks like a bug, Cc Catalin Marinas <[email protected]>
>
> I can't reach my test machine right now, I will try this tomorrow.
>
Hi, Wang and Catalin:
I have tested kmemleak on the x86 and x86_64 architecture again. There is only
backtrace:
[<ffffffffffffffff>] 0xffffffffffffffff
unreferenced object 0xffffc90012d27000 (size 64):
comm "insmod", pid 13092, jiffies 4298369684
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffffffffffff>] 0xffffffffffffffff
But in the x86, there is full backtrace.
I do this below
> cat .config | grep STACETRACE
>
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_STACKTRACE=y
> CONFIG_USER_STACKTRACE_SUPPORT=y
>
> As you see, the x86_64 architecture supprot stacktrace. But I found
> there's no backtrace yesterday.
> I'll test it again later.
>
> BTW
>
> cat /proc/cpuinfo | grep processor | wc -l
> 8
> cat /proc/cpuinfo | grep model
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
> model : 26
> model name : Intel(R) Xeon(R) CPU E5520 @ 2.27GHz
and My linux version is redhat 3.4.5
Is it a problem of x86_64 architecture or something else? I am really
very Anxious.
Thanks:)
On Fri, May 13, 2011 at 11:58 AM, ttlxzz ccc <[email protected]> wrote:
> Hi, wang
> I have test kmemleak on the x86 architecture. There is no problem with
> full backtrace.
> But I can't test it on the x86_64 because my test machine is doing
> something else.:(
> But I do this below
> cat .config | grep STACETRACE
>
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_STACKTRACE=y
> CONFIG_USER_STACKTRACE_SUPPORT=y
>
> As you see, the x86_64 architecture supprot stacktrace. But I found
> there's no backtrace yesterday.
> I'll test it again later.
>
> BTW
>
> cat /proc/cpuinfo | grep processor | wc -l
> 8
> cat /proc/cpuinfo | grep model
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
> model ? ? ? ? ? : 26
> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>
> thank you :)
>
>
> On Thu, May 12, 2011 at 10:49 PM, Am?rico Wang <[email protected]> wrote:
>> On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <[email protected]> wrote:
>>> Thanks for Wangcong
>>>
>>> I have test the kmemleak-test.ko and the result includes no backtrace
>>> except fffffffff, too.
>>> I'm compling the kernel by make menuconfig. :)
>>
>> Odd, this looks like a bug, Cc Catalin Marinas <[email protected]>
>>
>> I can't reach my test machine right now, I will try this tomorrow.
>>
>
On Fri, 2011-05-13 at 10:32 +0100, ttlxzz ccc wrote:
> I have tested kmemleak on the x86 and x86_64 architecture again. There
> is only
> backtrace:
>
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d27000 (size 64):
>
> comm "insmod", pid 13092, jiffies 4298369684
>
> hex dump (first 32 bytes):
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
>
> backtrace:
>
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> But in the x86, there is full backtrace.
Can you enable CONFIG_BACKTRACE_SELF_TEST and check whether the
boot-time backtrace test goes ok?
--
Catalin
Hi, Catalin=:)
I enable CONFIG_BACKTRACE_SELF_TEST and check the log
vim /var/log/kernel
and find the backtrace testing below:
May 15 13:48:54 db-sat-test05 kernel: ====[ backtrace testing ]===========
May 15 13:48:54 db-sat-test05 kernel: Testing a backtrace from process context.
May 15 13:48:54 db-sat-test05 kernel: The following trace is a kernel
self test and not a bug!
May 15 13:48:54 db-sat-test05 kernel: Pid: 1, comm: swapper Not
tainted 2.6.32_1-1-0-0 #7
May 15 13:48:54 db-sat-test05 kernel: Call Trace:
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8108b5f9>] ?
backtrace_regression_test+0x50/0x16a
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8117b143>] ?
proc_create_data+0xb3/0xe5
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8182d6e1>] ?
kallsyms_init+0x0/0x30
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8182d706>] ?
kallsyms_init+0x25/0x30
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff81009094>] ?
do_one_initcall+0x6c/0x1c0
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8181133a>] ?
kernel_init+0x2f5/0x381
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8100ca9a>] ? child_rip+0xa/0x20
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff81811045>] ?
kernel_init+0x0/0x381
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8100ca90>] ? child_rip+0x0/0x20
May 15 13:48:54 db-sat-test05 kernel: Testing a backtrace from irq context.
May 15 13:48:54 db-sat-test05 kernel: The following trace is a kernel
self test and not a bug!
May 15 13:48:54 db-sat-test05 kernel: Pid: 22, comm: ksoftirqd/6 Not
tainted 2.6.32_1-1-0-0 #7
May 15 13:48:54 db-sat-test05 kernel: Call Trace:
May 15 13:48:54 db-sat-test05 kernel: <IRQ> [<ffffffff8108b595>] ?
backtrace_test_irq_callback+0xd/0x21
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8105744e>] ?
tasklet_action+0x95/0xf8
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff81057034>] ?
__do_softirq+0xa9/0x154
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff81057892>] ?
ksoftirqd+0x0/0x16c
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8100cb9c>] ?
call_softirq+0x1c/0x28
May 15 13:48:54 db-sat-test05 kernel: <EOI> [<ffffffff8100e8c1>] ?
do_softirq+0x47/0xbc
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff81057917>] ?
ksoftirqd+0x85/0x16c
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8106b6e8>] ? kthread+0x9b/0xaa
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8100ca9a>] ? child_rip+0xa/0x20
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8106b64d>] ? kthread+0x0/0xaa
May 15 13:48:54 db-sat-test05 kernel: [<ffffffff8100ca90>] ? child_rip+0x0/0x20
May 15 13:48:54 db-sat-test05 kernel: Testing a saved backtrace.
May 15 13:48:54 db-sat-test05 kernel: The following trace is a kernel
self test and not a bug!
May 15 13:48:54 db-sat-test05 kernel: [<ffffffffffffffff>] 0xffffffffffffffff
May 15 13:48:54 db-sat-test05 kernel: ====[ end of backtrace testing ]====
Is there something wrong with the backtrace testing so that I can't
get the full backtrace, plz?
thank you very much:)
On Fri, May 13, 2011 at 10:08 PM, Catalin Marinas
<[email protected]> wrote:
> On Fri, 2011-05-13 at 10:32 +0100, ttlxzz ccc wrote:
>> I have tested kmemleak on the x86 and x86_64 architecture again. There
>> is only
>> ?backtrace:
>>
>> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
>>
>> unreferenced object 0xffffc90012d27000 (size 64):
>>
>> ?comm "insmod", pid 13092, jiffies 4298369684
>>
>> ?hex dump (first 32 bytes):
>>
>> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>>
>> ? ?00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>>
>> ?backtrace:
>>
>> ? ?[<ffffffffffffffff>] 0xffffffffffffffff
>>
>> But in the x86, there is full backtrace.
>
> Can you enable CONFIG_BACKTRACE_SELF_TEST and check whether the
> boot-time backtrace test goes ok?
>
> --
> Catalin
>
>
>
Hi Catalin and Wang :)
I'm very glad to find the reason of this problem. It's just because
the CONFIG_FRAME_POINTER is not set :).
And in dump_stack() which is defined in arch/x86/kernel/dumpstack.c,
CONFIG_FRAME_POINTER control whether to get the bp.
Now I enable CONFIG_FRAME_POINTER and I can see the full backtrace. :)
Thank you very much for Catalin and Wang:).
On Fri, May 13, 2011 at 5:32 PM, ttlxzz ccc <[email protected]> wrote:
> Hi, Wang and Catalin:
>
> I have tested kmemleak on the x86 and x86_64 architecture again. There is only
> ?backtrace:
>
> ? [<ffffffffffffffff>] 0xffffffffffffffff
>
> unreferenced object 0xffffc90012d27000 (size 64):
>
> ?comm "insmod", pid 13092, jiffies 4298369684
>
> ?hex dump (first 32 bytes):
>
> ? 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ? 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ?................
>
> ?backtrace:
>
> ? [<ffffffffffffffff>] 0xffffffffffffffff
>
> But in the x86, there is full backtrace.
> ?I do this below
>> cat .config | grep STACETRACE
>>
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_STACKTRACE=y
>> CONFIG_USER_STACKTRACE_SUPPORT=y
>>
>> As you see, the x86_64 architecture supprot stacktrace. But I found
>> there's no backtrace yesterday.
>> I'll test it again later.
>>
>> BTW
>>
>> cat /proc/cpuinfo | grep processor | wc -l
>> 8
>> cat /proc/cpuinfo | grep model
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>
> and My linux version is redhat 3.4.5
>
> Is it a problem of x86_64 architecture or something else? I am really
> very Anxious.
>
> Thanks:)
>
> On Fri, May 13, 2011 at 11:58 AM, ttlxzz ccc <[email protected]> wrote:
>> Hi, wang
>> I have test kmemleak on the x86 architecture. There is no problem with
>> full backtrace.
>> But I can't test it on the x86_64 because my test machine is doing
>> something else.:(
>> But I do this below
>> cat .config | grep STACETRACE
>>
>> CONFIG_STACKTRACE_SUPPORT=y
>> CONFIG_STACKTRACE=y
>> CONFIG_USER_STACKTRACE_SUPPORT=y
>>
>> As you see, the x86_64 architecture supprot stacktrace. But I found
>> there's no backtrace yesterday.
>> I'll test it again later.
>>
>> BTW
>>
>> cat /proc/cpuinfo | grep processor | wc -l
>> 8
>> cat /proc/cpuinfo | grep model
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>> model ? ? ? ? ? : 26
>> model name ? ? ?: Intel(R) Xeon(R) CPU ? ? ? ? ? E5520 ?@ 2.27GHz
>>
>> thank you :)
>>
>>
>> On Thu, May 12, 2011 at 10:49 PM, Am?rico Wang <[email protected]> wrote:
>>> On Thu, May 12, 2011 at 10:33 PM, ttlxzz ccc <[email protected]> wrote:
>>>> Thanks for Wangcong
>>>>
>>>> I have test the kmemleak-test.ko and the result includes no backtrace
>>>> except fffffffff, too.
>>>> I'm compling the kernel by make menuconfig. :)
>>>
>>> Odd, this looks like a bug, Cc Catalin Marinas <[email protected]>
>>>
>>> I can't reach my test machine right now, I will try this tomorrow.
>>>
>>
>
On Mon, 2011-05-16 at 08:18 +0100, ttlxzz ccc wrote:
> I'm very glad to find the reason of this problem. It's just because
> the CONFIG_FRAME_POINTER is not set :).
>
> And in dump_stack() which is defined in arch/x86/kernel/dumpstack.c,
> CONFIG_FRAME_POINTER control whether to get the bp.
>
> Now I enable CONFIG_FRAME_POINTER and I can see the full backtrace. :)
It's good you found it. I thought STACKTRACE on x86_64 would set the
necessary options like FRAME_POINTER so that it works properly. Kmemleak
only sets STACKTRACE.
--
Catalin
On Mon, May 16, 2011 at 4:53 PM, Catalin Marinas
<[email protected]> wrote:
> On Mon, 2011-05-16 at 08:18 +0100, ttlxzz ccc wrote:
>> I'm very glad to find the reason of this problem. It's just because
>> the CONFIG_FRAME_POINTER is not set :).
>>
>> And in dump_stack() which is defined in arch/x86/kernel/dumpstack.c,
>> CONFIG_FRAME_POINTER control whether to get the bp.
>>
>> Now I enable CONFIG_FRAME_POINTER and I can see the full backtrace. :)
>
> It's good you found it. I thought STACKTRACE on x86_64 would set the
> necessary options like FRAME_POINTER so that it works properly. Kmemleak
> only sets STACKTRACE.
>
I am wondering why STACKTRACE doesn't select FRAME_POINTER on x86_64,
which seems necessary...