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

[Alec Leamas <leamas alec gmail com>]

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