VoIP Mailing List Archives

[jason at jasonjgw.net]

This has occurred with a number of recent revisions. If anyone can reproduce
it or suggest debugging steps, I'll gladly supply more information. Jira isn't
convenient for me due to X issues at the moment, unless there's a way to
interact with it other than via a Javascript-capable Web browser.

Distribution: Debian Sid, now kernel 2.6.29 (same experience with 2.6.26).

FreeSwitch revision 12701.

Steps to reproduce

Make a call with portAudio to a SIP endpoint (I haven't tried it with other
endpoints):
pa call <destination>

Next, make another call:

pa call <other_destination>

Result: the party to the first call hears no music on hold, or possibly
broken/intermittent music on hold, and the second call fails to go through.

Where it hangs seems to vary, and sometimes it does in fact work. Often it
hangs before it reaches the calling state, suggesting that there's some kind
of locking issue involved.

I'll perform further testing. Meanwhile, if anyone else can reproduce it, this
may help.

Note that the second call often doesn't return an error; it just hangs
somewhere in the set-up process, e.g., init.


_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[jason at jasonjgw.net]

While I was trying to obtain more detailed logs of my portaudio problems,
FreeSWITCH crashed, leaving a core file.

The backtraces are here:
http://pastebin.freeswitch.org/7998

As far as I can remember, at the time of the segfault, one channel was trying
to connect and not succeeding; I had just issued a pa hangup command on it and
then a pa call to try connecting again. Since my memory of exactly what was
happening isn't as reliable as it should be, the value of the backtraces may
be diminished.

As to the portaudio problem, with rev. 12701 (Debian Sid, kernel 2.6.29,
x86_64 architecture), the situation appears to be that the second and
subsequent concurrent portaudio calls sometimes wait for a long time after
issuing a log message such as the following:

[NOTICE] switch_channel.c:597 switch_channel_set_name() New Channel
sofia/internal/1000@192.168.0.2:5070 [d6e56642-1a9b-11de-b23e-c5a9450df57d]

These calls do not always complete successfully, but I'm still trying to
collect more precise details of when and why they fail.

With apologies for being unable to use Jira, if anything valuable appears in
the backtraces, you are welcome to let me know via the list or by e-mail.

I have previously seen crashes while working with multiple portaudio calls,
but I don't yet have a reliable means to reproduce them.

If the backtraces are revealing, that's good, but if not, that's fine too and
I'll collect better particulars next time.


_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org

[brian at freeswitch.org]

Please direct the report to http://jira.freeswitch.org

/b

On Mar 27, 2009, at 2:58 AM, Jason White wrote:

[anthony.minessale at g...]

Are you updating with "make current" each time?


On Fri, Mar 27, 2009 at 2:58 AM, Jason White <jason@jasonjgw.net (jason@jasonjgw.net)> wrote: