GNOME.org
 

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

Le lundi 02 mars 2009 à 16:10 +0100, Eugen Dedu a écrit :
> Damien Sandras wrote:
> > 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.
> 
> There is something which intrigues me: you have libnotify installed. 
> configuration step shows: "libnotify disabled".  ekiga uses notification 
> library (because it crashes).  How can this be possible?
> 

Julien introduced a double detection of notify/libnotify incompatible
with the first one.

We'll see if he can fix it in time for the release tonight. If not, I'll
postpone the release.
-- 
 _     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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]