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.