Re: [Ekiga-list] Incoming call failure with 3.1.1

Eugen Dedu wrote:
Alec Leamas wrote:
Damien Sandras wrote:
Le lundi 02 mars 2009 à 14:39 +0100, Alec Leamas a écrit :
Eugen Dedu wrote:
Eugen Dedu wrote:
Damien Sandras wrote:
Le jeudi 26 février 2009 à 10:30 +0100, Alec Leamas a écrit :
Damien Sandras wrote:
Le mercredi 25 février 2009 à 21:02 -0500, Mark T.B. Carroll a écrit :
Damien Sandras <dsandras seconix com> writes:

Le jeudi 19 février 2009 à 00:32 -0500, Mark T.B. Carroll a écrit :
I have run through the configuration assistant thing from start to finish. I can call the 500 ekiga net echo test and that works just fine. However, calling the 520 ekiga net callback service has it hang up on me and then ... nothing, though the -d 5 output shows that it is indeed getting a callback initiated from from sip:500 ekiga net which is then aborted. I am behind NAT and the router forwards incoming UDP from port 5060 to 5100 to the machine I'm using and acts as a gateway to let all
my outgoing packets out.

Should I gzip my -d 4 output and send it to somebody? I can also sniff packets and send pcap files. I use Debian; software versions are,
There is a known problem with incoming calls and the current snapshot. I
will fix it this week-end.
Now with the 20090225 one, the incoming call does arrive (yay!), I hit
`accept', and it segfaults.

I can still send my -d 4 output to somebody. (-:
A gdb backtrace would be more useful.
waiting for some kind of customer "service", taking a backtrace (yes, same problem, trunk as of yesterday).
Despite trying 50 times, I can not reproduce it. Are you sure something
is not corrupted?

Eugen, can you reproduce it?

Sorry for taking so much time to reply.

Very interesting, when I call 520, I receive the call and it works (I
have audio conversation).  I use on debian
ii ekiga-snapshot 0-20090226-1 H.323 and SIP compatible VoIP
client - svn version

configure:      dummy
       export PTLIBDIR=$$PWD;    \
       ./configure               \
          --prefix=/usr          \
          --libdir=/usr/lib64    \
          --enable-debug         \
          --enable-tracing       \
          --disable-static       \
          --enable-plugins       \
          --disable-oss          \
          --enable-v4l2          \
          --disable-avc          \
For info, I use much less configure options, only prefix and enable-v4l for ptlib I think, the other ones are by default. (But I do not think
this is the problem.)

By the way, does someone know how we can show the default options when running ./configure --help (for ex.)? Instead of putting them in the wiki, better to automatise the process by pushing them in the source code.

================ Final configuration ===================
         Installing into prefix  :  /usr

              libnotify support  :  disabled
Maybe it's because libnotify disabled?! I have it enabled, and I have: ii libnotify-dev 0.4.4-3 sends desktop notifications to
a notification daemon
ii libnotify1 0.4.4-3 sends desktop notifications to
a notification daemon
In fact, it cannot be because of libnotify, because Mark Carroll has the same problem and he uses snapshots, which use libnotify...

My bad, thou shall not guess. I just compiled a version w libnotify, same problem & crash. Relevant thread from gdb:

Program received signal SIGSEGV, Segmentation fault.
0x00000037b3429a8c in g_type_check_instance_cast ()
   from /lib64/


Thread 1 (Thread 0x7ffff6b0f7b0 (LWP 23589)):
#0  0x00000037b3429a8c in g_type_check_instance_cast ()
   from /lib64/
#1 0x00000000004aa1da in closed_cb (main_window=0x2) at gui/main.cpp:2759 #2 0x00000037b340b7dd in g_closure_invoke () from /lib64/
#3  0x00000037b34214bd in ?? () from /lib64/
#4  0x00000037b3422b68 in g_signal_emit_valist ()
   from /lib64/
#5 0x00000037b3423093 in g_signal_emit () from /lib64/
#6  0x0000003167603929 in ?? () from /usr/lib64/
#7  0x0000003b99811994 in ?? () from /usr/lib64/
#8 0x00000037b340b7dd in g_closure_invoke () from /lib64/
#9  0x00000037b34214bd in ?? () from /lib64/
#10 0x00000037b3422b68 in g_signal_emit_valist ()
   from /lib64/
#11 0x00000037b3423093 in g_signal_emit () from /lib64/
#12 0x0000003b998129ca in ?? () from /usr/lib64/
#13 0x0000003b98c0ef7b in dbus_connection_dispatch ()
   from /lib64/
#14 0x0000003b99809765 in ?? () from /usr/lib64/
#15 0x00000037b2c3779b in g_main_context_dispatch ()
   from /lib64/
#16 0x00000037b2c3af6d in ?? () from /lib64/
#17 0x00000037b2c3b49d in g_main_loop_run () from /lib64/ #18 0x00000037b99238a7 in gtk_main () from /usr/lib64/
#19 0x00000000004aa6d4 in main (argc=1, argv=0x7fffffffe438)
    at gui/main.cpp:4562

What version of libnotify ?
What does grep give as result :
grep closed /usr/include/libnotify/notif*

$ rpm -qa | grep libnotify

$ grep closed /usr/include/libnotify/notif*
/usr/include/libnotify/notification.h: void (*closed)(NotifyNotification *notification, gint reason)

which is the problem. Also, gdb reveals that closed_cb() is called with two args, first of which is a *notification pointer, the second a 0x2.

We have the same version (0.4.4), yet the API is different??? Has Fedora changed the API???

Thou Shall Not Guess, once again. Top of the libnotify RPM changelog'below...

* Sat Aug 23 2008 Matthias Clasen <mclasen redhat com> - 0.4.4-12
- Handle extra parameter of the closed signal

* Tue Jun 10 2008 Colin Walters <walters redhat com> - 0.4.4-11
- Add patch neccessary for reliable notification positioning

* Mon Feb 18 2008 Fedora Release Engineering <rel-eng fedoraproject org> - 0.4.4-10
- Autorebuild for GCC 4.3

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]