| Summary: | PulseAudio Python Binding PyEval_CallFunction segfault in pa_mainloop_dispatch based on pa_threaded_mainloop | ||
|---|---|---|---|
| Product: | PulseAudio | Reporter: | Leslie Zhai <xiangzhai83> |
| Component: | clients | Assignee: | pulseaudio-bugs |
| Status: | RESOLVED NOTOURBUG | QA Contact: | pulseaudio-bugs |
| Severity: | normal | ||
| Priority: | medium | CC: | lennart |
| Version: | unspecified | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
|
Description
Leslie Zhai
2013-02-23 06:24:40 UTC
You could start by installing debug symbols (if your distro supports that) or rebuilding pulseaudio with debug symbols enabled. Or actually the libpulse debug symbols don't seem to be necessary. The last calls in the stack are from your code, so the bug is most likely in your code, nothing pulseaudio related. You need to call PyEval_CallFunction() or PyGILState_Release with such parameters that they don't crash. I have zero knowledge about those functions, so you're on your own. Resolving as "notourbug". Thank Tanu`s reply :) Yes pa_threaded_mainloop is working correctly in my cgtk.c and console.py testcases https://github.com/xiangzhai/pypulseaudio/blob/master/examples/cgtk.c But the pygtk.py testcase is different from console.py, because there is already a GMainLoop in PyGtk (Gtk+-2.0 Python Binding), so is it possible that shared data from concurrent modifications by pa_threaded_mainloop && GMainLoop? PyEval_CallFunction is Python C API, it acts like call function pointer, such like PyEval_CallFunction(py_callback, argv, ...) PyGILState_Release is another Python C API, it acts like pthread_mutex_unlock, or pa_threaded_mainloop_unlock. Anyway thanks a lot for your reply :) (In reply to comment #3) > Thank Tanu`s reply :) > > Yes pa_threaded_mainloop is working correctly in my cgtk.c and console.py > testcases > https://github.com/xiangzhai/pypulseaudio/blob/master/examples/cgtk.c > > But the pygtk.py testcase is different from console.py, because there is > already a GMainLoop in PyGtk (Gtk+-2.0 Python Binding), so is it possible > that shared data from concurrent modifications by pa_threaded_mainloop && > GMainLoop? No, I'm pretty sure pa_threaded_mainloop and GMainloop do not access or modify any shared data. The problem might be that PyEval_CallFunction() is called from the thread created by pa_threaded_mainloop. The GMainLoop runs in a different thread, so if PyEval_CallFunction() expects to be run in the GMainLoop thread, things will explode. Are you sure pa_threaded_mainloop is the right choice? If you're using GMainLoop, you can use pa_glib_mainloop to integrate libpulse with the same GMainLoop that you're already using. If you specifically want to run the pulseaudio stuff in a separate thread, pa_threaded_mainloop can be used, but then you must not call PyEval_CallFunction() directly from the libpulse callbacks, but instead notify the GMainLoop thread about the events and call PyEval_CallFunction() from the GMainLoop thread. Tanu Kaskinen you are genius! you FIXME :) I use pa_glib_mainloop to handle the event signal for Python Binding instead of pa_threaded_mainloop https://github.com/xiangzhai/pypulseaudio/commit/7c9dd2ff7059b9e9521d1a2e93606670fd872d19 Thank you very much! |
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.