Crash when using Bluetooth

Sun Oct 6 12:16:47 UTC 2013

Morning, gentlemen!

The time has come. I was again in the need of my Bluetooth port - so finally I had to take some time for it. Considering the good Android support in Qt5x now, I thought it would be a good idea to start from rebasing my code to Qt5 stable-latest (currently v5.2 Alpha 1). And it wasn't difficult. With some small modifications I got it working nicely.

About the issues:

1.
I'm still using my own JNIThreadHelper but I see that there is a general one available now in qtandroidextras (I like to believe that it was inspired by my code :P). Anyway, I don't get any troubles with thread affinity with either of them.

2.
About the crash: "JNI ERROR (app bug): accessed stale local reference 0xe680001d (index 7 in a table of size 4) "
As you might already know by now, Android (latest versions) move objects around in memory. In the old days I created JNI global references only for the objects that I was afraid garbage collector might delete. Nowadays global refs must be created for all object pointers because Android moves them around like a cat is carrying babies. And that includes class reflections.

But now I'm not sure what to do with the code - where to put it first. Any ideas?

Regards
Lauri

----- Original Message -----
From: "Dominique Rety" <dominiquerety at hotmail.fr>
To: "Kate Alhola" <kate.alhola at gmail.com>
Cc: necessitas-devel at kde.org
Sent: Friday, January 4, 2013 3:52:13 PM
Subject: Re: Crash when using Bluetooth

Hi Kate, 
I continue trying to operate the btchat sample, which implements functionalities very closed to those we have to use in our project. 
Before receiving your patch, I tried a solution consisting in moving the initialization code for the connectivity library (contained in JNI_OnLoad) to a separate function executed just before the first call to the library. 
For btchat, I execute this function just before QBluetoothLocalDevice().name() in the main application context. 
This solution works (I can get the device name without JNI ERROR), probably because the initialization code is performed in a thread context that remains valid. 
I also tried your patches, which solve the get name JNI ERROR as well. Your solution is probably better if it works without any constraint on the initialization thread context. 
However, all of this only partly solves the problem. When I try to connect through the btchat application, I got an other JNI ERROR when the device discovery logic starts. 
I have applied your patch to the QBluetoothLocalDevice::startDiscovery() cancelDiscovery() and isDiscovering() methods. This enables the code to continue a bit. 
But then I have similar problems into the AndroidBroadcastReceiver::initialize() method when calling env->RegisterNatives(jQtBroadcastReceiverClass). 
So I tried a similar patch to fix this issue by first issuing: 
JNIThreadHelper env; 
jQtBroadcastReceiverClass = env->FindClass("org/kde/necessitas/mobile/QtBroadcastReceiver"); 
Unfortunately, this call returns a NULL and I get a FATAL EXCEPTION, java.lang.NoClassDefFoundError: org/kde/necessitas/mobile/QtBroadcastReceiver. 
Note that the 
jQtBroadcastReceiverClass = env->FindClass("org/kde/necessitas/mobile/QtBroadcastReceiver"); 
is performed once with success in the AndroidBroadcastReceiver::loadJavaClass() method, which is called at libQtConnectivity library loading time, from JNI_OnLoad. 
I can't understand why this call is only valid at library load time. 
I'm not sure that trying to apply a similar patch in this situation would be a solution to this issue. 
Do you have an idea to progress on this subject ? 
Thank you for your help. 
Dominique RETY 

----- Original Message ----- 
From: Kate Alhola 
To: Dominique Rety 
Cc: necessitas-devel at kde.org 
Sent: Thursday, January 03, 2013 2:59 PM 
Subject: Re: Crash when using Bluetooth 

On Wed, Dec 26, 2012 at 7:33 PM, Dominique Rety < dominiquerety at hotmail.fr > wrote: 

Hi Kate, 
Thank you for your answer. 
I tried some traces and modifications into the lib QtConnectivity without success. It seems to me that functions into the library already contain calls to JNIThreadHelper class that should setup the Java environment by performing jvm->AttachCurrentThread(), but this doesn't solve the problem. 
At the same time, I performed some basic bluetooth tests directly through Java Eclipse (BluetoothAdapter.getDefaultAdapter.getName), which work fine on Nexus 7 with Android 4.2. 
However, our project contains some legacy parts that have already been developed in C, and using Qt would be the very best way to integrate them. Therefore I will only envision to implement a direct bridge between Java and C parts as a last resort if I can't find a viable solution with Qt. 
Consequently, I am very interested by your patches even before the next release, which could be helpful for us to take a decision for our development. Overriding and deploying the default Necessitas lib QtConnectivity is not a problem for me, at least for test purpose. 

