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 <dsand...@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 5...@ekiga.net echo test and that works > >>>>>>>> just fine. > >>>>>>>> However, calling the 5...@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:5...@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* /usr/include/libnotify/notification.h: void (*closed)(NotifyNotification *notification); -- _ Damien Sandras (o- //\ Ekiga Softphone : http://www.ekiga.org/ v_/_ Be IP : http://www.beip.be/ FOSDEM : http://www.fosdem.org/ SIP Phone : sip:dsand...@ekiga.net _______________________________________________ ekiga-list mailing list ekiga-list@gnome.org http://mail.gnome.org/mailman/listinfo/ekiga-list