now I develop the test code using GPB in qnx as follows:
Offer_event Offer;
string a = "127.0.0.7";
Offer.set_ipaddress(a);
Offer.set_port(9000);
BufSize = Offer.ByteSize();
Length_message = BufSize + Message_Header_Size;
Message->PayloadLength_of_Payload = BufSize;
PayloadBuffer = new char[BufSize];
Offer.SerializeToArray(PayloadBuffer, BufSize);
in that case, I met some errors. but I cannot understand it.
that error is as follows:
#0 std::string::size (this=0xcd21c0)
at /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntoarmeabi/arm-unknown-nto-qnx6.5.0eabi/pic/libstdc++-v3/include/bits/basic_string.h:624
624 /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntoarmeabi/arm-unknown-
nto-qnx6.5.0eabi/pic/libstdc++-v3/include/bits/basic_string.h: No such file or d
irectory.
in /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntoarmeabi/arm-unkno
wn-nto-qnx6.5.0eabi/pic/libstdc++-v3/include/bits/basic_string.h
(gdb) bt
#0 std::string::size (this=0xcd21c0)
at /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntoarmeabi/arm-unknown-n
to-qnx6.5.0eabi/pic/libstdc++-v3/include/bits/basic_string.h:624
#1 0x0067d6b0 in google::protobuf::internal::WireFormatLite::StringSize ()
#2 0x0063ecd0 in Offer_event::ByteSize ()
#3 0x00404f18 in AnalysisCmdC_Actor::TestGPB ()
from C:/QNX650/target/qnx6/armle-v7/lib/libc.so.3
#11 0x0004201a in ?? ()
Cannot access memory at address 0x0
Current language: auto; currently c++
(gdb)
I don't know why the ByteSize has a problem.
If i delete the string part, it works well.
I think usage of string is problem.
what's the problem?
Related
I came across below code for walking backtrace
struct stack_frame {
struct stack_frame *prev;
void *return_addr;
} __attribute__((packed));
typedef struct stack_frame stack_frame;
__attribute__((noinline, noclone))
void backtrace_from_fp(void **buf, int size)
{
int i;
stack_frame *fp;
__asm__("movl %%ebp, %[fp]" : /* output */ [fp] "=r" (fp));
for(i = 0; i < size && fp != NULL; fp = fp->prev, i++)
buf[i] = fp->return_addr;
}
the reason behind looking for this code is we are using a 3rd party malloc hook hence don't want to use backtrace which again allocates memory. Above doesn't work for x86_64 and I modified asm statement to
__asm__("movl %%rbp, %[fp]" : /* output */ [fp] "=r" (fp));
I get crash
(gdb) bt
#0 backtrace_from_fp (size=10, buf=<optimized out>) at src/tcmalloc.cc:1910
#1 tc_malloc (size=<optimized out>) at src/tcmalloc.cc:1920
#2 0x00007f5023ade58d in __fopen_internal () from /lib64/libc.so.6
#3 0x00007f501e687956 in selinuxfs_exists () from /lib64/libselinux.so.1
#4 0x00007f501e67fc28 in init_lib () from /lib64/libselinux.so.1
#5 0x00007f5029a32503 in _dl_init_internal () from /lib64/ld-linux-x86-64.so.2
#6 0x00007f5029a241aa in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#7 0x0000000000000001 in ?? ()
#8 0x00007fff22cb8e24 in ?? ()
#9 0x0000000000000000 in ?? ()
(gdb)
(gdb) p $rbp
$2 = (void *) 0x7f501e695f37
(gdb) p (stack_frame *)$rbp
$3 = (stack_frame *) 0x7f501e695f37
(gdb) p *$3
$4 = {prev = 0x69662f636f72702f, return_addr = 0x6d6574737973656c}
(gdb) x /1xw 0x69662f636f72702f
0x69662f636f72702f: Cannot access memory at address 0x69662f636f72702f
(gdb) fr
#0 backtrace_from_fp (size=10, buf=<optimized out>) at src/tcmalloc.cc:1910
1910 in src/tcmalloc.cc
(gdb)
Am I missing something ?. Any help on how can I reconstruct the same via code ?.
Am I missing something ?
The code you referenced assumes the compiled code is using frame pointer register chain.
This was the default on (32-bit) i*86 up until about 5-7 years ago, and has not been the default on x86_64 since ~forever.
The code will most likely work fine in non-optimized builds, but will fail miserably with optimization on both 32-bit and 64-bit x86 platforms using non-ancient versions of the compiler.
If you can rebuild all code (including libc) with -fno-omit-frame-pointer, then this code will work most of the time (but not all the time, because libc may have hand-coded assembly, and that assembly will not have frame pointer chain).
One solution is to use libunwind. Unfortunately, using it from inside malloc can still run into a problem, if you (or any libraries you use) also use dlopen.
I am getting a segmentation fault that is internal to malloc. Here is the trace of the error via gdb (Note: everything frome frame 4 and above is my code).
#0 0xf7d109dd in _int_malloc (av=av#entry=0xf7e45420 <main_arena>, bytes=bytes#entry=100)
at malloc.c:3697
#1 0xf7d12358 in __GI___libc_malloc (bytes=100) at malloc.c:2888
#2 0xf7efb4a5 in operator new(unsigned int) () from /usr/lib/libstdc++.so.6
#3 0xf7efb5ab in operator new[](unsigned int) () from /usr/lib/libstdc++.so.6
#4 0x0804f295 in GetDataFromMem (fileAddr=1744, size=-1) at ../userprog/exception.cc:709
#5 0x0804ec9d in ExecSC (bufAddr=1744, ptrAddr=2912) at ../userprog/exception.cc:578
#6 0x0804dde9 in ExceptionHandler (which=SyscallException) at ../userprog/exception.cc:191
#7 0x08051585 in Machine::RaiseException (this=0x805b8c8, which=SyscallException, badVAddr=0)
at ../machine/machine.cc:109
#8 0x08052ee3 in Machine::OneInstruction (this=0x805b8c8, instr=0x80628e8) at ../machine/mipssim.cc:535
#9 0x080519d0 in Machine::Run (this=0x805b8c8) at ../machine/mipssim.cc:40
#10 0x0804e74f in ForkBootStrap (val=0) at ../userprog/exception.cc:462
#11 0x08054338 in ThreadRoot ()
#12 0x00000000 in ?? ()
The line in my code that resulted in the fault:
int vpn = fileAddr / PageSize;
int offset = fileAddr % PageSize;
int counter = 0;
bool nullhit = false;
char *buf;
if (size == -1)
{
int curSize = DEF_BUF_LEN; //100
buf = new char[curSize]; //SEGFAULT
The exact line where the segmentation fault occurred (within malloc code):
3687 else
3688 {
3689 size = chunksize (victim);
3690
3691 /* We know the first chunk in this bin is big enough to use. */
(gdb)
3692 assert ((unsigned long) (size) >= (unsigned long) (nb));
3693
3694 remainder_size = size - nb;
3695
3696 /* unlink */
3697 unlink (victim, bck, fwd); //SEGFAULTS HERE
3698
3699 /* Exhaust */
3700 if (remainder_size < MINSIZE)
3701 {
(gdb)
3702 set_inuse_bit_at_offset (victim, size);
3703 if (av != &main_arena)
3704 victim->size |= NON_MAIN_ARENA;
3705 }
3706
3707 /* Split */
3708 else
3709 {
3710 remainder = chunk_at_offset (victim, nb);
3711
(gdb)
3712 /* We cannot assume the unsorted list is empty and therefore
3713 have to perform a complete insert here. */
3714 bck = unsorted_chunks (av);
3715 fwd = bck->fd;
3716 if (__builtin_expect (fwd->bk != bck, 0))
3717 {
3718 errstr = "malloc(): corrupted unsorted chunks 2";
3719 goto errout;
3720 }
3721 remainder->bk = bck;
The values of victim, bck, and fwd in unlink are respectively :
(gdb) p victim
$6 = (mchunkptr) 0x805c650
(gdb) p bck
$7 = (mchunkptr) 0xffffffff
(gdb) p fwd
$8 = (mchunkptr) 0xf7e454e8 <main_arena+200>
I am not really sure what the causes for this are. Any insight is appreciated.
Here is the backtrace of gdb,
Program terminated with signal 11, Segmentation fault.
#0 0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
(gdb) bt
#0 0xb7e78830 in Gtk::Widget::get_width () from /usr/lib/libgtkmm-2.4.so.1
#1 0x08221d5d in sigc::bound_mem_functor0<bool, videoScreen>::operator() (this=0xb1c04714)
at /usr/include/sigc++-2.0/sigc++/functors/mem_fun.h:1787`enter code here`
#2 0x08221d76 in sigc::adaptor_functor<sigc::bound_mem_functor0<bool, videoScreen> >::operator() (this=0xb1c04710)
at /usr/include/sigc++-2.0/sigc++/adaptors/adaptor_trait.h:251
#3 0x08221d96 in sigc::internal::slot_call0<sigc::bound_mem_functor0<bool, videoScreen>, bool>::call_it (rep=0xb1c046f8)
at /usr/include/sigc++-2.0/sigc++/functors/slot.h:103
#4 0xb7b1ed35 in ?? () from /usr/lib/libglibmm-2.4.so.1
#5 0xb73c6bb6 in ?? () from /usr/lib/libglib-2.0.so.0
#6 0xb28ff1f8 in ?? ()
#7 0xb647479c in __pthread_mutex_unlock_usercnt () from /lib/libpthread.so.0
#8 0xb73c6446 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#9 0xb73c97e2 in ?? () from /usr/lib/libglib-2.0.so.0
#10 0xb3d11af8 in ?? ()
#11 0x00000000 in ?? ()
I figured out the line of crash,here is the code around that line.
1:currPicLoaded = 1;
2:int status = -1;
3:zoomedPicWidth = drawVideo1->get_width();
I figured out that above line is 3 is the cause of crash, but this line execute 5 times before crash.So I do not know why it does crash at 6th time.
PS : Above line of code is with in a thread which run continuously.
Any help is more than welcome :)
how should I proceed
Your very first step should be to find out which instruction caused the SIGSEGV. Do this:
(gdb) x/i $pc
The most likely cause is that your drawVideo1 object is either dangling (has been deleted), or is corrupt in some other way.
Since you are apparently on Linux (you didn't say, but you should always say), the first tool to reach for for debugging "strange" problems like this is Valgrind.
This is the line that is causing the crash :
if (size <= 0)
return;
if (data)
{
std::string sData = std::string((char*)data, size);
buffer += sData; <-- This is the line causing crash
processBuffer();
}
else
return;
Here is the stack trace:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1282016352 (LWP 27952)]
0x002b48ec in memcpy () from /lib/tls/libc.so.6
(gdb) bt
#0 0x002b48ec in memcpy () from /lib/tls/libc.so.6
#1 0x001fea31 in std::string::_Rep::_M_clone () from /usr/lib/libstdc++.so.6
#2 0x001fef2e in std::string::reserve () from /usr/lib/libstdc++.so.6
#3 0x001ff83d in std::string::append () from /usr/lib/libstdc++.so.6
#4 0x001ff9e2 in std::string::operator+= () from /usr/lib/libstdc++.so.6
#5 0x003fc6c8 in StreamDecoder::StreamDecoderEncoder::addData
at src/StreamDecoder.cpp:171
I have verified that data is not empty and buffer is a string declared as a private member variable of that class.
I do not know why there is a segfault on memcpy. What could have gone wrong here ?
I had this problem working on a school project a few months back... if a string gets massive, it can cause a segfault. Try using something like an ostringstream instead.
I am trying to port some Python ctypes code from a Windows-specific program to link with a Linux port of my library. The shortest Python code sample that describes my problem is shown below. When I try to execute it, I receive a segmentation fault in examine_arguments() in Python. I placed a printf statement in my library at the crashing function call, but it is never executed, which leads me to think the problem is in the ctypes code.
import ctypes
avidll = ctypes.CDLL("libavxsynth.so")
class AVS_Value(ctypes.Structure, object):
def __init__(self, val=None):
self.type=ctypes.c_short(105) # 'i'
self.array_size = 5
self.d.i = 99
class U(ctypes.Union):
_fields_ = [("c", ctypes.c_void_p),
("b", ctypes.c_long),
("i", ctypes.c_int),
("f", ctypes.c_float),
("s", ctypes.c_char_p),
("a", ctypes.POINTER(AVS_Value))]
AVS_Value._fields_ = [("type", ctypes.c_short),
("array_size", ctypes.c_short),
("d", U)]
avs_create_script_environment = avidll.avs_create_script_environment
avs_create_script_environment.restype = ctypes.c_void_p
avs_create_script_environment.argtypes = [ctypes.c_int]
avs_set_var = avidll.avs_set_var
avs_set_var.restype = ctypes.c_int
avs_set_var.argtypes = [ctypes.c_void_p, ctypes.c_char_p, AVS_Value]
env = avs_create_script_environment(2)
val = AVS_Value()
res = avs_set_var(env, b'test', val)
My library has the following in its headers, and a plain-C program doing what I describe above (calling create_script_environment followed by set_var) runs fine. Looking at logging information my library is putting onto the console, the crash happens when I try to enter avs_set_var.
typedef struct AVS_ScriptEnvironment AVS_ScriptEnvironment;
typedef struct AVS_Value AVS_Value;
struct AVS_Value {
short type; // 'a'rray, 'c'lip, 'b'ool, 'i'nt, 'f'loat, 's'tring, 'v'oid, or 'l'ong
// for some function e'rror
short array_size;
union {
void * clip; // do not use directly, use avs_take_clip
char boolean;
int integer;
float floating_pt;
const char * string;
const AVS_Value * array;
} d;
};
AVS_ScriptEnvironment * avs_create_script_environment(int version);
int avs_set_var(AVS_ScriptEnvironment *, const char* name, AVS_Value val);
I tried backtracing the call from GDB, but I don't understand how to interpret the results nor really much about using GDB.
#0 0x00007ffff61d6490 in examine_argument () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#1 0x00007ffff61d65ba in ffi_prep_cif_machdep () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#2 0x00007ffff61d3447 in ffi_prep_cif () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#3 0x00007ffff61c7275 in _ctypes_callproc () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#4 0x00007ffff61c7aa2 in PyCFuncPtr_call.2798 () from /usr/lib/python2.7/lib-dynload/_ctypes.so
#5 0x00000000004c7c76 in PyObject_Call ()
#6 0x000000000042aa4a in PyEval_EvalFrameEx ()
#7 0x00000000004317f2 in PyEval_EvalCodeEx ()
#8 0x000000000054b171 in PyRun_FileExFlags ()
#9 0x000000000054b7d8 in PyRun_SimpleFileExFlags ()
#10 0x000000000054c5d6 in Py_Main ()
#11 0x00007ffff68e576d in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6
#12 0x000000000041b931 in _start ()
I'm at a loss as to how to approach this problem. I've looked at the details of the calling types, but I don't see anything obviously incorrect there. Am I falling into any platform-specific usages of types?
Edit It seems there's a problem with 32-bit vs 64-bit architectures in the ctypes module. When I tested this again with a 32-bit build of my library and 32-bit Python, it ran successfully. On 64-bit, it segfaults at the same place.
Try using c_void_p for the opaque AVS_ScriptEnvironment*:
avs_create_script_environment.restype = c_void_p
and:
avs_set_var.argtypes=[c_void_p,ctypes.c_char_p,AVS_Value]