public inbox for linux-bluetooth@vger.kernel.org
 help / color / mirror / Atom feed
From: Frank de Lange <bluez-f@unternet.org>
To: BlueZ development <bluez-devel@lists.sourceforge.net>
Subject: [Bluez-devel] sdpd in polling loop on disconnect
Date: Fri, 16 Feb 2007 01:31:59 +0100	[thread overview]
Message-ID: <45D4FB7F.6090301@unternet.org> (raw)

Is there anyone else here who has seen sdpd run away in a tight poll()
loop when a connected device drops the connection? I can more or less
reliably get sdpd go mad poll()ing and hogging the CPU by walking out of
range, turning off Bluetooth on the (ngage) phone, sending crap to the
serial port service on the phone, etc.

An almost surefire way to get this behaviour to occur goes as follows:

(assumption: paired phone, serial port bound to /dev/rfcomm3)

cat /dev/rfcomm3 (phone wakes up and wants OK)
echo blah > /dev/rfcomm3 (ditto)
usually sdpd will now start eating the CPU. Attaching gdb does not show
much more than that it is looping in g_main_loop_run:

Program received signal SIGUSR2, User defined signal 2.
0x00e1a402 in __kernel_vsyscall ()
(gdb) bt
#0  0x00e1a402 in __kernel_vsyscall ()
#1  0x008c2cfb in poll () from /lib/libc.so.6
#2  0x0046b453 in ?? () from /lib/libglib-2.0.so.0
#3  0x0046b7c9 in g_main_loop_run () from /lib/libglib-2.0.so.0
#4  0x80001800 in main (argc=1, argv=Cannot access memory at address 0x7
) at main.c:147

It loops in g_main_context_check(), repeatedly calling
g_io_channel_get_buffer_condition() as if it still believes there is
some data left to be read. I will look further into this but I'd like to
hear whether I'm the only one with these problems...

I'm using fedora core development by the way...

Cheers//Frank

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

             reply	other threads:[~2007-02-16  0:31 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-16  0:31 Frank de Lange [this message]
2007-02-16  2:00 ` [Bluez-devel] sdpd in polling loop on disconnect Marcel Holtmann
2007-02-19 20:00   ` Frank de Lange
2007-02-19 20:33     ` Marcel Holtmann
2007-02-19 21:19       ` Frank de Lange
2007-02-19 21:28         ` Johan Hedberg
2007-02-19 21:31         ` Marcel Holtmann
2007-02-19 21:36         ` Frank de Lange

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=45D4FB7F.6090301@unternet.org \
    --to=bluez-f@unternet.org \
    --cc=bluez-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox