Problème avec OpenJDK

Version imprimable

19/01/2014, 17h29
Patrice Henrio

Problème avec OpenJDK

Bonjour,

J'ai développé une application sous l'ide Eclipse. Elle fonctionne très bien sous windows, tant dans l'ide (run) ou en fichier jar. J'ai transporté ce projet sous Ubuntu : le jar ne marche plus, j'ai refait le programme avec l'ide eclipse sous ubuntu avec la jvm openjdk (version 7).

Ce programme est pour partie un lecteur de MP3 avec interface graphique.
Avec la commande run le programme se lance mais lorsque j'utilise les boutons de l'interface graphique (pause ou stop) le programme se fige d'une manière aléatoire mais très souvent sans donner d'erreur : même la croix de la fenêtre devient inopérante.
Si je change la jvm et que je remplace openjdk par sunjdk : le programme re-fonctionne parfaitement comme sous windows.

Quelqu'un a-t'il une explication ?
19/01/2014, 18h48
JoeChip

Pas les mêmes bugs dans les deux jdk...?
19/01/2014, 20h00
Patrice Henrio

Citation:

Envoyé par JoeChip

Pas les mêmes bugs dans les deux jdk...?

Pas de bug sous windows (sous eclipse ou en jar), pas de bug sous ubuntu/Eclipse/sun,
bug sous Ubuntu/eclipse/openjdk : Pas de trace d'errors : l'interface graphique ne réagit plus c'est tout.
19/01/2014, 20h46
joel.drigo

Salut,

Tu as essayé de faire un thread dump (avec jvisualvm par exemple) pour voir le problème (probable deadlock sur thread swing) ?
19/01/2014, 21h22
Patrice Henrio

Citation:

Envoyé par joel.drigo

Salut,

Tu as essayé de faire un thread dump (avec jvisualvm par exemple) pour voir le problème (probable deadlock sur thread swing) ?

Là je sais pas faire. Va falloir que je regarde cela de près.
Et il y a pas un moyen directement sous eclipse de surveiller les thread lors de l'exécution
19/01/2014, 21h36
joel.drigo

Tu lances ton application, et quand ça bloque, tu lances jvisualvm (qui se trouve dans le dossier bin de ton jdk). Tu vas voir ton programme dans la liste : tu double-cliques dessus. Ensuite tu vas dans l'onglet Thread, et tu cliques sur Thread dump. Ceci va te permettre de voir toutes les stack traces des threads actifs dans ton programme, et les objets qu'ils verrouillent, ou attendent (donc verrouillés par d'autres threads). Un thread qui attend est un thread bloqué.

Si un thread verrouille un objet (ligne avec locked) puis en attends un autre (ligne avec waiting) qui est verrouillé par un autre thread qui attend celui que le premier verrouille, tu as un deadlock (ceci peut se passer sur des chaines de plusieurs threads) : les deux vont s'attendre l'un l'autre indéfiniment.
Il suffit que tu analyses ces stack traces pour voir déjà si c'est tes classes qui sont la cause de ces deadlocks (inter-verrouillages, ou blocages mutuels).
19/01/2014, 21h40
joel.drigo

Citation:

Envoyé par Patrice Henrio

Et il y a pas un moyen directement sous eclipse de surveiller les thread lors de l'exécution

Il y'a un moyen dans Eclipse, en mode debug, sur ton projet, mais pas sur une application externe. Enfin, on doit pouvoir peut être le paramétrer : personnellement, je ne l'ai jamais fait. Pour le coup, je le fais avec NetBeans, que je trouve bien plus simple pour faire ça.
19/01/2014, 22h07
Patrice Henrio

Citation:

Envoyé par joel.drigo

Tu lances ton application, et quand ça bloque, tu lances jvisualvm (qui se trouve dans le dossier bin de ton jdk). Tu vas voir ton programme dans la liste : tu double-cliques dessus. Ensuite tu vas dans l'onglet Thread, et tu cliques sur Thread dump. Ceci va te permettre de voir toutes les stack traces des threads actifs dans ton programme, et les objets qu'ils verrouillent, ou attendent (donc verrouillés par d'autres threads). Un thread qui attend est un thread bloqué.

Si un thread verrouille un objet (ligne avec locked) puis en attends un autre (ligne avec waiting) qui est verrouillé par un autre thread qui attend celui que le premier verrouille, tu as un deadlock (ceci peut se passer sur des chaines de plusieurs threads) : les deux vont s'attendre l'un l'autre indéfiniment.
Il suffit que tu analyses ces stack traces pour voir déjà si c'est tes classes qui sont la cause de ces deadlocks (inter-verrouillages, ou blocages mutuels).

Est-ce que ça marche même si j'ai lancé l'application à partir de eclipse ?

J'ai bien trouvé jvisualvm mais dans la jvm de sun ... pas sûr que ça fonctionne avec openjdk ?

en fait visualjm existe pour openjdk. Il me reste à essayer de comprendre le fonctionnement ...

En tout cas merci pour cette piste de solution à mon problème.
19/01/2014, 22h25
Patrice Henrio

Citation:

Envoyé par joel.drigo

Il y'a un moyen dans Eclipse, en mode debug, sur ton projet, mais pas sur une application externe. Enfin, on doit pouvoir peut être le paramétrer : personnellement, je ne l'ai jamais fait. Pour le coup, je le fais avec NetBeans, que je trouve bien plus simple pour faire ça.

Ce n'est pas une application externe. Il va falloir que je comprenne mieux le module debug de eclipse.
19/01/2014, 22h45
joel.drigo

Oui. Mais dans ce cas, tu peux aussi utiliser le mode débug d'Eclipse.
19/01/2014, 23h11
Patrice Henrio

Citation:

Envoyé par joel.drigo

Oui. Mais dans ce cas, tu peux aussi utiliser le mode débug d'Eclipse.

Est-ce que l'on peut voir de la même façon les thread et leur évolution ?
19/01/2014, 23h51
joel.drigo

1 pièce(s) jointe(s)

Oui, perspective debug, vue debug. Tu verras les threads, les verrous (owns by), les objets bloquants (waiting for).

Explication sur un thread dump

Est-ce que quelqu'un peut m'expliquer les diverses lignes d'un thread dump. Surtout à quoi correspondent chaque thread.
J'ai pris un cas simple : une fenêtre et c'est tout.

Tout d'abord la classe :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
 
package test;
import javax.swing.JFrame;
public class TestThread extends JFrame
{
	public TestThread()
	{
		super("essai");
		setSize(400,200);
		setVisible(true);
	}
 
	public static void main(String[] args)
	{
		javax.swing.SwingUtilities.invokeLater(new Runnable()
		{
			public void run()
			{
				new TestThread();
			}
		});
 
	}
}

Maintenant le thread dump. Je trouve que ça fait beaucoup de thread pour un truc aussi simple.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
 
 
2014-01-20 10:19:50
Full thread dump OpenJDK Server VM (23.7-b01 mixed mode):
 
"RMI TCP Connection(2)-127.0.0.1" daemon prio=10 tid=0x8adafc00 nid=0xf40 runnable [0x87384000]
   java.lang.Thread.State: RUNNABLE
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:150)
	at java.net.SocketInputStream.read(SocketInputStream.java:121)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
	- locked <0xa8962390> (a java.io.BufferedInputStream)
	at java.io.FilterInputStream.read(FilterInputStream.java:83)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- <0xa894e358> (a java.util.concurrent.ThreadPoolExecutor$Worker)
 
"JMX server connection timeout 19" daemon prio=10 tid=0x8af0d000 nid=0xf3d in Object.wait() [0x873d5000]
   java.lang.Thread.State: TIMED_WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa90eaf20> (a [I)
	at com.sun.jmx.remote.internal.ServerCommunicatorAdmin$Timeout.run(ServerCommunicatorAdmin.java:168)
	- locked <0xa90eaf20> (a [I)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- None
 
"RMI Scheduler(0)" daemon prio=10 tid=0x8af0a000 nid=0xf3c waiting on condition [0x87426000]
   java.lang.Thread.State: TIMED_WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0xa912bf58> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.parkNanos(LockSupport.java:226)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.awaitNanos(AbstractQueuedSynchronizer.java:2082)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:1090)
	at java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.take(ScheduledThreadPoolExecutor.java:807)
	at java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1068)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1130)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- None
 
