[alsa-devel] usb midi disconnect -> kernel oops
Hi!
If I have a running application which connects (via alsa seq) to usb midi device, and device is disconnected, I get a kernel oops.
kernels tried: 2.6.20-rt8 (in-kernel alsa), 2.6.21-rc5-rt3 (in-kernel alsa, and 1.0.14_rc3)
Kernel dump attached.
Dmitry.
On 4/1/07, Dmitry Baikov dsbaikov@gmail.com wrote:
Kernel dump attached.
I think you forgot the attachment.
Lee
On 4/2/07, Takashi Iwai tiwai@suse.de wrote:
Still can't see... Could you just paste it?
[ 83.527000] usb 2-2: new full speed USB device using uhci_hcd and address 2 [ 83.702000] usb 2-2: configuration #1 chosen from 1 choice [ 83.920000] usbcore: registered new interface driver snd-usb-audio [ 87.020000] usb 2-2: USB disconnect, address 2 [ 91.526000] usb 2-2: new full speed USB device using uhci_hcd and address 3 [ 91.701000] usb 2-2: configuration #1 chosen from 1 choice [ 95.769000] usb 2-2: USB disconnect, address 3 [ 100.507000] usb 2-2: new full speed USB device using uhci_hcd and address 4 [ 100.682000] usb 2-2: configuration #1 chosen from 1 choice [ 104.000000] usb 2-2: USB disconnect, address 4 [ 111.814000] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 140.886000] usb 2-2: new full speed USB device using uhci_hcd and address 5 [ 141.061000] usb 2-2: configuration #1 chosen from 1 choice [ 146.001000] synaptics: using relaxed packet validation [ 151.879000] usb 2-2: USB disconnect, address 5 [ 152.083000] BUG: unable to handle kernel paging request at virtual address 00100104 [ 152.083000] printing eip: [ 152.083000] f8997b00 [ 152.083000] *pde = 3d5f2067 [ 152.083000] stopped custom tracer. [ 152.083000] Oops: 0002 [#1] [ 152.083000] PREEMPT [ 152.083000] Modules linked in: snd_rtctimer snd_seq_midi snd_seq_midi_event i915 snd_usb_audio snd_usb_lib snd_rawmidi snd_hwdep snd_seq snd_seq_device ecb ieee80211_crypt_wep ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc [ 152.083000] CPU: 0 [ 152.083000] EIP: 0060:[<f8997b00>] Not tainted VLI [ 152.083000] EFLAGS: 00010246 (2.6.21-rc5-rt3 #2) [ 152.083000] EIP is at clear_subscriber_list+0xc7/0x11c [snd_seq] [ 152.083000] eax: 00200200 ebx: f74bf878 ecx: f33c0610 edx: 00100100 [ 152.083000] esi: f33c05c0 edi: f74bf800 ebp: f74bf868 esp: c195dc5c [ 152.083000] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 preempt:00000001 [ 152.083000] Process khubd (pid: 177, ti=c195c000 task=c19c3550 task.ti=c195c000) [ 152.083000] Stack: f33c05c0 00000000 f76758b4 f7675800 f7721ec0 f76758b4 f77a56c0 f7721ec0 [ 152.083000] f7675800 c195de0c f33c0dc0 f8997b8a 00000001 f7721ec0 ffffffff f89939c0 [ 152.083000] 00000118 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 152.083000] Call Trace: [ 152.083000] [<f8997b8a>] port_delete+0x35/0x54 [snd_seq] [ 152.083000] [<f89939c0>] snd_seq_ioctl_delete_port+0x38/0x5b [snd_seq] [ 152.083000] [<f899316b>] snd_seq_do_ioctl+0x5a/0x64 [snd_seq] [ 152.083000] [<f89931a9>] snd_seq_kernel_client_ctl+0x2c/0x44 [snd_seq] [ 152.083000] [<f89976be>] snd_seq_event_port_detach+0x39/0x43 [snd_seq] [ 152.083000] [<f89d2016>] snd_seq_midisynth_delete+0x16/0x25 [snd_seq_midi] [ 152.083000] [<f89d208f>] snd_seq_midisynth_unregister_port+0x6a/0xb7 [snd_seq_midi] [ 152.083000] [<f88da073>] free_device+0x65/0xb6 [snd_seq_device] [ 152.083000] [<f88da3ee>] snd_seq_device_dev_disconnect+0x23/0x2f [snd_seq_device] [ 152.083000] [<f88d2bec>] snd_device_disconnect+0x28/0x72 [snd] [ 152.083000] [<f88d2e6c>] snd_device_disconnect_all+0x19/0x3d [snd] [ 152.083000] [<f88cfd56>] snd_card_disconnect+0xf2/0x127 [snd] [ 152.083000] [<f89bf67a>] usb_audio_disconnect+0x44/0xea [snd_usb_audio] [ 152.083000] [<c02fc3dc>] usb_unbind_interface+0x2d/0x5f [ 152.083000] [<c029eb94>] __device_release_driver+0x71/0x8e [ 152.083000] [<c029ec61>] device_release_driver+0x18/0x21 [ 152.083000] [<c029e769>] bus_remove_device+0x61/0x6f [ 152.083000] [<c029d1eb>] device_del+0x10f/0x171 [ 152.083000] [<c02fa29c>] usb_disable_device+0x5c/0xbb [ 152.083000] [<c02f7287>] usb_disconnect+0x7a/0xed [ 152.083000] [<c02f7d3a>] hub_thread+0x312/0x9e7 [ 152.083000] [<c012ca66>] kthread+0xa0/0xca [ 152.083000] [<c01048bf>] kernel_thread_helper+0x7/0x10 [ 152.083000] ======================= [ 152.083000] Code: 58 8b 56 58 8b 41 04 89 42 04 89 10 c7 46 58 00 01 10 00 eb 22 8d 6f 68 8d 5f 78 89 d8 e8 f0 ec 79 c7 8d 4e 50 8b 56 50 8b 41 04 <89> 42 04 89 10 c7 46 50 00 01 10 00 c7 41 04 00 02 20 00 89 d8 [ 152.083000] EIP: [<f8997b00>] clear_subscriber_list+0xc7/0x11c [snd_seq] SS:ESP 0068:c195dc5c
At Mon, 2 Apr 2007 15:41:07 +0400, Dmitry Baikov wrote:
On 4/2/07, Takashi Iwai tiwai@suse.de wrote:
Still can't see... Could you just paste it?
[ 83.527000] usb 2-2: new full speed USB device using uhci_hcd and address 2 [ 83.702000] usb 2-2: configuration #1 chosen from 1 choice [ 83.920000] usbcore: registered new interface driver snd-usb-audio [ 87.020000] usb 2-2: USB disconnect, address 2 [ 91.526000] usb 2-2: new full speed USB device using uhci_hcd and address 3 [ 91.701000] usb 2-2: configuration #1 chosen from 1 choice [ 95.769000] usb 2-2: USB disconnect, address 3 [ 100.507000] usb 2-2: new full speed USB device using uhci_hcd and address 4 [ 100.682000] usb 2-2: configuration #1 chosen from 1 choice [ 104.000000] usb 2-2: USB disconnect, address 4 [ 111.814000] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 140.886000] usb 2-2: new full speed USB device using uhci_hcd and address 5 [ 141.061000] usb 2-2: configuration #1 chosen from 1 choice [ 146.001000] synaptics: using relaxed packet validation [ 151.879000] usb 2-2: USB disconnect, address 5 [ 152.083000] BUG: unable to handle kernel paging request at virtual address 00100104 [ 152.083000] printing eip: [ 152.083000] f8997b00 [ 152.083000] *pde = 3d5f2067 [ 152.083000] stopped custom tracer. [ 152.083000] Oops: 0002 [#1] [ 152.083000] PREEMPT [ 152.083000] Modules linked in: snd_rtctimer snd_seq_midi snd_seq_midi_event i915 snd_usb_audio snd_usb_lib snd_rawmidi snd_hwdep snd_seq snd_seq_device ecb ieee80211_crypt_wep ipw2200 ieee80211 ieee80211_crypt snd_hda_intel snd_hda_codec snd_pcm snd_timer snd soundcore snd_page_alloc [ 152.083000] CPU: 0 [ 152.083000] EIP: 0060:[<f8997b00>] Not tainted VLI [ 152.083000] EFLAGS: 00010246 (2.6.21-rc5-rt3 #2) [ 152.083000] EIP is at clear_subscriber_list+0xc7/0x11c [snd_seq] [ 152.083000] eax: 00200200 ebx: f74bf878 ecx: f33c0610 edx: 00100100 [ 152.083000] esi: f33c05c0 edi: f74bf800 ebp: f74bf868 esp: c195dc5c [ 152.083000] ds: 007b es: 007b fs: 00d8 gs: 0000 ss: 0068 preempt:00000001 [ 152.083000] Process khubd (pid: 177, ti=c195c000 task=c19c3550 task.ti=c195c000) [ 152.083000] Stack: f33c05c0 00000000 f76758b4 f7675800 f7721ec0 f76758b4 f77a56c0 f7721ec0 [ 152.083000] f7675800 c195de0c f33c0dc0 f8997b8a 00000001 f7721ec0 ffffffff f89939c0 [ 152.083000] 00000118 00000000 00000000 00000000 00000000 00000000 00000000 00000000 [ 152.083000] Call Trace: [ 152.083000] [<f8997b8a>] port_delete+0x35/0x54 [snd_seq] [ 152.083000] [<f89939c0>] snd_seq_ioctl_delete_port+0x38/0x5b [snd_seq] [ 152.083000] [<f899316b>] snd_seq_do_ioctl+0x5a/0x64 [snd_seq] [ 152.083000] [<f89931a9>] snd_seq_kernel_client_ctl+0x2c/0x44 [snd_seq] [ 152.083000] [<f89976be>] snd_seq_event_port_detach+0x39/0x43 [snd_seq] [ 152.083000] [<f89d2016>] snd_seq_midisynth_delete+0x16/0x25 [snd_seq_midi] [ 152.083000] [<f89d208f>] snd_seq_midisynth_unregister_port+0x6a/0xb7 [snd_seq_midi] [ 152.083000] [<f88da073>] free_device+0x65/0xb6 [snd_seq_device] [ 152.083000] [<f88da3ee>] snd_seq_device_dev_disconnect+0x23/0x2f [snd_seq_device] [ 152.083000] [<f88d2bec>] snd_device_disconnect+0x28/0x72 [snd] [ 152.083000] [<f88d2e6c>] snd_device_disconnect_all+0x19/0x3d [snd] [ 152.083000] [<f88cfd56>] snd_card_disconnect+0xf2/0x127 [snd] [ 152.083000] [<f89bf67a>] usb_audio_disconnect+0x44/0xea [snd_usb_audio] [ 152.083000] [<c02fc3dc>] usb_unbind_interface+0x2d/0x5f [ 152.083000] [<c029eb94>] __device_release_driver+0x71/0x8e [ 152.083000] [<c029ec61>] device_release_driver+0x18/0x21 [ 152.083000] [<c029e769>] bus_remove_device+0x61/0x6f [ 152.083000] [<c029d1eb>] device_del+0x10f/0x171 [ 152.083000] [<c02fa29c>] usb_disable_device+0x5c/0xbb [ 152.083000] [<c02f7287>] usb_disconnect+0x7a/0xed [ 152.083000] [<c02f7d3a>] hub_thread+0x312/0x9e7 [ 152.083000] [<c012ca66>] kthread+0xa0/0xca [ 152.083000] [<c01048bf>] kernel_thread_helper+0x7/0x10 [ 152.083000] ======================= [ 152.083000] Code: 58 8b 56 58 8b 41 04 89 42 04 89 10 c7 46 58 00 01 10 00 eb 22 8d 6f 68 8d 5f 78 89 d8 e8 f0 ec 79 c7 8d 4e 50 8b 56 50 8b 41 04 <89> 42 04 89 10 c7 46 50 00 01 10 00 c7 41 04 00 02 20 00 89 d8 [ 152.083000] EIP: [<f8997b00>] clear_subscriber_list+0xc7/0x11c [snd_seq] SS:ESP 0068:c195dc5c
Thanks. I still don't get exactly where it happened. Could you run "objdump -Dl snd-seq.ko" and check the code around clear_subscriber_list match with the machine code above?
Takashi
On 4/2/07, Takashi Iwai tiwai@suse.de wrote:
[ 152.083000] Code: 58 8b 56 58 8b 41 04 89 42 04 89 10 c7 46 58 00 01 10 00 eb 22 8d 6f 68 8d 5f 78 89 d8 e8 f0 ec 79 c7 8d 4e 50 8b 56 50 8b 41 04 <89> 42 04 89 10 c7 46 50 00 01 10 00 c7 41 04 00 02 20 00 89 d8 [ 152.083000] EIP: [<f8997b00>] clear_subscriber_list+0xc7/0x11c [snd_seq] SS:ESP 0068:c195dc5c
Thanks. I still don't get exactly where it happened. Could you run "objdump -Dl snd-seq.ko" and check the code around clear_subscriber_list match with the machine code above?
It is the middle of instruction at 4ad3, how can we get there? Possibly, something added 2 to return address, instead of auto variable.
4aa0: e8 89 fd ff ff call 482e <unsubscribe_port> 4aa5: 85 ff test %edi,%edi 4aa7: 75 10 jne 4ab9 <clear_subscriber_list+0x80> 4aa9: ff 4e 60 decl 0x60(%esi) 4aac: 0f 94 c0 sete %al 4aaf: 84 c0 test %al,%al 4ab1: 0f 84 82 00 00 00 je 4b39 <clear_subscriber_list+0x100> 4ab7: eb 79 jmp 4b32 <clear_subscriber_list+0xf9> 4ab9: 83 7c 24 30 00 cmpl $0x0,0x30(%esp) 4abe: 75 2a jne 4aea <clear_subscriber_list+0xb1> 4ac0: 8d af b4 00 00 00 lea 0xb4(%edi),%ebp 4ac6: 8d 9f c4 00 00 00 lea 0xc4(%edi),%ebx 4acc: 89 d8 mov %ebx,%eax 4ace: e8 fc ff ff ff call 4acf <clear_subscriber_list+0x96> 4ad3: 8d 4e 58 lea 0x58(%esi),%ecx 4ad6: 8b 56 58 mov 0x58(%esi),%edx 4ad9: 8b 41 04 mov 0x4(%ecx),%eax 4adc: 89 42 04 mov %eax,0x4(%edx) 4adf: 89 10 mov %edx,(%eax) 4ae1: c7 46 58 00 01 10 00 movl $0x100100,0x58(%esi) 4ae8: eb 22 jmp 4b0c <clear_subscriber_list+0xd3> 4aea: 8d 6f 68 lea 0x68(%edi),%ebp 4aed: 8d 5f 78 lea 0x78(%edi),%ebx 4af0: 89 d8 mov %ebx,%eax 4af2: e8 fc ff ff ff call 4af3 <clear_subscriber_list+0xba>
At Tue, 3 Apr 2007 00:03:31 +0400, Dmitry Baikov wrote:
On 4/2/07, Takashi Iwai tiwai@suse.de wrote:
[ 152.083000] Code: 58 8b 56 58 8b 41 04 89 42 04 89 10 c7 46 58 00 01 10 00 eb 22 8d 6f 68 8d 5f 78 89 d8 e8 f0 ec 79 c7 8d 4e 50 8b 56 50 8b 41 04 <89> 42 04 89 10 c7 46 50 00 01 10 00 c7 41 04 00 02 20 00 89 d8 [ 152.083000] EIP: [<f8997b00>] clear_subscriber_list+0xc7/0x11c [snd_seq] SS:ESP 0068:c195dc5c
Thanks. I still don't get exactly where it happened. Could you run "objdump -Dl snd-seq.ko" and check the code around clear_subscriber_list match with the machine code above?
It is the middle of instruction at 4ad3, how can we get there?
I guess you're looking at a different place. As you can find the place matching with "89" (marked in the middle) somewhere in clear_subscriber_list(). Check the byte matter matching with disassembler code. Also, you can get source code lines via -l option of objdump, which helps pretty much.
Takashi
Possibly, something added 2 to return address, instead of auto variable.
4aa0: e8 89 fd ff ff call 482e <unsubscribe_port> 4aa5: 85 ff test %edi,%edi 4aa7: 75 10 jne 4ab9 <clear_subscriber_list+0x80> 4aa9: ff 4e 60 decl 0x60(%esi) 4aac: 0f 94 c0 sete %al 4aaf: 84 c0 test %al,%al 4ab1: 0f 84 82 00 00 00 je 4b39<clear_subscriber_list+0x100> 4ab7: eb 79 jmp 4b32 <clear_subscriber_list+0xf9> 4ab9: 83 7c 24 30 00 cmpl $0x0,0x30(%esp) 4abe: 75 2a jne 4aea <clear_subscriber_list+0xb1> 4ac0: 8d af b4 00 00 00 lea 0xb4(%edi),%ebp 4ac6: 8d 9f c4 00 00 00 lea 0xc4(%edi),%ebx 4acc: 89 d8 mov %ebx,%eax 4ace: e8 fc ff ff ff call 4acf <clear_subscriber_list+0x96> 4ad3: 8d 4e 58 lea 0x58(%esi),%ecx 4ad6: 8b 56 58 mov 0x58(%esi),%edx 4ad9: 8b 41 04 mov 0x4(%ecx),%eax 4adc: 89 42 04 mov %eax,0x4(%edx) 4adf: 89 10 mov %edx,(%eax) 4ae1: c7 46 58 00 01 10 00 movl $0x100100,0x58(%esi) 4ae8: eb 22 jmp 4b0c <clear_subscriber_list+0xd3> 4aea: 8d 6f 68 lea 0x68(%edi),%ebp 4aed: 8d 5f 78 lea 0x78(%edi),%ebx 4af0: 89 d8 mov %ebx,%eax 4af2: e8 fc ff ff ff call 4af3 <clear_subscriber_list+0xba>
On 4/3/07, Takashi Iwai tiwai@suse.de wrote:
I guess you're looking at a different place. As you can find the place matching with "89" (marked in the middle) somewhere in clear_subscriber_list(). Check the byte matter matching with disassembler code. Also, you can get source code lines via -l option of objdump, which helps pretty much.
Got it :) Kernel dumps the code around the faulty address, not from. That's explains that "middle of instruction".
I found why I never had this behaviour before: I changed port creation code from snd_seq_create_simple_port to create_port and incorrectly used return value (0) as a port number. And I had port 0 before. So, then I subscribed and later deleted this port several times.
As for objdump, -l option did not give anything (seems, I had stripped debug info). And now with debug alsa build, I cannot reproduce the bug.
old results of objdump: (Faulty address is 4ad9)
4aa0: e8 89 fd ff ff call 482e <unsubscribe_port> 4aa5: 85 ff test %edi,%edi 4aa7: 75 10 jne 4ab9 <clear_subscriber_list+0x80> 4aa9: ff 4e 60 decl 0x60(%esi) 4aac: 0f 94 c0 sete %al 4aaf: 84 c0 test %al,%al 4ab1: 0f 84 82 00 00 00 je 4b39 <clear_subscriber_list+0x100> 4ab7: eb 79 jmp 4b32 <clear_subscriber_list+0xf9> 4ab9: 83 7c 24 30 00 cmpl $0x0,0x30(%esp) 4abe: 75 2a jne 4aea <clear_subscriber_list+0xb1> 4ac0: 8d af b4 00 00 00 lea 0xb4(%edi),%ebp 4ac6: 8d 9f c4 00 00 00 lea 0xc4(%edi),%ebx 4acc: 89 d8 mov %ebx,%eax 4ace: e8 fc ff ff ff call 4acf <clear_subscriber_list+0x96> 4ad3: 8d 4e 58 lea 0x58(%esi),%ecx 4ad6: 8b 56 58 mov 0x58(%esi),%edx 4ad9: 8b 41 04 mov 0x4(%ecx),%eax 4adc: 89 42 04 mov %eax,0x4(%edx) 4adf: 89 10 mov %edx,(%eax) 4ae1: c7 46 58 00 01 10 00 movl $0x100100,0x58(%esi) 4ae8: eb 22 jmp 4b0c <clear_subscriber_list+0xd3> 4aea: 8d 6f 68 lea 0x68(%edi),%ebp 4aed: 8d 5f 78 lea 0x78(%edi),%ebx 4af0: 89 d8 mov %ebx,%eax 4af2: e8 fc ff ff ff call 4af3 <clear_subscriber_list+0xba> 4af7: 8d 4e 50 lea 0x50(%esi),%ecx 4afa: 8b 56 50 mov 0x50(%esi),%edx 4afd: 8b 41 04 mov 0x4(%ecx),%eax 4b00: 89 42 04 mov %eax,0x4(%edx) 4b03: 89 10 mov %edx,(%eax) 4b05: c7 46 50 00 01 10 00 movl $0x100100,0x50(%esi) 4b0c: c7 41 04 00 02 20 00 movl $0x200200,0x4(%ecx) 4b13: 89 d8 mov %ebx,%eax 4b15: e8 fc ff ff ff call 4b16 <clear_subscriber_list+0xdd>
At Tue, 3 Apr 2007 21:05:06 +0400, Dmitry Baikov wrote:
On 4/3/07, Takashi Iwai tiwai@suse.de wrote:
I guess you're looking at a different place. As you can find the place matching with "89" (marked in the middle) somewhere in clear_subscriber_list(). Check the byte matter matching with disassembler code. Also, you can get source code lines via -l option of objdump, which helps pretty much.
Got it :) Kernel dumps the code around the faulty address, not from. That's explains that "middle of instruction".
I found why I never had this behaviour before: I changed port creation code from snd_seq_create_simple_port to create_port and incorrectly used return value (0) as a port number. And I had port 0 before. So, then I subscribed and later deleted this port several times.
So this bug doesn't happen with the non-modified code, or does it?
As for objdump, -l option did not give anything (seems, I had stripped debug info). And now with debug alsa build, I cannot reproduce the bug.
Oh yeah, it makes our lives harder ;)
Takashi
old results of objdump: (Faulty address is 4ad9)
4aa0: e8 89 fd ff ff call 482e <unsubscribe_port> 4aa5: 85 ff test %edi,%edi 4aa7: 75 10 jne 4ab9 <clear_subscriber_list+0x80> 4aa9: ff 4e 60 decl 0x60(%esi) 4aac: 0f 94 c0 sete %al 4aaf: 84 c0 test %al,%al 4ab1: 0f 84 82 00 00 00 je 4b39<clear_subscriber_list+0x100> 4ab7: eb 79 jmp 4b32 <clear_subscriber_list+0xf9> 4ab9: 83 7c 24 30 00 cmpl $0x0,0x30(%esp) 4abe: 75 2a jne 4aea <clear_subscriber_list+0xb1> 4ac0: 8d af b4 00 00 00 lea 0xb4(%edi),%ebp 4ac6: 8d 9f c4 00 00 00 lea 0xc4(%edi),%ebx 4acc: 89 d8 mov %ebx,%eax 4ace: e8 fc ff ff ff call 4acf <clear_subscriber_list+0x96> 4ad3: 8d 4e 58 lea 0x58(%esi),%ecx 4ad6: 8b 56 58 mov 0x58(%esi),%edx 4ad9: 8b 41 04 mov 0x4(%ecx),%eax 4adc: 89 42 04 mov %eax,0x4(%edx) 4adf: 89 10 mov %edx,(%eax) 4ae1: c7 46 58 00 01 10 00 movl $0x100100,0x58(%esi) 4ae8: eb 22 jmp 4b0c <clear_subscriber_list+0xd3> 4aea: 8d 6f 68 lea 0x68(%edi),%ebp 4aed: 8d 5f 78 lea 0x78(%edi),%ebx 4af0: 89 d8 mov %ebx,%eax 4af2: e8 fc ff ff ff call 4af3 <clear_subscriber_list+0xba> 4af7: 8d 4e 50 lea 0x50(%esi),%ecx 4afa: 8b 56 50 mov 0x50(%esi),%edx 4afd: 8b 41 04 mov 0x4(%ecx),%eax 4b00: 89 42 04 mov %eax,0x4(%edx) 4b03: 89 10 mov %edx,(%eax) 4b05: c7 46 50 00 01 10 00 movl $0x100100,0x50(%esi) 4b0c: c7 41 04 00 02 20 00 movl $0x200200,0x4(%ecx) 4b13: 89 d8 mov %ebx,%eax 4b15: e8 fc ff ff ff call 4b16 <clear_subscriber_list+0xdd>
On 4/4/07, Takashi Iwai tiwai@suse.de wrote:
So this bug doesn't happen with the non-modified code, or does it?
This bug never happened with the correct code, only with buggy one, which subscribed and deleted the same port several times.
Dmitry.
At Wed, 4 Apr 2007 19:08:17 +0400, Dmitry Baikov wrote:
On 4/4/07, Takashi Iwai tiwai@suse.de wrote:
So this bug doesn't happen with the non-modified code, or does it?
This bug never happened with the correct code, only with buggy one, which subscribed and deleted the same port several times.
Do you mean the bug can be triggered even with the upstream HG code, when user-space apps do subscribe and delete the same port several times? I still don't get the exact conditions how to reproduce your bug...
Takashi
participants (3)
-
Dmitry Baikov -
Lee Revell -
Takashi Iwai