On 16/01/13 12:53, Julien Puydt wrote:
Le 15/01/2013 23:50, Lorin Melander a écrit :
Although no crash I still need to answer incoming calls. No connection
is made but u expect this right?
No crash : wonderful!
For the problem of no connection, I suggest to open another thread on
this list
Le 15/01/2013 21:18, Lorin Melander a écrit :
I use your latest patch and I run the test. here new result file.
Where is the crash? Does that mean the problem is solved?
Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
On 11/01/13 20:30, Julien Puydt wrote:
Le 11/01/2013 20:18, Lorin Melander a écrit :
I run with new patch.
here new result. The object call still is lost.
Sigh... Let's try with a variant of the first patch :-/
So whom camp is the ball in now?
--
Eugen
Le 07/01/2013 16:22, Lorin Melander a écrit :
I observed the Virtual Table of Opal::Call is missing at second answer
or hungup.
Here is another patch to test : this makes sure we keep references to
calls in the actions. I think I'll commit that one even if it doesn't
fix the problem at hand.
Hi Julien
http://www.filebin.ca/TB8qsM5SLRW/gdb-ekiga.txt.gz
I run with new patch.
here new result. The object call still is lost.
Not success but I still want to thank you for everything you done.
Best Regards,
Lorin
My observation note:
I suspect the object call between Opal and Ekiga is not
Le 11/01/2013 20:18, Lorin Melander a écrit :
I run with new patch.
here new result. The object call still is lost.
Sigh... Let's try with a variant of the first patch :-/
Snark
diff --git a/plugins/libnotify/libnotify-main.cpp b/plugins/libnotify/libnotify-main.cpp
index b4ea8f2..dd04aa0
I got reject from the new patch
On Fri, Jan 11, 2013 at 12:30 PM, Julien Puydt jpu...@free.fr wrote:
Le 11/01/2013 20:18, Lorin Melander a écrit :
I run with new patch.
here new result. The object call still is lost.
Sigh... Let's try with a variant of the first patch :-/
Snark
Le 11/01/2013 20:47, Lorin Melander a écrit :
I got reject from the new patch
You have to unapply the first version before applying the second.
Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
to apply patch
patch 1Np patch file
to unapply patch
patch 1Rp patch file
Right ?
On Fri, Jan 11, 2013 at 12:50 PM, Julien Puydt jpu...@free.fr wrote:
Le 11/01/2013 20:47, Lorin Melander a écrit :
I got reject from the new patch
You have to unapply the first version before applying the
I did patch -R libnotify-main.cpp firstpatch
Then patch -p1 libnotify-main.cpp secondpatch
I still get reject file.
On Fri, Jan 11, 2013 at 12:50 PM, Julien Puydt jpu...@free.fr wrote:
Le 11/01/2013 20:47, Lorin Melander a écrit :
I got reject from the new patch
You have to unapply the
Le 11/01/2013 21:03, Lorin Melander a écrit :
to apply patch
patch 1Np patch file
patch -p1 /path/to/patch
to unapply patch
patch 1Rp patch file
patch -R -p1 /path/to/patch
Beware I gave the second patch file the same name as the first.
Snark
true Yes I use different name for patch.
On Fri, Jan 11, 2013 at 1:20 PM, Julien Puydt jpu...@free.fr wrote:
Le 11/01/2013 21:03, Lorin Melander a écrit :
to apply patch
patch 1Np patch file
patch -p1 /path/to/patch
to unapply patch
patch 1Rp patch file
patch -R -p1
patch -R -p1 libnotify-main.cpp
libnotify_fix_for_wrong_use_of_get_on_smart_pointer.patch
(Stripping trailing CRs from patch.)
patching file libnotify-main.cpp
patch -p1 libnotify-main.cpp patchfile2
(Stripping trailing CRs from patch.)
patching file libnotify-main.cpp
Hunk #1 FAILED at 81.
1
Le 11/01/2013 21:33, Lorin Melander a écrit :
patch -R -p1 libnotify-main.cpp
libnotify_fix_for_wrong_use_of_get_on_smart_pointer.patch
(Stripping trailing CRs from patch.)
patching file libnotify-main.cpp
patch -p1 libnotify-main.cpp patchfile2
(Stripping trailing CRs from patch.)
patching
Le 11/01/2013 22:07, Lorin Melander a écrit :
I modify the libnotify-main.cp by reading the patch.
How would I can verify patch is match expected?
Does it compile?
Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
Le 11/01/2013 22:03, Lorin Melander a écrit :
Ok. I checked it is match after I test with diff. I use 4.0. did
you use git checkout -b v4_0 origin/v4_0 ? or download from ekiga
?
I'm using the git master branch, but I don't think that file was
modified much since 4.0. Here is the patched
../../plugins/libnotify/libnotify-main.cpp: In function 'void
call_notification_action_cb(NotifyNotification*, gchar*, gpointer)':
../../plugins/libnotify/libnotify-main.cpp:110:13: error: 'class
Ekiga::Call' has no member named 'hang_up'
I fixed typo error hangup is correct
On Fri, Jan 11, 2013
Loic, the simplest thing is the following.
Get your original file.
Replace in the patch hang_up by hangup
Your patch should be ok now.
On 11/01/13 21:33, Lorin Melander wrote:
patch -R -p1 libnotify-main.cpp
libnotify_fix_for_wrong_use_of_get_on_smart_pointer.patch
(Stripping trailing CRs
http://www.filebin.ca/TBzz5XIP7Ct/gdb-snark.txt.gz
Done! It seems better something still crash due to pure virtual method.
On Fri, Jan 11, 2013 at 2:11 PM, Julien Puydt jpu...@free.fr wrote:
Le 11/01/2013 22:03, Lorin Melander a écrit :
Ok. I checked it is match after I test with diff. I
Le 11/01/2013 22:43, Lorin Melander a écrit :
http://www.filebin.ca/TBzz5XIP7Ct/gdb-snark.txt.gz
Done! It seems better something still crash due to pure virtual method.
What is strange is that I see:
Eikga::Call constructor called!!
but not the call to the destructor... did you add some
Hi Developers
I finally found the problem with Boost pointer, however I do not know
how to fix. My Boost library is based on ubuntu 12.10.
(1.49.0-3.1ubuntu1.1).
I let me show you problem: Ekiga's Engine and protocol could not keep
up with Opal protocol.
I inserted messages in each constructor
Le 08/01/2013 18:11, Lorin Melander a écrit :
many things which confirm what I thought
My question about the type of the call variable still stands.
Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
Snark,
The call is based ekiga/lib/engine/protocol/call.h class call with
pure virtual methods which is derived by the
ekiga/lib/engine/components/opal/opal-call.h.
Whenever the opal-call is gone then protocol/call will cause pure
virtual method illegal when ekiga tries to access answer /hungup.
Le 08/01/2013 20:59, Lorin Melander a écrit :
The call is based ekiga/lib/engine/protocol/call.h class call with
pure virtual methods which is derived by the
ekiga/lib/engine/components/opal/opal-call.h.
I'm not asking where the class is : you have a problem with a variable
call when doing
Two methods call-answer() and call-hungup()
-Lorin
On Tue, Jan 8, 2013 at 1:01 PM, Julien Puydt jpu...@free.fr wrote:
Le 08/01/2013 20:59, Lorin Melander a écrit :
The call is based ekiga/lib/engine/protocol/call.h class call with
pure virtual methods which is derived by the
Le 08/01/2013 21:27, Lorin Melander a écrit :
Two methods call-answer() and call-hungup()
Right, two methods.
What is the type of the call object?
Snark
___
ekiga-devel-list mailing list
ekiga-devel-list@gnome.org
It is in the /ekiga/plugins/libnotify/libnotify-main.cpp
static void
call_notification_action_cb (NotifyNotification *notification,
gchar *action,
gpointer data)
{
Ekiga::Call *call = (Ekiga::Call *) data; is this you want to know ?
I think Julien wants that in gdb when the crash appears you type
p call
or other command to see what is the type of the variable call. Probably
it is initialised (?) to another value, and he wants to see what is the
type of this value in order to see where this is done.
Another possibility
Le 09/01/2013 00:16, Lorin Melander a écrit :
It is in the /ekiga/plugins/libnotify/libnotify-main.cpp
static void
call_notification_action_cb (NotifyNotification *notification,
gchar *action,
gpointer data)
{
Ekiga::Call *call =
HI Eugene,
I observed the Virtual Table of Opal::Call is missing at second answer
or hungup.
First answer
(gdb) print *call
$1 = {_vptr.Call = 0xb7e7d660 vtable for Opal::Call+256
Ekiga answers successfully.
2nd answer
(gdb) print *call
$1 = {_vptr.Call = 0x33352020,
Ekiga crashs with pure
Right there is something wrong with a smart pointer.
At first answer the call object correctly through a smart pointer.
I do not know why the call got the vtable missing at dail second time.
-Lorin.
On Mon, Jan 7, 2013 at 9:54 AM, Julien Puydt jpu...@free.fr wrote:
Le 07/01/2013 17:21, Lorin
Le 07/01/2013 18:22, Lorin Melander a écrit :
Right there is something wrong with a smart pointer.
At first answer the call object correctly through a smart pointer.
Yes.
I do not know why the call got the vtable missing at dail second time.
I know why: the object got killed. Now the
32 matches
Mail list logo
