skarzhevskyy/bluecove

Automatically exported from code.google.com/p/bluecove

bluecove's Issues

JVM Exception

The story so far:

at 2006-07-14 03:34 [email protected]:
> When I scan for new devices, sometimes, I can't get the friendly name of
> the new remote devices. In the first scan JVM launches an exception and
> I don't know how to avoid it. Here is the exception:
>
> #
> # An unexpected error has been detected by HotSpot Virtual Machine:
> #
> # EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x6d6c5b75, pid=4004,
tid=2652
> #
> # Java VM: Java HotSpot(TM) Client VM (1.5.0_04-b05 mixed mode, sharing)
> # Problematic frame:
> # V [jvm.dll+0x85b75]
> #
> # An error report file with more information is saved as hs_err_pid4004.log
> #
> # If you would like to submit a bug report, please visit:
> # http://java.sun.com/webapps/bugreport/crash.jsp
> #
> 
> In the .log you have:
> 
> --------------- T H R E A D ---------------
> 
> Current thread (0x00accd88): JavaThread "Thread-0" [_thread_in_vm, id=2652]
> 
> siginfo: ExceptionCode=0xc0000005, reading address 0x00000000
> 
> Registers:
> EAX=0x00000000, EBX=0x26ad96d8, ECX=0x0000deab, EDX=0x6d6c5b58,
ESP=0x0306e358, EBP=0x0306e374, ESI=0x00accd88, EDI=0x7c9110ed,
EIP=0x6d6c5b75, EFLAGS=0x00010246
>
> Top of Stack: (sp=0x0306e358)
> 0x0306e358: 00accd88 00000006 00000000 00acce44
> 0x0306e368: 7c91
> ....
> ....
> 
> But, if I scan two times and I get the friendly name of the bluetooth
> remote device in the second time, I CAN GET IT WELL, and also the
> DeviceClass.
>
> In the SPP Benhui example, in the first scan from the client, the
> friendlyname of the news bluetooth devices, sometimes are empty, but it
> doesn't launch te previous exception. I think that I't must be the same
> problem. In my application i call startinquiry() method, but in this
> first scan i don't get the remote devices data. In the inquirycomplete()
> method i call the startinquiry() method again, and then i get the remote 
> devices data, but it isn't too efficient.

Original issue reported on code.google.com by [email protected] on 19 Aug 2006 at 1:35

Possible bug in UUID expansion

The story so far:

at 2006-05-24 13:09 [email protected] wrote:
> There may be a bug in BlueCove 1.1.1 UUID promotion, i.e., short UUID is 
> not expanded to long UUID as it should.
> 
> We are not however sure if this is BlueCove or Windows XP SP2 stack's
> bug. If that is the case (Windows XP bug) can you add a note about it to 
> this item?
>
> The comment in the following code explains the situation.
>
> DiscoveryAgent discv = LocalDevice.getLocalDevice().getDiscoveryAgent(); 
> // if connecting to BlueCove and Windows machine it's recommended to use
> // UUID("1101", true) rather than UUID(0x1101) which seems not towork.
> UUID uuids[] = new UUID[] { new UUID("1101", true) };
> discv.searchServices(null, uuids, remoteDevice, this);

This sounds very implausible, because the UUID(long)-constructor calls the
UUIS(String)-constructor. But the UUID(String)-constructor seems very
weird. Look at this:

public UUID(String stringValue, boolean shortUUID) {
 int length = stringValue.length();
 if (shortUUID) {
  if (length < 1 || length > 8)
   throw new IllegalArgumentException();
  // How does this look to you?
  init("00000000".substring(length) + stringValue +
   "00001000800000805F9B34FB");
 } else {
  if (length < 1 || length > 32)
   throw new IllegalArgumentException();

init("00000000000000000000000000000000".substring(length)
   + stringValue);
 }
}

Original issue reported on code.google.com by [email protected] on 19 Aug 2006 at 1:06

registerService called too soon

> The description of ServiceRecord.setAttributeValue states:
> 
> "[...] In order for any changes made by this method to be reflected in
> the SDDB, a call must be made to the acceptAndOpen() method of the
> associated notifier to add this ServiceRecord to the SDDB for the first
> time [...]"
> 
> In the implementation however the service is registered in the
> constructor of BluetoothStreamConnectionNotifier instead of in its
> acceptAndOpen() method. This means that changes to the ServiceRecord
> made after creating the notifier but before calling acceptAndOpen for
> the first time, will not be reflected in the SDDB. Since updateRecord is
> unimplemented (for now) this seems unwanted.
>
> Proposed changes:
> 1) remove the registerService call from the constructor
> 2) move it to acceptAndOpen:
> 
> public StreamConnection acceptAndOpen() throws IOException {
>   BluetoothPeer peer =
((LocalDevice)LocalDevice.getLocalDevice()).getBluetoothPeer();
>   if ((handle == 0) && (!closed)) {
>     /* register service */
>     handle = peer.registerService(((ServiceRecordImpl)
serviceRecord).toByteArray());
>   }
>   return new BluetoothConnection(peer.accept(socket));
> }
>
> 3) check if handle != 0 in the close method, before calling
> unregisterService

Original issue reported on code.google.com by [email protected] on 19 Aug 2006 at 1:28

Problems opening and closing connections multiple times

The story so far:

at 2006-03-07 21:01 [email protected] wrote:
> Whilst using Bluecove V1.1.1 I am only able to establish and close SPP
> connections a certain number of times. After this time I have to restart
> the computer in order to establish another connection. The program I have
> written closes both the InputStream and StreamConnectionNotifier each time
> the connection is terminated.


