Separate names with a comma.
Discussion in 'macOS' started by Canerican, Jan 8, 2008.
So, the screencap says it all.
hi 2 google.
blued -- The Mac OS X bluetooth daemon.
The Bluetooth daemon handles SDP transactions, link key management, and
incoming connection acceptance. It cannot be used directly by the user.
something using your bt?
Nope, its even turned off.
Any ideas? Having the same thing 10.5.3, 2.33Ghz, MBP, 3G ram.
try restarting your mac
try turning bluetooth on/off tell us if that fluctuates the blueed process %.
any devices near your computer that are also bluetooth?
I've tried everything (repair file permissions, pram reset, pru reset and archive and install + upgrade back to 10.5.3...I think the bluetooth hardware may be damaged.
Removing the Apple Bluetooth .plist files from User and System preferences folder seemed to fix it.
I have the same problem about once a day after 10.5.7 and firmware update of the bluetooth chip. Only restart helps.
Can you specificy precisely which files you removed to fix this? I am afraid to remove to many, there is like 4-5 files with bluetooth in just the /User/Library folder.
Also deleting to little will not fix it I guess.
Can't remember exactly, I think I removed all of them. Just back them up first in case you delete an 'important' .plist file.
A list of the files I removed (actually renamed) are listed HERE.
Hope that helps!
sucks up all the VM as well....
bluetooth is disabled on this machine.
Recently, I have noticed that it is running, because it bloats up to over 3.5 GB of virtual memory, and thrashes so much that everything else pages out.
I killed it the other day, but it came back today, so I just attached gdb to it, which has caused it to pause, and everything else paged back.
My console log is full of:
Feb 25 13:09:14 8way blued: (/SourceCache/IOBluetoothApps/IOBluetoothFamily-2240.4.3/Apps_System/DeviceManager/daemon/InquiryManager.m:1716 -[InquiryManager notifyClientsOfInqu
iryComplete:infiniteSearchClientsOnly:]) EXCEPTION: connection is invalid
Feb 25 13:09:38: --- last message repeated 895 times ---
The stack trace is huge. The top 10 frames are:
gdb /usr/sbin/blued (wd: /usr/local/gw6c/bin)
#0 0x00007fff82119636 in _asl_append_string ()
#1 0x00007fff82134afb in asl_msg_to_string ()
#2 0x00007fff821345b0 in asl_send ()
#3 0x00007fff8267b838 in __CFLogCString ()
#4 0x00007fff8267b72b in _CFLogvEx ()
#5 0x00007fff85ab136b in NSLogv ()
#6 0x00007fff85ab1303 in NSLog ()
#7 0x000000010002711d in ?? ()
#8 0x0000000100026c3f in ?? ()
#9 0x0000000100027133 in ?? ()
#10 0x0000000100026c3f in ?? ()
#11 0x0000000100027133 in ?? ()
#12 0x0000000100026c3f in ?? ()
#13 0x0000000100027133 in ?? ()
#14 0x0000000100026c3f in ?? ()
#15 0x0000000100027133 in ?? ()
(More stack frames follow...)
... thru to ....
#13028 0x0000000100026c3f in ?? ()
#13029 0x0000000100027133 in ?? ()
#13030 0x0000000100026c3f in ?? ()
#13031 0x0000000100027133 in ?? ()
#13032 0x0000000100026c3f in ?? ()
#13033 0x0000000100027133 in ?? ()
#13034 0x0000000100026c3f in ?? ()
#13035 0x0000000100027133 in ?? ()
#13036 0x0000000100026c3f in ?? ()
#13037 0x0000000100027133 in ?? ()
#13038 0x0000000100026c3f in ?? ()
#13039 0x0000000100027133 in ?? ()
#13040 0x0000000100026c3f in ?? ()
#13041 0x00007fff85a4d85a in _nsnote_callback ()
#13042 0x00007fff82623e3a in __CFXNotificationPost ()
#13043 0x00007fff826103e8 in _CFXNotificationPostNotification ()
#13044 0x00007fff85a447c4 in -[NSNotificationCenter postNotificationNamebject:userInfo:] ()
#13045 0x00007fff85acbad0 in -[NSConnection invalidate] ()
#13046 0x00007fff85aa9974 in +[NSConnection _portInvalidated:] ()
#13047 0x00007fff85a4d85a in _nsnote_callback ()
#13048 0x00007fff82623e3a in __CFXNotificationPost ()
#13049 0x00007fff826103e8 in _CFXNotificationPostNotification ()
#13050 0x00007fff85a447c4 in -[NSNotificationCenter postNotificationNamebject:userInfo:] ()
#13051 0x00007fff85a8bfc0 in _NSPortDeathNotify ()
#13052 0x00007fff8267bf91 in ____CFMachPortChecker_block_invoke_1 ()
#13053 0x00007fff82101ce8 in _dispatch_call_block_and_release ()
#13054 0x00007fff820e087a in _dispatch_queue_drain ()
#13055 0x00007fff820e1127 in _dispatch_queue_serial_drain_till_empty ()
#13056 0x00007fff82113e4c in _dispatch_main_queue_callback_4CF ()
#13057 0x00007fff82617b00 in __CFRunLoopRun ()
#13058 0x00007fff82616c2f in CFRunLoopRunSpecific ()
#13059 0x00007fff85a88a24 in -[NSRunLoop(NSRunLoop) runMode:beforeDate:] ()
#13060 0x00007fff85a88903 in -[NSRunLoop(NSRunLoop) run] ()
#13061 0x00000001000252c9 in ?? ()
#13062 0x0000000100001398 in ?? ()
I suspect blued is getting kicked off because I run the new iStumbler, which has bluetooth support.
So let's see... you respond 6 months later to someone who responded 1 year after the OP. Nice of you to be helpful, but hopefully they got it sorted by now.
Zombie threads rock... just when you think they're dead, they crawl right back up again.
Blued just hung my entire machine!
This process brought my machine to a screeching halt. I use the menu bar clock as an indicator of system operation by enabling seconds. The clock was stuck with either no change or updating seconds in sporadic bursts. Blued ate up almost all the remaining system resources and I was told to quit programs. I tried quitting every program. The computer was frozen and I had Activity Monitor open showing Blued was the culprit, but it was too late. I had to do a hard shut down which is something I haven't had to do in the 6 months that I've been running Snow Leopard on my 24" iMac 3.06. I am going to keep an eye out to see if this happens again. I use bluetooth for file exchange, but I had turned bluetooth off without quitting the exchange program.
Sorry for posting to this zombie thread, but it seems blued being a resource hog is not dead yet! :/
Sounds similar to what I was experiencing.
I have subsequently enabled bluetooth, to use the spiffy new mouse, and have not had a repeat problem.
For me, it has only happened after running iStumbler (which has bluetooth support), and with bluetooth disabled.
You can see if you have the same issue as me by attaching gdb to a run-away blued. It is difficult when it is thrashing, you need to have a terminal window all ready to go, visible on the screen, with a root shell prompt, and then determine the pid of blued (lets call it PID), kick off gdb (gdb /usr/sbin/blued), and attach to the blued process (attach PID).
The stack will be huge, and a back trace will look more or less the same.
I had a similar issue. Take a look at this blog post for a suggested fix: http://cpenniman.blogspot.com/2010/02/blued-process-is-killing-my-cpu.html
I had a similar problem when I got home today. I never use BT and it's turned off. Anyway, a shutdown fixed it, but I have no idea what prompted the "blued" process to start.
just want to confirm that I experienced similar problem recently and the latest tonight when the system was slow and blued was eating 2.5GB of memory and still growing...
I had to kill it. I haven't yet tried renaming the plist files but will do so if I notice it again.
I had iStumbler running earlier today (could be related).
Same problem after running iStumbler
Could be a coincidence but the first time this happened to me was today after running iStumbler. Restart seems to have fixed problem for now.
I had the same issue when installing something on vmware. My machine always has bluetooth shut off but all of a sudden blued started using a ton of my MBP's i7 cpu and a gig of ram!
Best way thing to do is open a terminal and type the following
ps aux | grep blued
sudo kill -9 <ID of blued process here>
this also happened to me after running istumbler
Me too and I had used istumbler as well...must be what's causing it.
Probably not a coincidence. Exactly the same thing happened to me and also after I ran iStumbler.
Just to add to the growing consensus- I also had the same problem after running istumbler. Ate up RAM and seems to have bloated vm file size to over 50gb(!)
Restart seems to have brought things back to normal but I don't expect to be using istumbler anytime soon.