"RMI TCP Connection(1)-127.0.0.1" daemon prio=10 tid=0x8ad20800 nid=0xf3b runnable [0x87477000]
   java.lang.Thread.State: RUNNABLE
	at java.net.SocketInputStream.socketRead0(Native Method)
	at java.net.SocketInputStream.read(SocketInputStream.java:150)
	at java.net.SocketInputStream.read(SocketInputStream.java:121)
	at java.io.BufferedInputStream.fill(BufferedInputStream.java:235)
	at java.io.BufferedInputStream.read(BufferedInputStream.java:254)
	- locked <0xa9142360> (a java.io.BufferedInputStream)
	at java.io.FilterInputStream.read(FilterInputStream.java:83)
	at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:535)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run0(TCPTransport.java:808)
	at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:667)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- <0xa912b828> (a java.util.concurrent.ThreadPoolExecutor$Worker)
 
"RMI TCP Accept-0" daemon prio=10 tid=0x093f7000 nid=0xf39 runnable [0x874c8000]
   java.lang.Thread.State: RUNNABLE
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.AbstractPlainSocketImpl.accept(AbstractPlainSocketImpl.java:398)
	at java.net.ServerSocket.implAccept(ServerSocket.java:530)
	at java.net.ServerSocket.accept(ServerSocket.java:498)
	at sun.management.jmxremote.LocalRMIServerSocketFactory$1.accept(LocalRMIServerSocketFactory.java:52)
	at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.executeAcceptLoop(TCPTransport.java:387)
	at sun.rmi.transport.tcp.TCPTransport$AcceptLoop.run(TCPTransport.java:359)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- None
 
"Attach Listener" daemon prio=10 tid=0xb644f000 nid=0xf37 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
   Locked ownable synchronizers:
	- None
 
"DestroyJavaVM" prio=10 tid=0xb6406800 nid=0xf1e waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
   Locked ownable synchronizers:
	- None
 