Now patches are on Review board https://git.reviewboard.kde.org/r/108113/ . I would be happy if you could try them. 

Sorry about delays publishing them 

Kate 

Regards, 
Dominique 

----- Original Message ----- 
From: Kate Alhola 
To: Dominique Rety 
Cc: <necessitas-devel at kde.org> 
Sent: Wednesday, December 26, 2012 4:36 PM 
Subject: Re: Crash when using Bluetooth 

On 13.12.2012, at 16.41, Dominique Rety < dominiquerety at hotmail.fr > wrote: 

Hi, 
I am currently developing a telecommunication project involving Blutooth communication between Android devices. For this purpose, I'm trying to use Necessitas Bluetooth support and I experiment very similar problems that are described in the "Crash when using Bluetooth" (Kate Alhola) archive thread. 

There is several issues in current necessitas libQtConnectivity version. I have hopefully fixed most of them and i have version of libQtConnectivity that least works with my own applocation. I try to deliver patches to necessitas project so that fixes could be included in next release. 

Environment: 
Java JDK 1.7.0_09 
Qt Creator 2.5.83 Based on Qt 4.8.3 running on Linux Suze 
Kit = Necessitas Qt 4.8.2 for Android armv7a 
Compiler = Android GCC (arm-4.4.3) 
Android target SDK = android-16 
Deploy to Nexus 7 with Android version 4.2. 
I firstly tried to deploy the btchat sample and I faced the same problem: 
JNI ERROR (app bug): accessed stale local reference 0xe680001d (index 7 in a table of size 4) 
VM aborting 
Fatal signal 11 (SIGSEGV) at 0xdeadd00d (code=1), thread 13965 (.example.btchat) 
Setting traces in different source files of the connectivity library, I also noticed that the error happens when trying to use some member functions of QBluetoothLocalDevice (btchat sample requests for the local device name from the main function). 
I tried to bypass this problem by only creating the QBluetoothLocalDevice without requesting for the device name in the btchat application. The program then starts correctly. 
In the btchat application, the "Connect" button calls the QBluetoothServiceDiscoveryAgent::start function. This function randomly processes the request because it relies on discoveryState and deviceAddress members, which seem not to be initialized : either the discovery process freezes or the program aborts with an error (if luckily discoveryState and deviceAddress members get consistent values). I didn't try any further investigation. It seems to me that the connectivity library is compiled with qbluetoothlocaldevice_p.cpp, which just contains empty functions for the QBluetoothLocalDevice class, instead of a customized source for Android. 

Yes, that's case. The QBluetoothLocalDevice initializes static handles to java virtual machine that are then referenced by other modules. I have made fixes to several parts of libQtConnectivity 

Is Bluetooth support for Android in Necessitas complete ? 

Most of, some functions are still missing but there are some bugs in current version 

Is the btchat sample expected to work properly with Android ? 

I have not tried that one 

Is there any specific configuration issue I could miss ? 

That's good question, what is origin of the bugs, does it work with older android 
Versions ? The source reason of bugs is JNI handles alocation that conflict with 
Current thread structure and some that handles are expired when used. I have only tested with 
Android 4.x 

Is there any corrective or complement software I could download ? 

I could make my patches avaiable before next release but overriding default necessitas libQtConnectivity requires some tricks 

How can I progress on this issue ? What is the best way to get help and advices ? 

This list works fine. 

Kate 

Regards, 
Dominique RETY 
dominiquerety at hotmail.fr 

_______________________________________________ 
Necessitas-devel mailing list 
Necessitas-devel at kde.org 
https://mail.kde.org/mailman/listinfo/necessitas-devel 

_______________________________________________
Necessitas-devel mailing list
Necessitas-devel at kde.org
https://mail.kde.org/mailman/listinfo/necessitas-devel