All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dimitry Andric <dimitry.andric@tomtom.com>
To: bluez-devel@lists.sourceforge.net
Subject: Re: [Bluez-devel] SDP browsing inconsistency on Motorola A1000
Date: Fri, 11 Mar 2005 15:35:22 +0100	[thread overview]
Message-ID: <4231ACAA.3050207@tomtom.com> (raw)
In-Reply-To: <1110549590.32238.131.camel@baroque.rococosoft.com>

[-- Attachment #1: Type: text/plain, Size: 1697 bytes --]

Stephen Crane wrote:

> I don't know what's causing your problem but I've had a look at the
> dumps and it seems that the integer-sequence values being printed out in
> error are in fact from the LANG_BASE_ATTR_ID_LIST, which occurs 44 bytes
> after the SVCLASS_ID_LIST. 

I didn't notice this earlier, but I'd say they are *before* the
ServiceClassIDList:

[...]
Attribute Identifier : 0x0 - ServiceRecordHandle
  Integer : 0x10003
[...]
Attribute Identifier : 0x6 - LanguageBaseAttributeIDList
  Data Sequence
    Code ISO639 (Integer) : 0x656e
    Encoding (Integer) : 0x6a
    Base Offset (Integer) : 0x100
[...]
Attribute Identifier : 0x0 - ServiceRecordHandle
  Integer : 0x10003
Attribute Identifier : 0x1 - ServiceClassIDList
  Data Sequence
    Integer : 0x656e
    Integer : 0x6a
    Integer : 0x100
[...]

At least I've got a bit of a clue where to start looking now. :)


> Can you step through this in a debugger on the ARM box?

I'll need to fix up some things for that, I'll get back about this
later.  I tried debugging on the thing before, but there's some weird
problems with gdb on it.

Usually I try to get by with inserting printfs in various strategic
locations, but the problem here is that I'm not sure where to put
them...


> Also to check for memory corruption, can you run it under valgrind
> on the x86 box?

Valgrind reports no problems, at least as far as I can interpret its
output.  (Attached as valgrind.dump.gz)


> Finally, are you sure that the text of your sdptool-arm dump is correct?
> The data for the record in question seems to be repeated:

Hm, either my mail client or my mail server corrupted this specific
file.  I'm sending it again as a .gz file.


[-- Attachment #2: valgrind.dump.gz --]
[-- Type: application/octet-stream, Size: 1553 bytes --]

[-- Attachment #3: sdptool-arm.gz --]
[-- Type: application/octet-stream, Size: 1553 bytes --]

      reply	other threads:[~2005-03-11 14:35 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-11 12:40 [Bluez-devel] SDP browsing inconsistency on Motorola A1000 Dimitry Andric
2005-03-11 13:59 ` Stephen Crane
2005-03-11 14:35   ` Dimitry Andric [this message]

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=4231ACAA.3050207@tomtom.com \
    --to=dimitry.andric@tomtom.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.