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 <[email protected]> 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 [email protected] echo test and that works just fine. However, calling the [email protected] 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:[email protected] 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



_______________________________________________
ekiga-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/ekiga-list

Reply via email to