To be fair, we do have a few modifications to the source.
I seriously
doubt anyone wants them, but I am making them available
under GPL. I
cannot rule out that I haven't caused the problem. I have
created a
patch and posted it to http://www.hedl
in.com/ekiga-pf.patch. Below is a
description of the changes:
We added call recording to the ekiga pcss endpoint (pretty
simple, we
add an OpalFileMediaStream as a sink to each patch connected
to the PCSS
endpoint). We did not modify the gui to access this
functionality.
Stack traces indicate this change is not affecting our
deadlocks.
The second change is to add "PCP" support. This
is an internally
defined protocol similar to Woomera (We didn't know about
woomera) to
allow us to control the phone using an XPCom component in
Firefox. I
cannot rule this out as a cause but I don't think it is.
All the
dialing was done from Firefox using this code.
The deadlock always occurs as the call is being terminated.
The
PCP::OnDisconnect function is almost identical to the
disconnect button
callback in the gui code. Yesterday I made changes to make
sure it
wasn't being called twice.
I have made a stack trace while the phone was deadlocked and
posted it
to http://www.
hedlin.com/ekiga-bt-full.5104. Thread 1 became blocked
after we were aware of the problem and I clicked the
disconnect button.
Unfortunately I wasn't running a trace on this last deadlock
(when I
finally rolled out libopal and pwlib with full debug
symbols). I have a
-d6 trace (with some substitutions of phone numbers, user
name, and
server names) from yesterday where the stack trace looked
very similar
posted to http://ww
w.hedlin.com/ekiga-deadlock.log.gz
I am still trying to figure out which objects are locking
and will post
more when I have it, but I am hoping someone more familiar
with ekiga
and opal can find this faster than me.
Thank you,
Charlie Hedlin
_______________________________________________
Ekiga-devel-list mailing list
Ekiga-devel-list gnome.org
http://mail.gnome.org/mailman/listinfo/ekiga-devel-list
|