"AWT-EventQueue-0" prio=10 tid=0x87619c00 nid=0xf30 waiting on condition [0x875ad000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0xa90a26c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
	at java.awt.EventQueue.getNextEvent(EventQueue.java:543)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
 
   Locked ownable synchronizers:
	- None
 
"AWT-Shutdown" prio=10 tid=0x87618800 nid=0xf2f in Object.wait() [0x875fe000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa91604a8> (a java.lang.Object)
	at java.lang.Object.wait(Object.java:503)
	at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:287)
	- locked <0xa91604a8> (a java.lang.Object)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- None
 
"AWT-XAWT" daemon prio=10 tid=0x87614400 nid=0xf2e runnable [0x87757000]
   java.lang.Thread.State: RUNNABLE
	at sun.awt.X11.XToolkit.waitForEvents(Native Method)
	at sun.awt.X11.XToolkit.run(XToolkit.java:627)
	at sun.awt.X11.XToolkit.run(XToolkit.java:591)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- None
 
"Java2D Disposer" daemon prio=10 tid=0x88aed400 nid=0xf2d in Object.wait() [0x877a8000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa90e9830> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0xa90e9830> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at sun.java2d.Disposer.run(Disposer.java:145)
	at java.lang.Thread.run(Thread.java:724)
 
   Locked ownable synchronizers:
	- None
 
"Service Thread" daemon prio=10 tid=0x8ae9ac00 nid=0xf2a runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
   Locked ownable synchronizers:
	- None
 
"C2 CompilerThread1" daemon prio=10 tid=0x8ae99000 nid=0xf29 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
   Locked ownable synchronizers:
	- None
 
"C2 CompilerThread0" daemon prio=10 tid=0x8ae97000 nid=0xf28 waiting on condition [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
   Locked ownable synchronizers:
	- None
 
"Signal Dispatcher" daemon prio=10 tid=0x8ae95400 nid=0xf27 runnable [0x00000000]
   java.lang.Thread.State: RUNNABLE
 
   Locked ownable synchronizers:
	- None
 
"Finalizer" daemon prio=10 tid=0x8ae50c00 nid=0xf25 in Object.wait() [0x8903f000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa9040dd8> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:135)
	- locked <0xa9040dd8> (a java.lang.ref.ReferenceQueue$Lock)
	at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:151)
	at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:189)
 
   Locked ownable synchronizers:
	- None
 
"Reference Handler" daemon prio=10 tid=0x8ae4f000 nid=0xf24 in Object.wait() [0x89091000]
   java.lang.Thread.State: WAITING (on object monitor)
	at java.lang.Object.wait(Native Method)
	- waiting on <0xa9040c70> (a java.lang.ref.Reference$Lock)
	at java.lang.Object.wait(Object.java:503)
	at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:133)
	- locked <0xa9040c70> (a java.lang.ref.Reference$Lock)
 
   Locked ownable synchronizers:
	- None
 
"VM Thread" prio=10 tid=0x8ae48800 nid=0xf23 runnable 
 
"GC task thread#0 (ParallelGC)" prio=10 tid=0xb6410800 nid=0xf21 runnable 
 
"GC task thread#1 (ParallelGC)" prio=10 tid=0xb6412000 nid=0xf22 runnable 
 
"VM Periodic Task Thread" prio=10 tid=0x8ae9cc00 nid=0xf2b waiting on condition 
 
JNI global references: 257

J'utilise openjdk sous Ubuntu
Le programme est lancé sous Eclipse.

Le but est de pouvoir traiter ensuite les thread d'un programme qui présente un deadlock, mais tant que je comprendrai pas ce dump je pense qu'il est inutile que je cherche à l'aveugle à régler le problème.

Merci.

Dans ce programme, le seul thread qui t'interesse, c'est le thread EDT, c'est à dire "AWT-EventQueue-0". C'est lui qui a la charge de mettre à jour l'IHM des composants swing. Lorsque l'IHM est figée, c'est souvent lui qui est deadlocké avec un autre thread.
Les autres sont des Thread systeme.

A mon avis, le plus simple pour toi pour comprendre est de créer un cas de deadlock et de voir a quoi ca peut ressembler.
En voila un trivial. Dans une application reelle, ca peut etre plus complexe à voir (par exemple thread 1 qui attend thread 2, thread 3 qui attend thread 2 ... thread n qui attend thread 1).

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
import javax.swing.JFrame;
 
public class TestThread extends JFrame
{
   public TestThread()
   {
      super("essai");
      setSize(400, 200);
      setVisible(true);
      setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
 
      final Object sem1 = new Object();
      final Object sem2 = new Object();
 
      Thread t1 = new Thread()
      {
         @Override
         public void run()
         {
            while (true)
            {
               synchronized (sem1)
               {
                  try
                  {
                     Thread.sleep(100);
                  }
                  catch (InterruptedException e)
                  {
                     e.printStackTrace();
                  }
                  synchronized (sem2)
                  {
                     System.out.println("tread1");
                  }
               }
            }
         }
      };
 
      Thread t2 = new Thread()
      {
         @Override
         public void run()
         {
            while (true)
            {
               try
               {
                  Thread.sleep(100);
               }
               catch (InterruptedException e)
               {
                  e.printStackTrace();
               }
               synchronized (sem2)
               {
                  synchronized (sem1)
                  {
                     System.out.println("tread1");
                  }
               }
            }
         }
      };
      t1.setName("MonThread1");
      t1.start();
      t1.setName("MonThread2");
      t2.start();
   }
 
   public static void main(String[] args)
   {
      javax.swing.SwingUtilities.invokeLater(new Runnable()
      {
         public void run()
         {
            new TestThread();
         }
      });
   }
}

Dans cet exemple, c'est les thread t1 et t2 qui sont en deadlock.

Merci beaucoup.

Je vais continuer à creuser. J'ai effectivement un deadlock dans un programme beaucoup plus complexe.

Comme je l'indiquais au tout début du fil de la conversation : sous openJDK j'ai un deadlock et pas sous sunJDK. Il semble que icedtea (un composant de openJDK) soit en cause.

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
Found one Java-level deadlock:
=============================
"Lecteur MP3":
  waiting to lock monitor 0x8b00b218 (object 0xa934cae8, a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine),
  which is held by "AWT-EventQueue-0"
"AWT-EventQueue-0":
  waiting to lock monitor 0x8b00a534 (object 0x93c39970, a java.lang.Object),
  which is held by "Lecteur MP3"
 
Java stack information for the threads listed above:
===================================================
"Lecteur MP3":
	at org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.write(PulseAudioSourceDataLine.java:183)
	- waiting to lock <0xa934cae8> (a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine)
	- locked <0x93c39970> (a java.lang.Object)
	at memory.lecteur.LecteurMP3.run(LecteurMP3.java:636)
	- locked <0xa921fa98> (a memory.lecteur.javazoom.spi.mpeg.sampled.convert.DecodedMpegAudioInputStream)
	at java.lang.Thread.run(Thread.java:724)
"AWT-EventQueue-0":
	at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.stop(PulseAudioDataLine.java:386)
	- waiting to lock <0x93c39970> (a java.lang.Object)
	- locked <0xa934cae8> (a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine)
	at org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.stop(PulseAudioSourceDataLine.java:51)
	at memory.lecteur.LecteurMP3.pausePlayback(LecteurMP3.java:381)
	at memory.lecteur.LecteurMP3.pause(LecteurMP3.java:841)
	at memory.chants.JLecteurMP3.pauseChant(JLecteurMP3.java:409)
	at memory.chants.JLecteurMP3.actionPerformed(JLecteurMP3.java:336)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
	at java.awt.Component.processMouseEvent(Component.java:6505)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3312)
	at java.awt.Component.processEvent(Component.java:6270)
	at java.awt.Container.processEvent(Container.java:2229)
	at java.awt.Component.dispatchEventImpl(Component.java:4861)
	at java.awt.Container.dispatchEventImpl(Container.java:2287)
	at java.awt.Component.dispatchEvent(Component.java:4687)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
	at java.awt.Container.dispatchEventImpl(Container.java:2273)
	at java.awt.Window.dispatchEventImpl(Window.java:2719)
	at java.awt.Component.dispatchEvent(Component.java:4687)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.awt.EventQueue$4.run(EventQueue.java:708)
	at java.awt.EventQueue$4.run(EventQueue.java:706)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
 
Found 1 deadlock.

Comme ce composant n'existe pas tel quel dans sunJDK ça explique pourquoi il y a problème sous l'une des jvm et pas sous l'autre.

20/01/2014, 11h54
joel.drigo
Citation:

Envoyé par Patrice Henrio

Maintenant le thread dump. Je trouve que ça fait beaucoup de thread pour un truc aussi simple.

Il y a de nombreux threads que tu peux ignorer :
- Les threads RMI (dans ton cas d'application) sont utilisés par jvisualvm pour communiquer avec la jvm
- Les threads techniques de la JVM, comme ceux qui concerne le GC
En règle générale, interesses-toi aux threads :
- Dont les stack traces passent par tes classes, puisque c'est ton code avant tout que tu éxécutes, et qui donc est suscetible de présenter des problèmes
- L'Event Dispatcher Thread (celui qui s'appelle AWT-Event Queue), qui concerne l'affichage, comme le dit @hwoarang,
Ensuite le thread dump présente une liste des stack traces de tous les threads, c'est-à-dire l'enchainement des appels de méthodes en méthodes qui sont faits sur chacun de ces threads.

Par exemple :
```
"AWT-EventQueue-0" prio=10 tid=0x87619c00 nid=0xf30 waiting on condition [0x875ad000]
   java.lang.Thread.State: WAITING (parking)
	at sun.misc.Unsafe.park(Native Method)
	- parking to wait for  <0xa90a26c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2043)
	at java.awt.EventQueue.getNextEvent(EventQueue.java:543)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:211)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
```
On commence par le nom du thread entre guillemet : "AWT-EventQueue-o, suivi d'infromation (priorité, référence...).
Ensuite, on a l'état du thread. Ici le thread est dans un état d'attente.
Puis on a la trace des appels récursives, en partant du dernier appel (ce qu'exécutait le thread au moment du thread dump), puis on remonte progressivement vers le premier appel (dans le thread principal de l'application, ce sera la méthode main.).

