Bug 507971 - kmemleak: Freeing unknown object at 0xffffc90018070000
kmemleak: Freeing unknown object at 0xffffc90018070000
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-24 18:14 EDT by Tom London
Modified: 2009-08-19 09:55 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-19 09:55:30 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
"dmesg" output showing "kmemleak" messages (121.25 KB, text/plain)
2009-06-24 18:14 EDT, Tom London
no flags Details

  None (edit)
Description Tom London 2009-06-24 18:14:21 EDT
Created attachment 349311 [details]
"dmesg" output showing "kmemleak" messages

Description of problem:

See this in dmesg & /var/log/messages:

Bridge firewalling registered
iwlagn 0000:03:00.0: loaded firmware version 8.24.2.12
kmemleak: Freeing unknown object at 0xffffc90018070000
Pid: 1034, comm: NetworkManager Not tainted 2.6.31-0.25.rc0.git22.fc12.x86_64 #1
Call Trace:
 [<ffffffff81139f74>] delete_object+0x5b/0x13b
 [<ffffffff8113b012>] kmemleak_free+0x5b/0xb5
 [<ffffffff8111dc51>] vfree+0x40/0x68
 [<ffffffff813485e6>] release_firmware+0x49/0x6c
 [<ffffffffa021997c>] ? iwl_mac_start+0xc5c/0x106b [iwlagn]
 [<ffffffffa0219adc>] iwl_mac_start+0xdbc/0x106b [iwlagn]
 [<ffffffff8109df9b>] ? __module_text_address+0x25/0x85
 [<ffffffffa016712c>] ieee80211_open+0x275/0x6b2 [mac80211]
 [<ffffffff8143749b>] dev_open+0xb0/0x101
 [<ffffffff8143697d>] dev_change_flags+0xbc/0x193
 [<ffffffff8144196e>] do_setlink+0x2e2/0x3c7
 [<ffffffff81441b66>] rtnl_setlink+0x113/0x126
 [<ffffffff8144124f>] rtnetlink_rcv_msg+0x1d5/0x206
 [<ffffffff8144107a>] ? rtnetlink_rcv_msg+0x0/0x206
 [<ffffffff81456d61>] netlink_rcv_skb+0x52/0xb9
 [<ffffffff8144105f>] rtnetlink_rcv+0x35/0x50
 [<ffffffff8145681a>] netlink_unicast+0x12b/0x1a8
 [<ffffffff81456b25>] netlink_sendmsg+0x28e/0x2b1
 [<ffffffff81421b71>] __sock_sendmsg+0x70/0x8f
 [<ffffffff8142253d>] sock_sendmsg+0xdb/0x108
 [<ffffffff814223bf>] ? sock_recvmsg+0xde/0x10b
 [<ffffffff8107f56f>] ? autoremove_wake_function+0x0/0x5f
 [<ffffffff8110f2a8>] ? might_fault+0x71/0xd9
 [<ffffffff8142d776>] ? verify_iovec+0x60/0xb6
 [<ffffffff8142278b>] sys_sendmsg+0x221/0x2a5
 [<ffffffff81058bf0>] ? finish_task_switch+0xa7/0x136
 [<ffffffff81058b98>] ? finish_task_switch+0x4f/0x136
 [<ffffffff814ef1a7>] ? thread_return+0x4e/0xd3
 [<ffffffff81147db2>] ? path_put+0x31/0x4c
 [<ffffffff810c133e>] ? audit_syscall_entry+0x12d/0x16d
 [<ffffffff814f1346>] ? trace_hardirqs_on_thunk+0x3a/0x3f
 [<ffffffff814ef1a7>] ? thread_return+0x4e/0xd3
 [<ffffffff81012f42>] system_call_fastpath+0x16/0x1b
Registered led device: iwl-phy0::radio
Registered led device: iwl-phy0::assoc

Along with listing of many "unreferenced objects" (first 2 of 100 listed):
kmemleak: unreferenced object 0xffff88013bc73000 (size 64):
kmemleak:   comm "swapper", pid 0, jiffies 4294667296
kmemleak:   backtrace:
kmemleak:     [<ffffffff8113b95c>] kmemleak_alloc+0x1f8/0x35c
kmemleak:     [<ffffffff8112ff4f>] kmem_cache_alloc_node_notrace+0x13b/0x174
kmemleak:     [<ffffffff814ed0e6>] process_zones+0x81/0x1ef
kmemleak:     [<ffffffff8182a2b6>] setup_per_cpu_pageset+0x24/0x4e
kmemleak:     [<ffffffff81806000>] start_kernel+0x38e/0x451
kmemleak:     [<ffffffff818052d0>] x86_64_start_reservations+0xbb/0xd6
kmemleak:     [<ffffffff818053f0>] x86_64_start_kernel+0x105/0x128
kmemleak:     [<ffffffffffffffff>] 0xffffffffffffffff
kmemleak: unreferenced object 0xffff88013bc73088 (size 64):
kmemleak:   comm "swapper", pid 0, jiffies 4294667296
kmemleak:   backtrace:
kmemleak:     [<ffffffff8113b95c>] kmemleak_alloc+0x1f8/0x35c
kmemleak:     [<ffffffff8112ff4f>] kmem_cache_alloc_node_notrace+0x13b/0x174
kmemleak:     [<ffffffff814ed0e6>] process_zones+0x81/0x1ef
kmemleak:     [<ffffffff8182a2b6>] setup_per_cpu_pageset+0x24/0x4e
kmemleak:     [<ffffffff81806000>] start_kernel+0x38e/0x451
kmemleak:     [<ffffffff818052d0>] x86_64_start_reservations+0xbb/0xd6
kmemleak:     [<ffffffff818053f0>] x86_64_start_kernel+0x105/0x128
kmemleak:     [<ffffffffffffffff>] 0xffffffffffffffff

Complete dmesg attached.

Version-Release number of selected component (if applicable):
kernel-2.6.31-0.25.rc0.git22.fc12.x86_64

How reproducible:
Don't know

Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Fabian Deutsch 2009-07-06 03:46:03 EDT
I do not know whether this is the same problem, but kmemleak eats 100% every now and then. I do not know why this happens, what happens and how I can reproduce this.
Comment 2 Fabian Deutsch 2009-07-06 06:06:44 EDT
Okay. It seems as if this is a natural behavior. It's at least irritating.
Comment 3 Tom London 2009-08-19 09:55:30 EDT
Haven't seen any kmemleak messages in quite a while.

Closing this..... (reopen as needed).

Note You need to log in before you can comment on or make changes to this bug.