Hi Alex,
which application does this happen in?
o Alex Balashov on 06/20/2011 10:26 AM:
I have what appears to be a crash bug on BYE processing. Here is the
backtrace:
#0 0x00007ffff74dbbdc in std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::compare(char const*)
const () from /usr/lib64/libstdc++.so.6
#1 0x00000000004cbbe3 in operator==<char, std::char_traits<char>,
std::allocator<char> > (this=0x8ae4d90, hdrs="", flags=1)
at /usr/lib/gcc/x86_64-redhat-
linux/4.1.2/../../../../include/c++/4.1.2/bits/basic_string.h:2163
#2 AmSipDialog::bye (this=0x8ae4d90, hdrs="", flags=1) at
AmSipDialog.cpp:793
>...
This occurred in 1.1.1, and continues to occur after I upgraded to
1.4.1. This backtrace is from 1.4.1.
is it consistently reproducible or does that occur only once in a while?
Unfortunately, I do not have the core dump nor a copy of the message
buffer that is causing this. However, line 793 in AmSipDialog.cpp is
this comparison:
if (it->second.method == "INVITE"){
I can only assume that something here is being dereferenced that is in
fact null, or that 'method' is a pointer out of bounds. But
unfortunately it is not for me to know.
Sorry, that's all the information I have. Unfortunately, the scope in
step #0 won't let me print the value of any useful variables, and I'm
not handy enough with GDB to figure out how to traverse up the call
stack.
can you do 'up' twice, which gets you into the AmSipDialog::bye frame,
then examine a few things:
p uac_trans
p it
p it->second
p uac_trans.size()
(sounds you are running sems in gdb, so that should be possible)
thanks!
Stefan
_______________________________________________
Sems mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/sems