Please describe problem better (how many times, what devices, does it work 
better/worse on other platforms) or send a minimal program to sample this
(one written specifically to show this bug, not the application you are
developing minus everything you don't want us to see). I on the other
hand can tell you, that the programs I have written can stay open for hours
with connections going and coming.

Original issue reported on code.google.com by [email protected] on 19 Aug 2006 at 1:11

Fail to build on Debian 11

I tried and failed to build the code on Debian 11.

I cloned the source, installed maven and ran 'mvn', and got this failure:

Downloaded from central: https://repo.maven.apache.org/maven2/javassist/javassist/3.8.0.GA/javassist-3.8.0.GA.jar (594 kB at 7.7 MB/s)
Downloaded from central: https://repo.maven.apache.org/maven2/net/sf/jour/jour-instrument/2.0.3/jour-instrument-2.0.3.jar (117 kB at 454 kB/s)
[INFO] 
[INFO] --- maven-resources-plugin:2.6:resources (default-resources) @ bluecove ---
[INFO] Using 'ISO-8859-1' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory /home/pere/src/debian/bluecove/bluecove/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.1:compile (default-compile) @ bluecove ---
[INFO] Changes detected - recompiling the module!
[INFO] Compiling 136 source files to /home/pere/src/debian/bluecove/bluecove/target/classes
[INFO] -------------------------------------------------------------
[ERROR] COMPILATION ERROR : 
[INFO] -------------------------------------------------------------
[ERROR] Source option 1.3 is no longer supported. Use 6 or later.
[ERROR] Target option 1.1 is no longer supported. Use 1.6 or later.
[INFO] 2 errors 
[INFO] -------------------------------------------------------------
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary:
[INFO] 
[INFO] bluecove-site-skin 2.0.0 ........................... SUCCESS [  7.429 s]
[INFO] bluecove-parent 2.1.1-SNAPSHOT ..................... SUCCESS [  0.188 s]
[INFO] bluecove 2.1.1-SNAPSHOT ............................ FAILURE [  2.181 s]
[INFO] bluecove-emu 2.1.1-SNAPSHOT ........................ SKIPPED
[INFO] bluecove-tests 2.1.1-SNAPSHOT ...................... SKIPPED
[INFO] bluecove-emu-gui 2.1.1-SNAPSHOT .................... SKIPPED
[INFO] bluecove-gpl 2.1.1-SNAPSHOT ........................ SKIPPED
[INFO] bluecove-bluez 2.1.1-SNAPSHOT ...................... SKIPPED
[INFO] bluecove-android2 2.1.1-SNAPSHOT ................... SKIPPED
[INFO] bluecove-examples 2.1.1-SNAPSHOT ................... SKIPPED
[INFO] dependency-fix 2.1.1-SNAPSHOT ...................... SKIPPED
[INFO] bluecove-tester-base 2.1.1-SNAPSHOT ................ SKIPPED
[INFO] tck-agent 2.1.1-SNAPSHOT ........................... SKIPPED
[INFO] bluecove-tester 2.1.1-SNAPSHOT ..................... SKIPPED
[INFO] bluecove-tester-obex 2.1.1-SNAPSHOT ................ SKIPPED
[INFO] bluecove-microemu-starter 2.1.1-SNAPSHOT ........... SKIPPED
[INFO] obex-install 2.1.1-SNAPSHOT ........................ SKIPPED
[INFO] obex-server 2.1.1-SNAPSHOT ......................... SKIPPED
[INFO] distribution 2.1.1-SNAPSHOT ........................ SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  10.147 s
[INFO] Finished at: 2022-10-24T14:45:44+02:00
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.1:compile (default-compile) on project bluecove: Compilation failure: Compilation failure: 
[ERROR] Source option 1.3 is no longer supported. Use 6 or later.
[ERROR] Target option 1.1 is no longer supported. Use 1.6 or later.
[ERROR] -> [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn <args> -rf :bluecove

servicesDiscovered being fired even when UUIDs aren't found

The story so far:

at 2006-08-11 13:05 [email protected] wrote:
> It doesn't always happen, but sometimes devices that don't have a 
> service with one of the specified UUID's fire a servicesDiscovered in
> the DiscoveryListener.
>
> I have called agent.searchServices() specifying only one UUID which I
> generated myself, so it's unique.
>
> I was running an application in which the servicediscovery was working
> fine. However when a Sony-Ericsson T630 entered the room (which doesn't
> even support JABTW), servicesDiscovered was being fired...
>
> According to the BT API javadoc:
> "searchServices()
> Searches for services on a remote Bluetooth device that have all the
> UUIDs specified in uuidSet."
>
> I have created a workaround in my application by checking for the UUID
> in the ServiceRecord[] array that servicesDiscovered() returns.
>
> I'm attaching a print out of the ServiceRecord supposed to have the
> UUID: 75BC36D7E37B400097A464CD49EF2A85
>
> This print out was generated using the Util.printServiceRecord method
> from the Bluelet application by Ben Hui, available at:
> http://www.benhui.net/modules.php?name=Downloads&d_op=getit&lid=5
>
> By the way, the UUID was created as a long address, so this shouldn't be 
> affected by the other BUG in the tracker that mentions a problem when
> expanding a short UUID to a long UUID.

Original issue reported on code.google.com by [email protected] on 19 Aug 2006 at 1:24

Add Readme

What is this project about?