Ensuite comme tu vois "parking to wait for <0xa90a26c0> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)", on t'indique que l'objet de référence <0xa90a26c0> ne peut être utilisé parce que bloqué par un autre thread, et donc que le thread "AWT-EventQueue-0" est mis en attente (entre parenthèse, on indique la classe de l'objet).
Si cette référence était possédé par un autre thread, qui lui aussi serait mis en attente pour obtenir un autre objet qui serait bloqué par AWT-EventQueue, tu serais en état de deadlock.

Ici cet objet est un objet interne de la file d'évènement, et le fait que le thread attende cet objet est probablement dû au fait qu'il n'y a aucun évènement à traiter dans cette file.

Pour chaque ligne de la pile d'appels, tu auras les noms de la classe et de la méthode appelée, et entre parenthèse le nom du fichier et le numéro de ligne, s'il est disponible (en cas de version "exécutable" il faut avec choisi les options adéquates).

Donc si je comprends bien dans le deadlock évoqué ci-dessous :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
 
 
Found one Java-level deadlock:
=============================
"Lecteur MP3":
  waiting to lock monitor 0x8b00b218 (object 0xa934cae8, a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine),
  which is held by "AWT-EventQueue-0"
"AWT-EventQueue-0":
  waiting to lock monitor 0x8b00a534 (object 0x93c39970, a java.lang.Object),
  which is held by "Lecteur MP3"
 
Java stack information for the threads listed above:
===================================================
"Lecteur MP3":
	at org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.write(PulseAudioSourceDataLine.java:183)
	- waiting to lock <0xa934cae8> (a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine)
	- locked <0x93c39970> (a java.lang.Object)
	at memory.lecteur.LecteurMP3.run(LecteurMP3.java:636)
	- locked <0xa921fa98> (a memory.lecteur.javazoom.spi.mpeg.sampled.convert.DecodedMpegAudioInputStream)
	at java.lang.Thread.run(Thread.java:724)
"AWT-EventQueue-0":
	at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.stop(PulseAudioDataLine.java:386)
	- waiting to lock <0x93c39970> (a java.lang.Object)
	- locked <0xa934cae8> (a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine)
	at org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.stop(PulseAudioSourceDataLine.java:51)
	at memory.lecteur.LecteurMP3.pausePlayback(LecteurMP3.java:381)
	at memory.lecteur.LecteurMP3.pause(LecteurMP3.java:841)
	at memory.chants.JLecteurMP3.pauseChant(JLecteurMP3.java:409)
	at memory.chants.JLecteurMP3.actionPerformed(JLecteurMP3.java:336)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)
	at javax.swing.AbstractButton$Handler.actionPerformed(AbstractButton.java:2341)
	at javax.swing.DefaultButtonModel.fireActionPerformed(DefaultButtonModel.java:402)
	at javax.swing.DefaultButtonModel.setPressed(DefaultButtonModel.java:259)
	at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(BasicButtonListener.java:252)
	at java.awt.Component.processMouseEvent(Component.java:6505)
	at javax.swing.JComponent.processMouseEvent(JComponent.java:3312)
	at java.awt.Component.processEvent(Component.java:6270)
	at java.awt.Container.processEvent(Container.java:2229)
	at java.awt.Component.dispatchEventImpl(Component.java:4861)
	at java.awt.Container.dispatchEventImpl(Container.java:2287)
	at java.awt.Component.dispatchEvent(Component.java:4687)
	at java.awt.LightweightDispatcher.retargetMouseEvent(Container.java:4832)
	at java.awt.LightweightDispatcher.processMouseEvent(Container.java:4492)
	at java.awt.LightweightDispatcher.dispatchEvent(Container.java:4422)
	at java.awt.Container.dispatchEventImpl(Container.java:2273)
	at java.awt.Window.dispatchEventImpl(Window.java:2719)
	at java.awt.Component.dispatchEvent(Component.java:4687)
	at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:735)
	at java.awt.EventQueue.access$200(EventQueue.java:103)
	at java.awt.EventQueue$3.run(EventQueue.java:694)
	at java.awt.EventQueue$3.run(EventQueue.java:692)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:87)
	at java.awt.EventQueue$4.run(EventQueue.java:708)
	at java.awt.EventQueue$4.run(EventQueue.java:706)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:705)
	at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)
 
Found 1 deadlock.

Pouvez-vous m'expliquer ce que cela signifie. J'ai du mal à comprendre d'autant qu'il y est fait référence à icedtea dont je n'ai pas les sources ?

20/01/2014, 13h54
joel.drigo

La classe memory.lecteur.LecteurMP3 est bien une classe à toi ?

On voit que l'appel de la méthode stop de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine appelée par ta méthode memory.lecteur.LecteurMP3.pausePlayback() est en deadlock avec l'appel de write de la classe org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLin appelée par run() de ta classe memory.lecteur.LecteurMP3.run(LecteurMP3.java:636).

Les objets sur lesquels on a le synchrinized qui cause le deadlock sont l'instance de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine et une instance d'Object.
20/01/2014, 14h47
hwoarang

Est ce que tu peux poster le code de memory.lecteur.LecteurMP3 qui apparaissent dans les traces ?
En particulier les lignes qui posent probleme et l'initialisation des classes utilisées sur ces lignes ?

Citation:

Envoyé par joel.drigo

La classe memory.lecteur.LecteurMP3 est bien une classe à toi ?

On voit que l'appel de la méthode stop de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine appelée par ta méthode memory.lecteur.LecteurMP3.pausePlayback() est en deadlock avec l'appel de write de la classe org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLin appelée par run() de ta classe memory.lecteur.LecteurMP3.run(LecteurMP3.java:636).

Les objets sur lesquels on a le synchrinized qui cause le deadlock sont l'instance de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine et une instance d'Object.

Oui cette classe est bien à moi. Par contre normalement la méthode run n'appelle pas directement PulseAudioSourceDataLin.
Je te mets les codes concernées avec les variables nécessaires.
Déclaration de la classe

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
 
public class LecteurMP3 implements Runnable
{
	/************** LES CONSTANTES **************************************************************************/
	// le tampon de lecture
	private static int					EXTERNAL_BUFFER_SIZE	= 4000 * 4;
 
	private boolean test = false;
 
	/************** LES ATTRIBUTS ***************************************************************************/
	// la source audio (un Fichier mp3, une url, ou un InputStream
	// ici on utilise essentiellement une url mais la modification pour utiliser
	// des fichiers est minime.
	private File						source;
 
