Eclipse CDT / GDB listing/jumping to code not compiled within the binary

Eclipse version: Mars.2 (4.5.2) CDT version: 8.8.1 GDB version: 7.4.1

For the past couple of working days, I've been experiencing some mildly astounding behaviour of Eclipse and GDB, specifically the CDT.

When debugging my application (this specific one, I haven't been able to reproduce this behaviour w/ other applications - even calling the same functions!), everything is fine to a certain point and all of a sudden, no matter which function I call from a specific file, I'll always land in a function of tinyxml2 - which isn't even compiled in to the library I'm debugging. (Code will follow shortly).

Furthermore, the debugger (Eclipse view) shows at max 3 frames in the stack, the bottom-most frame is always 0x0 - suggesting stack corruption.

GDB backtrace:

backtrace
#0  tinyxml2::XMLAttribute::QueryFloatValue (this=0xfee0000, value=0x0) at ../../common/xmlreader/tinyxml2.cpp:1414
#1  0x00000000 in ?? ()

Even more confusing is the now apparent existance of variables (more specifically pointers) that weren't there before:

Here is the backtrace from one statement before calling the offending code:

#0  LibMdxDataset::OpenCanCommunicationsPort(struct {...} *) (tParaLoad=0xbfffef14) at libmdxdataset.cpp:1102
#1  0x0fed2024 in LibMdxDataset::Download(struct {...} *) (tParaLoad=0xbfffef14) at libmdxdataset.cpp:952
#2  0x0fed10a0 in LibMdxDataset::UpdateTerminal (fpUpdateProc=0x1000ed74 <UpdaterTest::UpdaterDelegate::updaterCallback(int, wchar_t const*, int)>, wcParam=0x1003f50c L"CAN:[redacted], EXTENDED:[redacted], TXID:[redacted], RXID:[redacted], DS:[redacted]", wcFileName=0x1003f5e4 L"[redacted]", hAbortEvent=0x0) at libmdxdataset.cpp:685
#3  0x10010a68 in UpdaterTest::ModuleAbstraction::ModuleMdx::RetrieveDataset (callback=0x1000ed74 <UpdaterTest::UpdaterDelegate::updaterCallback(int, wchar_t const*, int)>, parameters=..., filename=..., abortEvent=0x0) at ModuleAbstraction.h:133
#4  0x10010050 in UpdaterTest::UpdaterDelegate::startUpdate (this=0xbffff904, parameters=..., filename=..., abortEvent=0x0) at UpdaterDelegate.cpp:178
#5  0x1000d6e0 in UpdaterTest::UpdaterTestMain (argCount=1, argVector=0xbffffbd4) at Main.cpp:202
#6  0x1000e2c0 in main (argCount=1, argVector=0xbffffbd4) at Main.cpp:327

---

Now that I've explained my problem (if you feel I haven't, or have more questions, please let me know so I can update the OP), I'd like to get to showing some code.

Note: Some file names, function calls and/or parameters may be redacted or changed completely.

Starting with the code called directly before this behaviour occurs:

