C++ backtrace with this=0x0 in various frames

3
votes

I have a program in a mips multicore system and I get a backtrace from core really hard to figure out (at least for me) , I suppose that maybe one of the other cores write to mem but not all the stack is corrupted what makes it more confusing for me.

In frame #2 this is NULL and in frame #0 this is NULL too (the cause of the core-dump).

This is (part) the backtrace:

#0  E::m (this=0x0, string=0x562f148 "", size=202) at E.cc:315
#1  0x00000000105c773c in P::e (this=0x361ecd00, string=0x562f148 "", size=202, offset=28) at P.cc:137
#2  0x00000000105c8c5c in M::e (this=0x0, id=7 '\a', r=2, string=0x562f148 "", size=202, oneClass=0x562f148 "", secondClass=0x14eff439 "", 
offset=28) at M.cc:75                                         
#3  0x0000000010596354 in m::find (this=0x4431fd70, string=0x562f148 "", size=202, oneClass=0x14eff438 "", secondClass=0x14eff439 "", 
                   up=false) at A.cc:458                    
#4  0x0000000010597364 in A::trigger (this=0x4431fd70, triggerType=ONE, string=0x562f148 "", size=0, up=true) at A.cc:2084
#5  0x000000001059bcf0 in A::findOne (this=0x4431fd70, index=2, budget=0x562f148 "", size=202, up=true) at A.cc:1155
#6  0x000000001059c934 in A::shouldpathNow (this=0x4431fd70, index=2, budget=0x562f148 "", size=202, up=false, startAt=0x0, short=)
   at A.cc:783    
#7  0x00000000105a385c in A::shouldpath (this=0x4431fd70, index=2, rbudget=, rsize=, up=false,
                   direct=) at A.cc:1104

About the m::find function


    442 m_t m::find(unsigned char const *string, unsigned int size,
    443                                           hClass_t *hClass, h_t *fHClass,
    444                                           bool isUp) {  
    445   
    446                                                                            
    447   const Iterator &it=arr_[getIndex()]->getSearchIterator((char const*)value, len);
    448                                                            
    449   unsigned int const offset = value - engine_->getData();  
    450                                                                                        451   int ret=UNKNOWN;            
    452   M *p;                    
    453   for(const void* match=it.next(); 
    454       ret == UNKNOWN && match != NULL;                                                 
    455       match = it.next()){ 
    456     p = (M*)match;   
    457 if(p->needMore()){            
    458       ret = p->e(id_, getIndex(), value, len, hClass, fHClass, offset);
2
c++mips
Could you include the code for E::m? – user7116
This code is simple , just at init a member is trying to be checked: int i; bool evaluating=true; if(member_) { .... } – ramp
The core happens at the <pre> 'if(member_)' </pre> – ramp
The interesting function is m::find. Can you show the code (with line numbers?) Please edit your question, don't add code to comments. – n. 1.8e9-where's-my-share m.
Note that debuggers are usually not perfect in following the calling conventions, especially when the compiler is newer than the debugger. – PlasmaHH

2 Answers

6
votes

this=0x0 can actually happen pretty easily. For example:

E *instance = NULL;
instance->method();

this will be NULL within method.

There's no need to assume that the memory has been corrupted or the stack has been overwritten. In fact, if the rest of the stack's contents seem to make sense (and you seem to think that they do), then the stack is probably fine.

Instead of necessarily looking for memory corruption, check your logic to see if you have an uninitialized (NULL) pointer or reference.

1
votes

Not being able to see all the code, its kind-of difficult to imagine what's happening. Could you also add the code for M::e() and P::e() or at least the important parts.

Something that might just solve everything is to add a NULL check, as follows in m::find():

456     p = (M*)match;   
        if(!p) { return; /* or do whatever */ }
457     if(p->needMore()){            
458       ret = p->e(id_, getIndex(), value, len, hClass, fHClass, offset);

If p were NULL, I would have expected it to have crashed calling p->needMore(), but depending on what that method does, it may not crash.