[jitsi-dev] libjnportaudio.so segfaults resuming after suspension - Linux


#1

Hello,
I'm attaching the console output of a jitsi process (jitsi-1.1-nightly.4359.10120.x86_64.rpm) after have resumed the system (OpenSUSE 12.2) from suspension (suspension to ram).

You can see at line 42

free(): invalid pointer

and at line 46 the backtrace which shows:

/usr/lib/jitsi/lib/native/libjnportaudio.so(Pa_UpdateAvailableDeviceList+0x15d)[0x7fba348e7fcd]

Assuming the jre (either oracle's one build 1.7.0_09-b05 or openjdk's build 23.2-b09) is not violating memory limits, I would blame that Pa_UpdateAvailableDeviceList function call.
If I understand correctly that function is part of the portaudio lib (even if I have set jitsi to use pulseaudio), thus the culprit of the segfault is the function itself or the code portion in libjnportaudio.so which calls it .

I reported an analogue issue http://java.net/jira/browse/JITSI-1031 some months ago, but didn't receive much love ;).

Being such a disruptive and annoying thing to have to restart jitsi *every* time I go for a suspension, I'd like to hear something back from the devs, maybe how to workaround and if anybody else confirms the issue.

Thank you.

jitsi_console_output.log (25.8 KB)

···

--
Marco


#2

I'm attaching the console output of a jitsi process (jitsi-1.1-nightly.4359.10120.x86_64.rpm) after have resumed the system (OpenSUSE 12.2) from suspension (suspension to ram).

You can see at line 42

free(): invalid pointer

and at line 46 the backtrace which shows:

/usr/lib/jitsi/lib/native/libjnportaudio.so(Pa_UpdateAvailableDeviceList+0x15d)[0x7fba348e7fcd]

I reported an analogue issue http://java.net/jira/browse/JITSI-1031 some months ago, but didn't receive much love ;).

Thank you for the report! We'll address this issue as soon as possible in accord with our priorities.

even if I have set jitsi to use pulse audio

In the meantime, if Jitsi's PulseAudio support suits you well, we may be able to prevent the invocation of PortAudio's function Pa_UpdateAvailableDeviceList. Please let us know if that'll mitigate the problem for you.

···

On 07.12.2012, at 02:27, Marco Vittorini Orgeas <marco@vittorini.org> wrote:


#3

Hi!
Well, yes(!), if that prevents jitsi to segfaults every time would be *greatly* appreciated!
Also seen that pulseaudio is the default option running jitsi under linux, I would have already expected portaudio related code not be running, so this could be another bug per se.
Naturally, reading your reply I'm assuming that jitsi connect directly to pulseaudio server, bypassing entirely portaudio(?).

To repeat: this would be *greatly* appreciated!

···

On 12/07/2012 08:44 AM, Lyubomir Marinov wrote:

even if I have set jitsi to use pulse audio

In the meantime, if Jitsi's PulseAudio support suits you well, we may be able to prevent the invocation of PortAudio's function Pa_UpdateAvailableDeviceList. Please let us know if that'll mitigate the problem for you.

--
Marco


#4

I have a doubt:
Do you meant to try to create and propose a patch myself?
If not: what's the best way for me to notice the change?

Is there some "commits mailing list" where I can monitor for this particular
change to happen, or is there any other resource where I can see daily commits
(like a changelog or something like this).

Thank you.

···

On Friday, December 07, 2012 02:45:09 PM Marco Vittorini Orgeas wrote:

On 12/07/2012 08:44 AM, Lyubomir Marinov wrote:
>> even if I have set jitsi to use pulse audio
>
> In the meantime, if Jitsi's PulseAudio support suits you well, we may be
> able to prevent the invocation of PortAudio's function
> Pa_UpdateAvailableDeviceList. Please let us know if that'll mitigate the
> problem for you.
Hi!
Well, yes(!), if that prevents jitsi to segfaults every time would be
*greatly* appreciated!
Also seen that pulseaudio is the default option running jitsi under
linux, I would have already expected portaudio related code not be
running, so this could be another bug per se.
Naturally, reading your reply I'm assuming that jitsi connect directly
to pulseaudio server, bypassing entirely portaudio(?).

To repeat: this would be *greatly* appreciated!

--
Marco