	private URL							url;
 
	private InputStream					inputStream;
 
	// le thread de lecture
	private Thread						thread					= null;
 
	// gestion du flux de lecture (le flux encodé en MP3, IO)
	private AudioInputStream			encodedAudioInputStream;
 
	// la longueur du Fichier en octet
	private int							nbBytes					= -1;
 
	// gestion du flux audio (le flux décodé, AudioSystem)
	private AudioInputStream			audioInputStream;
 
	// les infos sur le format du Fichier
	private AudioFileFormat				audioFileFormat;
 
	// la sortie son (AudioSystem)
	private SourceDataLine				sortieSon;
 
	// le controle de volume
	protected FloatControl				controleVolume;
 
	// l'état du lecteur (au départ inconnu)
	private int							etat					= LecteurEvent.UNKNOWN;
 
	// les écouteurs qui seront informés des changements d'état
	private Collection<LecteurListener>	listeners				= null;
 
	// le nombre d'octets à passer avant de commencer à jouer
	private int							nbByteSkip				= -1;
 
	// la durée du morceau en micro-secondes
	private long						duree					= -1;
 
	//un lecteur de fichier MP3
	private static MpegAudioFileReader	mafr;
.../...

Puis le code de la méthode pausePlayback

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	private void pausePlayback()
	{
		if (this.sortieSon != null)
		{
			if (test) return;
			if (this.etat == LecteurEvent.PLAYING)
			{
				this.sortieSon.flush();
				this.sortieSon.stop();
				this.etat = LecteurEvent.PAUSED;
			}
		}
	}

if (test) return est là uniquement pour raison de débogage.
Comme le déroulement l'indique on purge la sortieSon avant de l'arrêter. On passe l'état du lecteur à pause.

Et le code de run

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
 
