Re: [pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively
'Twas brillig, and Daniel Mack at 31/03/11 18:16 did gyre and gimble: Could you try to run multiple instances of the test binary at the same time? Yeah, I should be able to get around to this on Sunday... doubt I will manage before then sadly. Does anyone else have any idea about the startup backtrace Daniel has... this is obviously rather worrying... (just out of curiosity, I presume there is no chance you're accidentally using your system PA's modules or similar wierdness? (especially libpulsecommon.so which is unversioned - perhaps stracing will help double check). There may be some titbits of info here, tho' it's a little out of date now: http://colin.guthr.ie/2010/09/compiling-and-running-pulseaudio-from-git/ Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively
On Fri, Apr 1, 2011 at 1:02 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Daniel Mack at 31/03/11 18:16 did gyre and gimble: Could you try to run multiple instances of the test binary at the same time? Yeah, I should be able to get around to this on Sunday... doubt I will manage before then sadly. Does anyone else have any idea about the startup backtrace Daniel has... this is obviously rather worrying... (just out of curiosity, I presume there is no chance you're accidentally using your system PA's modules or similar wierdness? (especially libpulsecommon.so which is unversioned - perhaps stracing will help double check). No, this is certainly not the reason. On OS X, there is no PulseAudio preinstalled of course, and on Linux, I called libtool --mode exec gdb pulseaudio to make sure the correct libs are used at runtime. Despite the fact that the daemon shouldn't crash regardless what the client throws at it, I wonder whether my example test is actually valid. Does it do anything bogus? Daniel ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 5/5] bluetooth: Refuse to use the HSP profile if there is some other HSP device active.
On Thu, 2011-03-31 at 15:30 +0300, Tanu Kaskinen wrote: On Thu, 2011-03-31 at 15:11 +0300, Tanu Kaskinen wrote: If no volunteers pop up, I guess I'll have to get a bluetooth dongle for my desktop so that I can test this myself. Never mind, I found a dongle already - I'll test it tomorrow. Ok, tests are now done. I couldn't get any audio in the HSP mode (A2DP worked fine). The sink seemed to be running and there were no errors, the problem seemed to be just that the sink was not getting any wakeups from the hardware. Before any BT hardware was connected, module-bluetooth-discover printed some errors at startup, but apart from this no-audio-with-hsp problem the errors didn't seem to cause any trouble. The behavior was identical with the current git master and with my patches applied. Even though I got no audio, looking at pulseaudio logs it seemed like sink_set_volume_cb was working alright, which was the only thing I wanted to test anyway. So, I suggest now that patches 1-4 get merged, along with the bluetooth: Fix HSP volume handling patch. -- Tanu ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively
'Twas brillig, and Daniel Mack at 01/04/11 12:56 did gyre and gimble: On Fri, Apr 1, 2011 at 1:02 PM, Colin Guthrie gm...@colin.guthr.ie wrote: 'Twas brillig, and Daniel Mack at 31/03/11 18:16 did gyre and gimble: Could you try to run multiple instances of the test binary at the same time? Yeah, I should be able to get around to this on Sunday... doubt I will manage before then sadly. Does anyone else have any idea about the startup backtrace Daniel has... this is obviously rather worrying... (just out of curiosity, I presume there is no chance you're accidentally using your system PA's modules or similar wierdness? (especially libpulsecommon.so which is unversioned - perhaps stracing will help double check). No, this is certainly not the reason. On OS X, there is no PulseAudio preinstalled of course, and on Linux, I called libtool --mode exec gdb pulseaudio to make sure the correct libs are used at runtime. Despite the fact that the daemon shouldn't crash regardless what the client throws at it, I wonder whether my example test is actually valid. Does it do anything bogus? Oh jeez... I just realised I misread on of your mails (it was a long day, I was tired better excuse goes here). I thought you were saying your daemon crashed on *startup* on linux... before your test was run :s Sorry if my replies were a little odd due to that! Will take a look at your test to see if I can reproduce here, but as I said before, it may not be until Sunday... hopefully some of the others can chime in. Cheers Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] [PATCH 5/5] bluetooth: Refuse to use the HSP profile if there is some other HSP device active.
'Twas brillig, and Tanu Kaskinen at 01/04/11 13:10 did gyre and gimble: So, I suggest now that patches 1-4 get merged, along with the bluetooth: Fix HSP volume handling patch. OK, I can't see anything obvious to object to (partly because I'm pretty green with bluetooth stuff and partly because there cannot possibly be any bugs... :p) Merged in my tree now. Thanks :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively
Hi Colin, On Fri, Apr 1, 2011 at 2:28 PM, Colin Guthrie gm...@colin.guthr.ie wrote: Oh jeez... I just realised I misread on of your mails (it was a long day, I was tired better excuse goes here). No worries :) I thought you were saying your daemon crashed on *startup* on linux... before your test was run :s No, the startup is fine. The bug is about some sort of race condition when starting up and tearing down runloops, contexts and streams in a wild manner and very excessively from a client. I happend to trigger these category of bugs during my development of the PulseAudio driver for OS X, and I wrote the test to minimize the amount of code it needs to reproduce it. Even though the test results in slightly different effects (on the daemon's side) for OS X and Linux, I think it could be the same kind of bug after all. From the backtrace on Linux, it looks like a message is not fully queued or dequeued, and hence the payload is corrupted. A similar thing could have caused a semaphore not to be posted which makes the daemon hang on OS X. I'll debug this further, but I still know too less about the internal async messages that are being passed around, the queues and all the locking theory. Maybe Lennart can shed some light? Will take a look at your test to see if I can reproduce here, but as I said before, it may not be until Sunday... hopefully some of the others can chime in. No hurries, and thanks for caring :) Daniel ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively
'Twas brillig, and Colin Guthrie at 01/04/11 13:28 did gyre and gimble: Will take a look at your test to see if I can reproduce here, but as I said before, it may not be until Sunday... hopefully some of the others can chime in. OK, I took a (very) quick look. I tweaked the Makefile.am to not add your test to the TEST variable as these are all run on make check. As your test requires a running daemon this cannot be done here. As you see from the comment above, there are several other tests skipped for the same reason. I also changed the test itself a little bit so that it prints it's progress as it goes as I wasn't sure how far through the test I'd gotten. I've now run the test twice all the way through and not had a crash. This is either good or bad news depending on your take on it. I've pushed this to git master now so that more people can test. I did test against my installed server which is a few commits older but this should still be susceptible to this crash, so I think the results are still valid. Now that the test is in the tree, hopefully it'll get more test coverage. I'm on x86_64 if that's relevant... Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mageia Contributor [http://www.mageia.org/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
Re: [pulseaudio-discuss] Semaphore lockup when using threaded mainloops excessively
On Fri, Apr 1, 2011 at 3:25 PM, Colin Guthrie gm...@colin.guthr.ie wrote: I've now run the test twice all the way through and not had a crash. This is either good or bad news depending on your take on it. Could be that the faster your machine, the less likely you are to trigger the bug. Maybe more instances of the test running concurrently might help? I tested on a Netbook featuring an Atom CPU. I've pushed this to git master now so that more people can test. Great, thank you. Daniel ___ pulseaudio-discuss mailing list pulseaudio-discuss@mail.0pointer.de https://tango.0pointer.de/mailman/listinfo/pulseaudio-discuss
