Fw: Crash when using Bluetooth

Dominique Rety dominiquerety at hotmail.fr
Wed Jan 9 10:05:20 UTC 2013


Hi all,

To my understanding, before connecting a bluetooth device it is necessary to perform discovering to get the remote MAC address.
Do you successfully go through this step when testing Bluetooth in your environment ?

Device discovering involves the broadcast receiver, which is started from QBluetoothLocalDevice::startDiscovery
Therefore it seems to me that the patch consisting in reloading the btAdapterClass must also be applied to the startDiscovery(), cancelDiscovery() and isDiscovering() methods.

While trying to go further in my tests, I noticed that AndroidBroadcastReceiver suffers from the same syndrome.
Then I tried to reload jQtBroadcastReceiverClass from "org/kde/necessitas/mobile/QtBroadcastReceiver", but without success (class not found).
QtBroadcastReceiver is an extension of the BroadcastReceiver Java class (cf. QtBroadcastReceiver.java)
I can successfully load jQtBroadcastReceiverClass from "android/content/BroadcastReceiver", but of course the program fails later because the class doesn't contain the expected extensions.

Do you have any explanation why it is possible to find a class from "android/bluetooth/BluetoothAdapter" or from "android/content/BroadcastReceiver", but not from "org/kde/necessitas/mobile/QtBroadcastReceiver" ?
More generally, why any FindClass performed during the connectivity library load work fine but must be repeated at program run time ? Why some Java classes could become no more accessible ?
Is there a change in Qt loading logic that can explain this ? How to investigate in this direction ?

I will be happy if I can make a contribution to diagnose these problems.

Dominique Rety


----- Original Message ----- 
From: Dominique Rety 
To: Kate Alhola 
Cc: necessitas-devel at kde.org 
Sent: Friday, January 04, 2013 2:52 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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/necessitas-devel/attachments/20130109/7d0e1231/attachment-0001.html>


More information about the Necessitas-devel mailing list