	/**
         * la boucle principale déclenchée par l'appel thread.start() de la méthode
         * startPlayback()
         * 
         * Etat == STOPPED => Fin du thread et libérer les ressources audio
         * Etat == PLAYING => Le flux audio est envoyé vers la sortie
         * Etat == PAUSED => Attendre un nouvel état
         */
	public void run()
	{
		// pour pouvoir rentrer dans la boucle, nBytesRead est passé à 1
		int nBytesRead = 1;
		// un tableau de 16000 octets
		byte[] abData = new byte[EXTERNAL_BUFFER_SIZE];
		// bloquer le flux pendant la lecture
		synchronized (this.audioInputStream)
//		synchronized (this.sortieSon)
		{
			// la boucle play/pause
			// tant que le son n'est pas arrêté et qu'il y a des octets lus
			while ((nBytesRead != -1) && (this.etat != LecteurEvent.STOPPED)
					&& (this.etat != LecteurEvent.UNKNOWN))
			{
				// si on est en pause, on ne fait rien mais le thread n'est pas
				// arrêté
				if (this.etat == LecteurEvent.PLAYING)
				{
					// Play.
					try
					{
 
						// On ne saute des octets qu'avant une lecture. Donc
						// quand on veut sauter N octets
						// on place N dans nbBytesSkip et on les saute juste
						// avant de lire la suite.
						if (this.nbByteSkip > 0)
						{
							this.audioInputStream.skip(this.nbByteSkip);
							this.nbByteSkip = 0;
						}
						// read(T[], x, N) avec T[], un tableau d'octet, x et N
						// des entiers.
						// On lit un maximum de N octets qui sont stockés dans
						// le tableau.
						// T[x] stocke le premier octet lu.
						nBytesRead = this.audioInputStream.read(abData, 0,
								abData.length);
						if (nBytesRead >= 0)
						{
							// on écrit les octets sur la sortie son
							this.sortieSon.write(abData, 0, nBytesRead);
							// on informe les listeners
							Iterator<LecteurListener> it = this.listeners
									.iterator();
							while (it.hasNext())
							{
								LecteurListener listener = (LecteurListener) it
										.next();
								if (this.audioInputStream instanceof PropertiesContainer)
								{
									Map<?,?> proprietes = ((PropertiesContainer) this.audioInputStream)
											.properties();
									long x = (Long) proprietes
											.get("mp3.position.microseconds");
									// uniquement pour indiquer la progression
									// du lecteur)
									listener.progress(x);
								}
								else
									throw new LecteurException(
											"impossible d'obtenir la progression de la lecture");
							}
						}
					}
					catch (IOException e)
					{
						// si une exception est levée, on arrête le lecteur
						this.etat = LecteurEvent.STOPPED;
						// et on prévient les listeners
						notifyEvent(LecteurEvent.STOPPED);
						e.printStackTrace();
					}
					catch (LecteurException e)
					{
						e.printStackTrace();
					}
				}
				else
				{
					// Pause, on attend une seconde
					try
					{
						Thread.sleep(1000);
					}
					catch (InterruptedException e)
					{}
				}
			}
 
			// Libérer les ressources car la lecture est finie
			if (this.sortieSon != null)
			{
				this.sortieSon.drain();
				this.sortieSon.stop();
				this.sortieSon.close();
				this.sortieSon = null;
			}
			// Notification of "End Of Media"
			if (nBytesRead == -1)
			{
				closeStream();
				this.etat = LecteurEvent.EOM;
				notifyEvent(LecteurEvent.EOM);
			}
			// fermeture du flux
		}
 
		this.etat = LecteurEvent.STOPPED;
		// informer de l'arrêt
		notifyEvent(LecteurEvent.STOPPED);
	}

Je ne sais pas si cela suffit pour comprendre le problème car ici rien n'appelle directement la méthode stop de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.

20/01/2014, 14h54
Patrice Henrio

Citation:

Envoyé par hwoarang

Est ce que tu peux poster le code de memory.lecteur.LecteurMP3 qui apparaissent dans les traces ?
En particulier les lignes qui posent probleme et l'initialisation des classes utilisées sur ces lignes ?

Est-ce que je viens de poster suffit ? Je peux aussi mettre toute la classe. Ce projet utilise beaucoup le projet javazoom et tritonus. cependant vu les problèmes que j'ai rencontré j'ai récupéré toutes les sources de ces deux projets et garder seulement les classes nécessaires.

Citation:

Envoyé par joel.drigo

La classe memory.lecteur.LecteurMP3 est bien une classe à toi ?

On voit que l'appel de la méthode stop de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine appelée par ta méthode memory.lecteur.LecteurMP3.pausePlayback() est en deadlock avec l'appel de write de la classe org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLin appelée par run() de ta classe memory.lecteur.LecteurMP3.run(LecteurMP3.java:636).

Les objets sur lesquels on a le synchrinized qui cause le deadlock sont l'instance de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine et une instance d'Object.

Où se trouvent les indications qui permettent de comprendre que c'est la méthode stop qui est en cause ? J' avais bien trouvé que c'était la méthode run() et en particulier semble-t'il la ligne : this.sortieSon.write(abData, 0, nBytesRead);
qui posait problème mais je n'avais pas vu le problème de la méthode stop().

Le problème vient probablement de synchronized (this.audioInputStream). Je suppose qu'il s'agit d'une instance de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLin

Citation:

Envoyé par Patrice Henrio

Où se trouvent les indications qui permettent de comprendre que c'est la méthode stop qui est en cause ?

Found one Java-level deadlock:
=============================
"Lecteur MP3":
  waiting to lock monitor 0x8b00b218 (object 0xa934cae8, a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine),
  which is held by "AWT-EventQueue-0"
"AWT-EventQueue-0":
  waiting to lock monitor 0x8b00a534 (object 0x93c39970, a java.lang.Object),
  which is held by "Lecteur MP3"
 
Java stack information for the threads listed above:
===================================================
"Lecteur MP3":
	at org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.write(PulseAudioSourceDataLine.java:183)
	- waiting to lock <0xa934cae8> (a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine)
	- locked <0x93c39970> (a java.lang.Object)
	at memory.lecteur.LecteurMP3.run(LecteurMP3.java:636)
	- locked <0xa921fa98> (a memory.lecteur.javazoom.spi.mpeg.sampled.convert.DecodedMpegAudioInputStream)
	at java.lang.Thread.run(Thread.java:724)
"AWT-EventQueue-0":
	at org.classpath.icedtea.pulseaudio.PulseAudioDataLine.stop(PulseAudioDataLine.java:386)
	- waiting to lock <0x93c39970> (a java.lang.Object)
	- locked <0xa934cae8> (a org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine)
	at org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLine.stop(PulseAudioSourceDataLine.java:51)
	at memory.lecteur.LecteurMP3.pausePlayback(LecteurMP3.java:381)
	at memory.lecteur.LecteurMP3.pause(LecteurMP3.java:841)
	at memory.chants.JLecteurMP3.pauseChant(JLecteurMP3.java:409)
	at memory.chants.JLecteurMP3.actionPerformed(JLecteurMP3.java:336)
	at javax.swing.AbstractButton.fireActionPerformed(AbstractButton.java:2018)

...

Found 1 deadlock.

Ce n'est pas les méthode stop() ou write() qui sont en cause, ce sont tes méthodes pausePlayback() et run() qui le sont, dans la manière d'appeler les méthodes de PulseAudioSourceDataLine et synchroniser sur l'instance de cette classe.

20/01/2014, 15h17
hwoarang

Et "sortieSon" ? Il est initialisé comment ?

Pour préciser, meme si on ne peut pas écarter un bug du jdk, il est plus probable que tu appelles des fonctions dans un ordre ou de maniere non prévue (par exemple dans un thread particulier ou bien dans un mauvais état).

Citation:

Envoyé par hwoarang

Et "sortieSon" ? Il est initialisé comment ?

Pour préciser, meme si on ne peut pas écarter un bug du jdk, il est plus probable que tu appelles des fonctions dans un ordre ou de maniere non prévue (par exemple dans un thread particulier ou bien dans un mauvais état).

Voici l'initialisation de la sortie son

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
 
