GNOME Bugzilla – Bug 697738
Freezes when accepting video call (backtrace attached)
Last modified: 2020-06-06 16:30:33 UTC
Created attachment 241187 [details] GDB backtrace I have two Windows XP machines, each with a Logitech C500, and each connected to an Asterisk SIP server. Ekiga 4.0.1. Each machine can see its own video in the preview window. When I ring one machine from the other, Ekiga freezes on the recipient as soon as the button is pressed to pick up the call. I've attached a backtrace. I've got a debug log but its too large to upload. I'll find some way to send it if requested.
Created attachment 241188 [details] Ekiga debug log
I looked over your log without having found something evident. I will look again into it.
Unfortunately, the stack trace does not give any useful information, because the synbols are stripped. Could you try installing the program at http://eugen.dedu.free.fr/x.exe on the machine where ekiga will freeze and give me again the gdb stack trace? Also, does the freeze always appear? Can you notice visually if it appears when you press the button, or when it tries to show the remote video, or other thing, or you cannot infer anything? Finally, in -d 4 debug log I see that there is communication for several seconds at then end of the log, whereas you said there is freeze, do you know what happens?
Any news, ian?
This could be the same as https://mail.gnome.org/archives/ekiga-devel-list/2013-April/msg00009.html.
Very sorry for not getting back to this. I will look at it today, but hopefully within the next few days if not.
Created attachment 243239 [details] GDB backtrace based off Eugen Dedu's exe
ian, sorry, but could you also use http://eugen.dedu.free.fr/a.exe and give me just the -d 4 log?
The video preview output always freezes as soon as I pick up a video call. If I turn off the video preview window on the recipient then it still hangs, but I see no video at all. The recipient doesn't see any video from the calling side. The application freezes with the video preview (or blank window with previews off). It happens on every Ekiga to Ekiga video call. It seems to happen with "moving logo" chosen as video device on both PCs too. If I disable every video codec on the recipient then Ekiga doesn't hang (but of course there is no video). https://mail.gnome.org/archives/ekiga-devel-list/2013-April/msg00009.html could be the same bug if this call back test is a video call. Thanks,
Okay, a.exe installed now, same problem. I've noticed that after a while, without -d4 I get: osutils.cxx(2294) PTLib Possible deadlock in read/write mutex 0x3019ec8 : thread-id=1704 (0x6a8), readers=0, writers=1 thread-id=3604 (0xe14), readers=1, writers=6 Anyway, the stderr log is attached. In the log I'm using the "moving logo" device on both PCs. The "Read 160 instead of 320" line keeps repeating during the hang, and the 3 final lines only seem to appear when I end the task. Thanks
Created attachment 243243 [details] stderr from a.exe
Just a note to say that this problem also seems to affect non-video calls. We've noticed that if somebody makes a call from a Cisco 7940 (non-video) phone via our Asterisk server to an Ekiga client then Ekiga will crash unless every codec has been disabled. The Ekiga user can phone the 7940 just fine, even with all video codecs enabled.
ian, sorry for the long delay, I was pretty busy. I am willing to tackle this bug, are you ready to help to fix this bug too?
Hi, No problem about the delay. If I can provide any more information then just tell me. Thanks for looking at this, Ian
ian, could you tell me what do show the three entries in Preferences->Audio-Devices?
"Default (PTLIB/WindowsMultimedia)" in all three boxes. The problem on inbound calls happens even without the webcam plugged in/installed, in which case the only other option is "SoundMAX HD Audio (PTLIB/WindowsMultiMedia) Ian
Ian, in comment #12 you wrote that it appears without video too. Does this appear when you disable all video codecs on recipient, or all audio and video codecs on recipient? I would like to know if it is related to video or not. Also, in the same comment you wrote that it crashed, whereas in the bug report there was a freeze. Do you confirm this? If yes, I would like a gdb stack from the crash, since it is simpler to investigate. Be prepared to have several exchanges in bugzilla to solve this bug, sorry...
Sorry, I misspoke. Ekiga never crashes. It simply hangs/becomes unresponsive. I don't know if this is relevant, but I'm running Debian's Asterisk 1:1.6.2.9-2+squeeze6 with: videosupport=yes disallow=all allow=ulaw allow=alaw allow=gsm allow=h263 I have realized that the hang is intermittent, let me give you an example session. In each case I dial from a Cisco 7940 (non-video) phone, to 4.0.1 with the moving logo video device. If the call fails the asterisk server behaves as if Ekiga doesn't pick up (7940 keeps ringing): My video codec order is: * theora * h261 * H263 * H263-1998 * H264 * MP4V-ES I can accept 10 successive inbound calls without a crash: If I disable all video codecs If I check just theora If I check just h261 If I check just MP4V-ES If I check only theora and h261 If I check only theora and MP4V-ES If I check only theora and h261 and MP4V-ES If I check everything again it hangs on the second inbound accept. After restarting it, if I check everything except theora it hangs on the second inbound accept. After restarting it, if I check only H263-1998, H264, MP4V-ES I can make 10 calls. If I check only theora, h261, H263 it hangs straight away. After restarting (not changing the codecs) it hangs on the second inbound accept. After restarting again it hangs on the third inbound attempt. At this point I reorder my codec list to: * H263-1998 (disabled) * H264 (disabled) * MP4V-ES (disabled) * theora * h261 * H263 it hangs on the 2nd call again.
It could be a duplicate of bug #719951
Ekiga is not under active development anymore: https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/273 Ekiga saw its last release 7 years ago. The last code commits were 4 years ago. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (and transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active Ekiga development again in the future.