bool OpenCanCommunicationsPort(UpdateParams* params) {

#ifdef __linux__
        // We're on a Linux box here
        // This means we need to set the CAN mask parameters while opening the CAN port.
        // This part is incompatible with Windows...
        char canPort[8] = {0};
        //(int)params->wcCan_Bus
        sprintf(&canPort[0], "can%i", (int)params->wcCan_Bus);
        *params->hCanDev = canInit(&canPort[0], params->ulCanRcvID, 0);
                                ^ -- error occurs here

#elif defined(_WIN32)
        // ... snip ...

The code that is supposed to execute is the following:

int canInit(const char *canChannel, int canId, int canMask) {
    // ... snip ...
}

Instead, GDB shows the following code:

  ˯ -- starting here
XMLError XMLAttribute::QueryFloatValue( float* value ) const
{
    if ( XMLUtil::ToFloat( Value(), value )) {
        return XML_SUCCESS;
    }
    return XML_WRONG_ATTRIBUTE_TYPE;
}

Just to prove that tinyxml is not compiled in to the binary, here's an excerpt from the Makefile:

libbla.so.1.0.0: libbla.o w2psx.o candevice.o cantreiber.o
    ${CXX} $^ -o $@ ${LDFLAGS}

Also, here's the output of ldd:

linux-vdso32.so.1 =>  (0x00100000)
librt.so.1 => /lib/powerpc-linux-gnu/librt.so.1 (0x0ffd7000)
libutilities.so => /opt/redacted_dir/lib/libutilities.so (0x0ffa7000)
libredacted1.so => /opt/redacted_dir/lib/libredacted1.so (0x0ff3c000)
libredacted2.so => /opt/redacted_dir/lib/libredacted2.so (0x0ff02000)
libredacted3dataset.so => /opt/redacted_dir/lib/libredacted3dataset.so (0x0fec3000)
libredacted4.so => /opt/redacted_dir/lib/libredacted4.so (0x0fe84000)
libstdc++.so.6 => /usr/lib/powerpc-linux-gnu/libstdc++.so.6 (0x0fd34000)
libm.so.6 => /lib/powerpc-linux-gnu/libm.so.6 (0x0fc66000)
libgcc_s.so.1 => /lib/powerpc-linux-gnu/libgcc_s.so.1 (0x0fc2f000)
libc.so.6 => /lib/powerpc-linux-gnu/libc.so.6 (0x0fa93000)
libpthread.so.0 => /lib/powerpc-linux-gnu/libpthread.so.0 (0x0fa58000)
/lib/ld.so.1 (0x20607000)
libcurl.so.4 => /usr/lib/libcurl.so.4 (0x0f9ce000)
libminizip.so.1 => /opt/redacted_dir/lib/libminizip.so.1 (0x0f9a4000)
libcares.so.2 => /usr/lib/powerpc-linux-gnu/libcares.so.2 (0x0f973000)
libssl.so.1.0.0 => /usr/lib/powerpc-linux-gnu/libssl.so.1.0.0 (0x0f90d000)
libcrypto.so.1.0.0 => /usr/lib/powerpc-linux-gnu/libcrypto.so.1.0.0 (0x0f732000)
libz.so.1 => /lib/powerpc-linux-gnu/libz.so.1 (0x0f6fb000)
libdl.so.2 => /lib/powerpc-linux-gnu/libdl.so.2 (0x0f6d7000)

---

A tidbit more to the structure of the application: The main application has multiple (custom) libraries linked to it, which contain the "actual" payloads and protocols. The application itself is essentially just a Frankenstein Machine giving life to the code when it's needed.

[application]
    --includes--> libutils.so
    --includes--> libupdater1.so
    --includes--> libupdater2.so
    --includes--> <...>

This leads me to multiple theories.

Theory 1

My first theory (as I've mentioned above) is that the stack is being corrupted somehow. I came to this conclusion due to the stack mysteriously disappearing and starting at the address 0x0. Further "proving" this theory are the symptom itself: pointing to an address it shouldn't even know of.

What leads me to believe this is not the case, however, is that the symptoms are the same. They are reproducible within the application. Re-building the application and all libs does not lead to differing results! Also, both before and after GDB skips to the weird position, I've checked the variables within the scope of the respective stack frame, none of them were uninitialised or had weird values.

Theory 2

My second theory is that the libraries are somehow missing from the target device/not up-to-date w/ the versions on the development system. I can practically immediately rule this out, however, as I've built a build script which automatically packs and deploys the new libraries (only the libraries, not the application as it is deployed with Eclipse) to the target.

---

Does this behaviour fit with one of my theories? What can cause this behaviour? Is this common, and what is a (preferably easy) fix?

I'm not too experienced with C++ (coming up on a year's worth of true "experience") and/or the tools surrounding it.