elix22 / bluecove

Automatically exported from code.google.com/p/bluecove
2 stars 0 forks source link

JVM Exception #5

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
The story so far:

at 2006-07-14 03:34 alvmoriles@users.sourceforge.net:
> 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 paul.tot...@gmail.com on 19 Aug 2006 at 1:35

GoogleCodeExporter commented 9 years ago
Finally I've managed to code a workaround for this bug. 

Here I relate all the details because it may help when trying to isolate and 
reproduce the bug effectively.

It only takes place the very first time that a search is done. So this means 
that to reproduce it I had to restart 
the system every time. 
It also worked to unplug/plug in the bluetooth dongle that I use. But this 
would eventually affect every usb 
device connected to the computer, this could be caused by so many things (as 
winxp itself, my motherboard, 
the usb controller) but it actually happened in my system).
If the computer is left for a considerable amount of time (few hours) with no 
bluetooth activity whatsoever, the 
exception may also be obtained.

So basically, I tried the "loop" trick that alvmoriles suggests, but that 
wouldn't avoid the bug. But I have found 
something that will surely reproduce the bug. Which is to obtain the device 
friendly name immediately after it 
has been discovered. 

For instance, this means that if you check for the device friendly name in the 
"deviceDiscovered()" method of 
the "discoveryListener"  the program will always crash, no matter how many 
times you have gone in the loop.

What my program used to do is to inform the user about the device friendly name 
right after it had been 
found, this would end up with the JVM exception every time that the application 
was run for the first time.

Now I search for every device and I don't retrieve the friendly names at all. 
Once the "inquiryCompleted" has 
been fired and I start looking for services on each device, then I am able to 
show the friendly names.

However, from time to time, these names will be returned as a empty strings. 

Hope this helps. Anyway don't hesitate to ask if I haven't really made myself 
clear, because I am probably one 
of the most interested in seeing this bug fixed :)

If it can be helpful I could try all this stuff with the avetana stack, to see 
if there's something inherent to 
microsoft's driver, as the empty strings instead of actual names.

Good luck with it.

Jaume

Original comment by jaumedej...@gmail.com on 19 Aug 2006 at 9:23

GoogleCodeExporter commented 9 years ago
Fixed the problem in dll would be avalable in version 1.2.1

Original comment by skarzhev...@gmail.com on 16 Dec 2006 at 6:59

GoogleCodeExporter commented 9 years ago

Original comment by skarzhev...@gmail.com on 16 Mar 2007 at 6:39