Created attachment 122001 [details] pulseaudio start failed There is not any audio card in the system, we just want to play audio via bluetooth headset. We ported pulseaudio6.0 to arm linux, it could not detect any other sinks, so it load module-null-sink, but can not found any data for sink:auto_null in the database device volumes. Then it show failed to handle SIGBUS. Aborted. The details is in the attachment.
What do you mean when you say you ported pulseaudio to arm? Pulseaudio should work on arm out-of-the-box. After reading up on what SIGBUS might indicate, one possible cause for this crash might be unaligned memory access. This will make alignment issues to become invisible (with performance cost): echo 2 > /proc/cpu/alignment Does that command appear to "fix" this crash? I hope it does, but in any case, switch the alignment configuration back to 5 (or whatever was the original value) and get a backtrace with gdb of the crash. A backtrace is needed for further debugging. You can read more about the kernel's alignment error handling configuration here: https://www.kernel.org/doc/Documentation/arm/mem_alignment
Created attachment 122021 [details] attachment-19082-0.html Thanks for your help. But it doesn't work. If the problem is caused by the module-null-sink. From the attachment, We can see that, the module-null-sink was loaded,but can not found any data for key:sink:auto_null in the database. And I have tried to remove the module-null-sink from the default.pa, then the SIGBUS will no longer appeared, other error will appeared. 在 2016-02-27 18:41:45，bugzilla-daemon@freedesktop.org 写道： Comment # 1 on bug 94316 from Tanu Kaskinen What do you mean when you say you ported pulseaudio to arm? Pulseaudio should work on arm out-of-the-box. After reading up on what SIGBUS might indicate, one possible cause for this crash might be unaligned memory access. This will make alignment issues to become invisible (with performance cost): echo 2 > /proc/cpu/alignment Does that command appear to "fix" this crash? I hope it does, but in any case, switch the alignment configuration back to 5 (or whatever was the original value) and get a backtrace with gdb of the crash. A backtrace is needed for further debugging. You can read more about the kernel's alignment error handling configuration here: https://www.kernel.org/doc/Documentation/arm/mem_alignment You are receiving this mail because: You reported the bug.
It's normal that in this situation module-null-sink gets loaded, and module-device-restore fails to find any saved configuration for the null sink. A backtrace is needed to figure out where exactly the crash happens. If using gdb to get a backtrace is new to you, there are some instructions on this page: https://wiki.freedesktop.org/www/Software/PulseAudio/Documentation/User/Community/
Created attachment 122052 [details] gdb_pulseaudio.txt Thans a lot. The attachment is the backtrace for pulseaudio. Hope it could helpful for analysis the problem. -- 发自我的网易邮箱手机智能版 在 2016-02-29 17:47:07，bugzilla-daemon@freedesktop.org 写道： >Comment # 3 on bug 94316 from Tanu Kaskinen >It's normal that in this situation module-null-sink gets loaded, and >module-device-restore fails to find any saved configuration for the null sink. >A backtrace is needed to figure out where exactly the crash happens. If using >gdb to get a backtrace is new to you, there are some instructions on this page: >https://wiki.freedesktop.org/www/Software/PulseAudio/Documentation/User/Community/ >You are receiving this mail because: >You reported the bug.
The crash seems to happen when accessing memory pool memory, probably when that happens for the first time. For some reason the operating system doesn't like that. The problem probably goes away if you set "enable-shm = no" in /etc/pulse/daemon.conf. If the system is very tight on memory, you could also try playing with "shm-size-bytes" in daemon.conf to set it to some lower value than the default, although my (limited) understanding is that lack of memory shouldn't be the problem if the crash happens already on the first access to the shared memory. If the system has memory overcommit disabled, allocating the memory pool should fail in an earlier phase, and if overcommit is enabled, this code shouldn't fail, because it only consumes the first 64 kB from the memory pool, which surely can't cause the memory to run out (otherwise you'd have bigger problems).
Created attachment 122053 [details] attachment-19787-0.html Thans for your mail. I have tried to modify the "enable-shm" and "shm-size-bytes", but it seems itdoesn't work. It also show that "Using shared memory pool with 1024 slots of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is 65496". 在 2016-03-01 17:30:20，bugzilla-daemon@freedesktop.org 写道： Comment # 5 on bug 94316 from Tanu Kaskinen The crash seems to happen when accessing memory pool memory, probably when that happens for the first time. For some reason the operating system doesn't like that. The problem probably goes away if you set "enable-shm = no" in /etc/pulse/daemon.conf. If the system is very tight on memory, you could also try playing with "shm-size-bytes" in daemon.conf to set it to some lower value than the default, although my (limited) understanding is that lack of memory shouldn't be the problem if the crash happens already on the first access to the shared memory. If the system has memory overcommit disabled, allocating the memory pool should fail in an earlier phase, and if overcommit is enabled, this code shouldn't fail, because it only consumes the first 64 kB from the memory pool, which surely can't cause the memory to run out (otherwise you'd have bigger problems). You are receiving this mail because: You reported the bug.
(In reply to duanshitao from comment #6) > Thans for your mail. > I have tried to modify the "enable-shm" and "shm-size-bytes", but it seems > itdoesn't work. Do you mean that with "enable-shm = no" the crash still happens in the same place? > It also show that "Using shared memory pool with 1024 slots > of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is > 65496". What is the configuration when this is printed? This shouldn't be printed when shm is disabled, and should be different if shm-size-bytes is different than the default.
Created attachment 122055 [details] daemon.conf Yes, I set "enable-shm = no", it doesn't work and the log was printed. And I set "shm-size-bytes=16777216".The results is the same. The attachment is the daemon.conf which I used. Please kindly help me to have a check. -- 发自我的网易邮箱手机智能版 在 2016-03-01 19:19:49，bugzilla-daemon@freedesktop.org 写道： >Comment # 7 on bug 94316 from Tanu Kaskinen >(In reply to duanshitao from comment #6) >> Thans for your mail. >> I have tried to modify the "enable-shm" and "shm-size-bytes", but it seems >> itdoesn't work. > >Do you mean that with "enable-shm = no" the crash still happens in the same >place? > >> It also show that "Using shared memory pool with 1024 slots >> of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is >> 65496". > >What is the configuration when this is printed? This shouldn't be printed when >shm is disabled, and should be different if shm-size-bytes is different than >the default. >You are receiving this mail because: >You reported the bug.
Semicolon is a comment character in daemon.conf, so you have to remove the semicolon from the lines you have edited for the changes to take effect.
So sorry for my mistake that I had not delete the ";" at the begin of the line. Now the daemon works, but there iS a new issue. It shows that cannot open Shared object file module-device-restore.so which I could found in /usr/lib/pulse-6.0/modules. What is the problem? -- 发自我的网易邮箱手机智能版 在 2016-03-01 19:19:49，bugzilla-daemon@freedesktop.org 写道： >Comment # 7 on bug 94316 from Tanu Kaskinen >(In reply to duanshitao from comment #6) >> Thans for your mail. >> I have tried to modify the "enable-shm" and "shm-size-bytes", but it seems >> itdoesn't work. > >Do you mean that with "enable-shm = no" the crash still happens in the same >place? > >> It also show that "Using shared memory pool with 1024 slots >> of size 64.0 KiB each, total size is 64.0 MiB, maximum usable slot size is >> 65496". > >What is the configuration when this is printed? This shouldn't be printed when >shm is disabled, and should be different if shm-size-bytes is different than >the default. >You are receiving this mail because: >You reported the bug.
You're not the first one to get confused by the semicolons... Your earlier logs showed that pulseaudio successfully loaded module-device-restore. What has changed? Is there any other log output that seems related? Does your user have permission to open the module file?
I just delete the semicolons at the beginning of the lines. And to avoid permission error, I had done chmod 777 for all the files. in /usr/lib/pulse-6.0/modules -- 发自我的网易邮箱手机智能版 在 2016-03-01 20:26:26，bugzilla-daemon@freedesktop.org 写道： >Comment # 11 on bug 94316 from Tanu Kaskinen >You're not the first one to get confused by the semicolons... > >Your earlier logs showed that pulseaudio successfully loaded >module-device-restore. What has changed? Is there any other log output that >seems related? Does your user have permission to open the module file? >You are receiving this mail because: >You reported the bug.
Hi Tanu Kaskinen: The load module failed issue is solved by set dl-search-path to /usr/lib/pulse-6.0/modules. Then I change enable-shm to enable-shm=no, the issue of SIGBUS is also solved. I have another question, use the current configuration, is there any influence during audio playing. -- 发自我的网易邮箱手机智能版 在 2016-03-01 20:26:26，bugzilla-daemon@freedesktop.org 写道： >Comment # 11 on bug 94316 from Tanu Kaskinen >You're not the first one to get confused by the semicolons... > >Your earlier logs showed that pulseaudio successfully loaded >module-device-restore. What has changed? Is there any other log output that >seems related? Does your user have permission to open the module file? >You are receiving this mail because: >You reported the bug.
Created attachment 122073 [details] pacmd_list-sinks.txt After modified the daemon.conf, the program run normally. But it will shutdown and terminated when I use pacmd or pactl to send a cmd. At the first time, after the bluetooth headset was connected, I could see the a2dp sink, but after pulseaudio terminated, I restart the pulseaudio, the a2dp sink will never be seen. -- 发自我的网易邮箱手机智能版 在 2016-03-01 20:26:26，bugzilla-daemon@freedesktop.org 写道： >Comment # 11 on bug 94316 from Tanu Kaskinen >You're not the first one to get confused by the semicolons... > >Your earlier logs showed that pulseaudio successfully loaded >module-device-restore. What has changed? Is there any other log output that >seems related? Does your user have permission to open the module file? >You are receiving this mail because: >You reported the bug.
Created attachment 122074 [details] pulseaudio_terminated_after_pacmd_exe.txt
You can set "exit-idle-time = -1" in daemon.conf to prevent shutdown after a period of idleness.
I used pacmd play-file to play a mp3, it show me: no pulseaudio daemon running, or not running as session daemon. -- 发自我的网易邮箱手机智能版 在 2016-03-02 15:07:39，bugzilla-daemon@freedesktop.org 写道： >Comment # 16 on bug 94316 from Tanu Kaskinen >You can set "exit-idle-time = -1" in daemon.conf to prevent shutdown after a >period of idleness. >You are receiving this mail because: >You reported the bug.
I used pacmd play-file and paplay to play a wav file, it show me failed to open audio file. What the problem? -- 发自我的网易邮箱手机智能版 在 2016-03-02 15:07:39，bugzilla-daemon@freedesktop.org 写道： >Comment # 16 on bug 94316 from Tanu Kaskinen >You can set "exit-idle-time = -1" in daemon.conf to prevent shutdown after a >period of idleness. >You are receiving this mail because: >You reported the bug.
If paplay fails with error message "Failed to open audio file", it means that libsndfile's function sf_open_fd() failed. Based on the available information, it's impossible for me to say with any more precision what the problem is.
Created attachment 122096 [details] attachment-18376-0.html Thanks for your mail. I had download another audio file, it could be played by pacmd play-file cmd. May be the coding format of the audio file caused the issue. But it could not be played by paplay cmd, it looks like, paplay need to use shared memory, even If I set enable-shm to no. Another question, if I just send pcm streams to pulseaudio to realize the audio play(the decoding has been done in another application). Where are the API that could be called. 在 2016-03-03 16:14:14，bugzilla-daemon@freedesktop.org 写道： Comment # 19 on bug 94316 from Tanu Kaskinen If paplay fails with error message "Failed to open audio file", it means that libsndfile's function sf_open_fd() failed. Based on the available information, it's impossible for me to say with any more precision what the problem is. You are receiving this mail because: You reported the bug.
(In reply to duanshitao from comment #20) > Created attachment 122096 [details] > attachment-18376-0.html > > Thanks for your mail. You're welcome. By the way, I'm not sending my comments via email, it's the bug tracking software that sends the emails. It would be nice if you could also use the web interface, because the html parts of your emails get added to the bug as attachments. Not a big deal, though. > I had download another audio file, it could be played by pacmd play-file > cmd. May be the coding format of the audio file caused the issue. > But it could not be played by paplay cmd, it looks like, paplay need to use > shared memory, even If I set enable-shm to no. Oh, I didn't realize that to fully disable shm, it has to be disabled separately for clients too. Adding "enable-shm = no" to /etc/pulse/client.conf should stop paplay (and all other applications using libpulse) from trying to use shared memory. > Another question, if I just send pcm streams to pulseaudio to realize the > audio play(the decoding has been done in another application). Where are the > API that could be called. libpulse is the library that provides the client API. It's documented here: https://freedesktop.org/software/pulseaudio/doxygen/
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/pulseaudio/pulseaudio/issues/431.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.