Discussion :

[atha2]

Bonjour,

J'ai parfois (1 fois sur 5 ou 6 je dirais) quand je quitte mon application des erreurs comme la suivante

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
04-10 15:30:20.715: A/libc(25759): @@@ ABORTING: INVALID HEAP ADDRESS IN dlfree
04-10 15:30:20.715: A/libc(25759): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1)

Ces erreurs ne se voient pas au niveau du téléphone quand je quitte mais quand je redémarre j'ai un écran noire qui fait planter le téléphone pendant 15/20 secondes.

Mon code n'utilise pas le NDK, mais utilise le Bluetooth, le MediaPlayer et charge pour environ 1Mo d'image qui utilisent des lib C.
Comment puis-je savoir d'où provient cette erreur ? Et pourquoi en Java n'ai-je pas une Exception ?


La seule piste que j'ai c'est :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

04-10 16:21:04.046: V/BluetoothSocket.cpp(30784): destroyNative

qui est affiché 2 fois dans les logs alors que la fonction destroyNative n'est appelé que par la méthode close() de BluetoothSocket.java qui fait d'abord :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

 if (mSocketState == SocketState.CLOSED) return;

Bizarre du coup. Encore plus bizarre la classe BluetoothSocket.java contient :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
    /** @hide */
    @Override
    protected void finalize() throws Throwable {
        try {
            close();
        } finally {
            super.finalize();
        }
    }

J'ai toujours lu qu'utiliser finalize() pour libérer les ressources était une mauvaise idée... J'ai comme l'impression que Android/GC close() la socket sans attendre que mes threads de lecture/écriture aient fermés leurs output/input streams.

Est-ce que quelqu'un aurait une idée comment détecter/corriger mon problème ?

[nicroman]

J'ai toujours lu qu'utiliser finalize() pour libérer les ressources était une mauvaise idée...

Oui... c'est une bad practice.... parceque la ressource va demander une double passe du garbage-collector pour être récupérée.
Mais il est tout de même recommandé dans les classes maintenant une ressource de vérifier que l'utilisateur de la classe fait bien les choses correctement....
Parsonnellement j'utilise plus les exceptions dans mes classes:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
@Override
    protected void finalize() {
        if (isOpened()) {
            close(); // close anyway....
            throw new IllegalStateException("Finalized without being closed !");
        }
    }

[atha2]

J'ai finalement corriger ce problème qui venait du Bluetooth en ne séparant pas la gestion de la socket et des streams dans différents threads comme je le faisait avant. Je n'ai plus qu'un seul thread qui s'occupe de tout et je n'ai plus de problème.

Ce qui posait problème était ma conception pour libérer proprement les ressources :

• Ma socket était gérer par le thread UI
• Dans le onStop() je demandais au 2 threads de se terminer. Ce qui n'est pas immédiat à cause des lectures bloquantes et ma gestion de l'écriture (j'avais mis en place un système de boite au lettre et le thread d'écriture aller chercher la tram à envoyer, ce qui était gérer de manière bloquante (wait(timeout))pour ne pas utiliser le CPU).
• Une fois que le thread était terminé, il envoyais un event à l'activité (mais dans son propre thread avec les synchronized qui vont bien). Lors du 2ème appel au listener, je fermai la socket.

Là où je pense qu'était mon erreur c'est que la socket était déjà (quand ça plantait) finalized (et closed) car liée au cycle de vie de l'application.

Ce qui reste bizarre, c'est que mon listener étant une WeakReference, je n'aurai pas du pouvoir accéder à la socket si elle est finalized
A part s'il y a un court temps entre le moment on la méthode finalized est appelé et le moment où elle est réellement libérée.