	/**
         * Créer la sortie son
         * @throws LineUnavailableException les erreurs sur la sortie son
         */
	private void createLine() throws LineUnavailableException
	{
		if (this.sortieSon == null)
		{
			// récupérer le format de la source
			AudioFormat sourceFormat = this.audioInputStream.getFormat();
 
			// pour les fichiers MP3 choisis nSampleSizeInBits = 16;
			AudioFormat targetFormat = new AudioFormat(
					AudioFormat.Encoding.PCM_SIGNED,
					sourceFormat.getSampleRate(), 16,
					sourceFormat.getChannels(),
					2 * sourceFormat.getChannels(),
					sourceFormat.getSampleRate(), false);
			// garder une référence sur le flux audio pour la progression de la
			// lecture
			// encodedAudioInputStream est le format encodé de départ (IO)
			// audioInputStream sera le format décodé (système audio)
			this.encodedAudioInputStream = this.audioInputStream;
			// Créer le flux décodé
			// this.audioInputStream =
			// AudioSystem.getAudioInputStream(targetFormat,
			// this.audioInputStream);
			MpegFormatConversionProvider mfcp = new MpegFormatConversionProvider();
			this.audioInputStream = mfcp.getAudioInputStream(targetFormat,
					this.audioInputStream);
 
			// this.audioInputStream = getAudioInputStream();
			//
			// if (this.url != null) initAudioInputStream(url);
			// else if (this.source != null) initAudioInputStream(this.source);
			// else if (this.inputStream != null)
			// initAudioInputStream(inputStream);
			//
			// this.audioInputStream = lecteur.getAudioInputStream(targetFormat,
			// this.audioInputStream);
			// récupérer le format décodé
			AudioFormat audioFormat = this.audioInputStream.getFormat();
			// Informer la sortie son
			DataLine.Info info = new DataLine.Info(SourceDataLine.class,
					audioFormat, AudioSystem.NOT_SPECIFIED);
			this.sortieSon = (SourceDataLine) AudioSystem.getLine(info);
		}
	}

avec la déclaration de la sortieSon

Code:

1
2
3
 
// la sortie son (AudioSystem)
	private SourceDataLine				sortieSon;

Sous sunJDK SourceDataLine renvoie à
public interface SourceDataLine extends DataLine du package package javax.sound.sampled;

Par contre sous openJDK il ne trouve pas la source (je n'ai pas réussi à localiser les sources ni de icedtea ni de openJDK ... ce qui est quand même un comble pour un paquetage qui n'existe que parce que sunJDK est considéré comme non libre).

20/01/2014, 16h54
Patrice Henrio

Citation:

Envoyé par joel.drigo

Le problème vient probablement de synchronized (this.audioInputStream). Je suppose qu'il s'agit d'une instance de org.classpath.icedtea.pulseaudio.PulseAudioSourceDataLin

Ce n'est pas les méthode stop() ou write() qui sont en cause, ce sont tes méthodes pausePlayback() et run() qui le sont, dans la manière d'appeler les méthodes de PulseAudioSourceDataLine et synchroniser sur l'instance de cette classe.

pour sunJDK
audioInputStream est une instance de
public class AudioInputStream extends InputStream
du package package javax.sound.sampled;

pareil pour openJDK sauf que je n'ai pas accès aux sources ... comme expliqué précédemment.
20/01/2014, 18h01
Patrice Henrio

J'ai fini par trouver où se cachaient les sources de openJDK. Je vais pouvoir aller plus loin dans ma recherche.

Comme on me l'a signalé, le problème vient surement de l'ordre de déclenchement des méthodes et aussi d'un problème se synchronized.

J'ai un attribut de la classe LecteurMP3 qui est un Thread

Code:

private Thread thread = null;

Lorsque je démarre un chant, si le lecteur est à l'arrêt je réinitialise le flux audio d'entrée.
Ensuite je vérifie que le lecteur est en lecture.
Code:

1 2 3 4 5 6 7 8 9 private void startPlayback() throws LecteurException { if (this.etat == LecteurEvent.STOPPED) initAudioInputStream(); if (this.etat == LecteurEvent.OPENED) { .../... } }
Ensuite je regarde si le thread est "vivant"
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 // ATTENTION : le thread précédent est peut-être encore en lecture if ((this.thread != null) && (this.thread.isAlive())) { int cnt = 0; while (this.etat != LecteurEvent.OPENED) { try { if (this.thread != null) { cnt++; Thread.sleep(1000); if (cnt > 2) this.thread.interrupt(); } } catch (InterruptedException e) { throw new LecteurException(LecteurException.WAITERROR,e); } } }
Une fois que je suis sûr que le thread a fini de travailler, j'initialise la ligne son, le thread
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 try { initLine(); } catch (LineUnavailableException e) { throw new LecteurException(LecteurException.CANNOTINITLINE, e); } this.thread = new Thread(this, "Lecteur MP3"); this.thread.start(); if (this.sortieSon != null) { this.sortieSon.start(); this.etat = LecteurEvent.PLAYING; }
J'ai l'impression que je ne fais ce qu'il faut déjà dans cette méthode. la ligne

Code:

this.thread = new Thread(this, "Lecteur MP3");

est-elle nécessaire ?

21/01/2014, 23h49
Patrice Henrio

Bon j'ai trouvé comment contourner le problème (mais pas pourquoi le problème existe sous OpenJDK et pas sous SunJDK).
Pour utiliser l'audio sous Java il faut recueillir les fournisseurs de tables de mixage de la machine java installée. La méthode qui permet de les récupérer est la même il s'agit de
AudioSystem.getMixerProviders()

Sous OpenJDK cette méthode getMixerProviders() renvoie
org.classpath.icedtea.pulseaudio.PulseAudioMixerProvider
com.sun.media.sound.DirectAudioDeviceProvider
com.sun.media.sound.PortMixerProvider

Sous SunJDK cette même méthode renvoie
com.sun.media.sound.DirectAudioDeviceProvider
com.sun.media.sound.PortMixerProvide

Comme on renvoie le premier fournisseur de table de mixage adapté, sous OpenJDK on récupère PulseAudioMixerProvider qui semble ne pas gérer de la même façon que le suivant les sources MP3.
Il suffit de créer une version perso de AudioSystem.