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

Question

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);

Answer 1

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.

Answer 2

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.