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

From: Damien Sandras <dsandras seconix com>
To: Ekiga mailing list <ekiga-list gnome org>
Subject: Re: [Ekiga-list] Incoming call failure with 3.1.1
Date: Mon, 02 Mar 2009 15:41:27 +0100

Le lundi 02 mars 2009 à 15:35 +0100, Alec Leamas a écrit :
> 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?
> >>>>>>>           
> >>>>>> Hi,
> >>>>>>
> >>>>>> 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          \
> >>>>>>>           --disable-v4l
> >>>>>>>           
> >>>>>> 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/libgobject-2.0.so.0
> >>>>
> >>>> [cut]
> >>>>
> >>>> Thread 1 (Thread 0x7ffff6b0f7b0 (LWP 23589)):
> >>>> #0  0x00000037b3429a8c in g_type_check_instance_cast ()
> >>>>    from /lib64/libgobject-2.0.so.0
> >>>> #1  0x00000000004aa1da in closed_cb (main_window=0x2) at 
> >>>> gui/main.cpp:2759
> >>>> #2  0x00000037b340b7dd in g_closure_invoke () from 
> >>>> /lib64/libgobject-2.0.so.0
> >>>> #3  0x00000037b34214bd in ?? () from /lib64/libgobject-2.0.so.0
> >>>> #4  0x00000037b3422b68 in g_signal_emit_valist ()
> >>>>    from /lib64/libgobject-2.0.so.0
> >>>> #5  0x00000037b3423093 in g_signal_emit () from 
> >>>> /lib64/libgobject-2.0.so.0
> >>>> #6  0x0000003167603929 in ?? () from /usr/lib64/libnotify.so.1
> >>>> #7  0x0000003b99811994 in ?? () from /usr/lib64/libdbus-glib-1.so.2
> >>>> #8  0x00000037b340b7dd in g_closure_invoke () from 
> >>>> /lib64/libgobject-2.0.so.0
> >>>> #9  0x00000037b34214bd in ?? () from /lib64/libgobject-2.0.so.0
> >>>> #10 0x00000037b3422b68 in g_signal_emit_valist ()
> >>>>    from /lib64/libgobject-2.0.so.0
> >>>> #11 0x00000037b3423093 in g_signal_emit () from 
> >>>> /lib64/libgobject-2.0.so.0
> >>>> #12 0x0000003b998129ca in ?? () from /usr/lib64/libdbus-glib-1.so.2
> >>>> #13 0x0000003b98c0ef7b in dbus_connection_dispatch ()
> >>>>    from /lib64/libdbus-1.so.3
> >>>> #14 0x0000003b99809765 in ?? () from /usr/lib64/libdbus-glib-1.so.2
> >>>> #15 0x00000037b2c3779b in g_main_context_dispatch ()
> >>>>    from /lib64/libglib-2.0.so.0
> >>>> #16 0x00000037b2c3af6d in ?? () from /lib64/libglib-2.0.so.0
> >>>> #17 0x00000037b2c3b49d in g_main_loop_run () from 
> >>>> /lib64/libglib-2.0.so.0
> >>>> #18 0x00000037b99238a7 in gtk_main () from 
> >>>> /usr/lib64/libgtk-x11-2.0.so.0
> >>>> #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
> >> libnotify-devel-0.4.4-12.fc10.x86_64
> >> libnotify-0.4.4-12.fc10.x86_64
> >>
> >> $ 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...
> 
> %changelog
> * 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
> 

Which is a problem since the API is differnet in the official and
distributed rpms.
-- 
 _     Damien Sandras
(o-      
//\    Ekiga Softphone : http://www.ekiga.org/
v_/_   Be IP           : http://www.beip.be/
       FOSDEM          : http://www.fosdem.org/
       SIP Phone       : sip:dsandras ekiga net

Follow-Ups:
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Eugen Dedu
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Eugen Dedu

References:
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Eugen Dedu
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Eugen Dedu
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Alec Leamas
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Damien Sandras
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Alec Leamas
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Eugen Dedu
- Re: [Ekiga-list] Incoming call failure with 3.1.1
  - From: Alec Leamas

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