这个 gdb 核心是否因违反 ODR（一个定义规则）而发生？

Question

I was working with code to include rapidjson headers in my server application. When I compiled, it was ok. but when some other library part in the application was running, it turned out to be dead with gdb core file.

#0  0x00007f36c614e922 in rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator>::Malloc (this=0x7f36a4037700, size=256) at ../../common/include/rapidjson/allocators.h:321
321             RAPIDJSON_NOEXCEPT_ASSERT(shared_->refcount > 0);
...
#17 0x00007f36c57999cb in dbgw::sql::NBaseTPreparedStatement::executeQuery (this=<optimized out>) at ../../src/dbgw/dbgw3/sql/nbase_t/NBaseTPreparedStatement.cpp:85

I realized the dynamic library actually has rapidjson in it already and I solved by adding namespace to newly added rapidjson after I saw this below

https://rapidjson.org/group___r_a_p_i_d_j_s_o_n___c_o_n_f_i_g.html#ga743a79d3af927391fe3eb5c979136899

So what I am curious about is...

Q1.Is this happened because multiple inclusions violated ODR, shared library unexpectedly (because of overwritten symbol stuff) runned newly added (maybe different version of) rapidjson code, and it resulted to throw exception?

Q2. Can I assume the reason that previous declaration error didn't occur while compile is that it was "shared" library and only linked when the application is run?(unlike static library)

Answer 1

Is this happened because multiple inclusions violated ODR, shared library unexpectedly (because of overwritten symbol stuff) runned newly added (maybe different version of) rapidjson code, and it resulted to throw exception?

It's possible that that is the cause, but you have supplied far too few details to tell.

Can I assume the reason that previous declaration error didn't occur while compile is that it was "shared" library and only linked when the application is run?(unlike static library)

Probably not. "Previous declaration" is a compile time error, and you wouldn't expect one here (with separate translation units).

What you are probably asking is "why didn't multiple definition link error happen?". If so, yes: it is not an error to have the same symbol definition in the main executable and one (or more) shared library it is using. This is in fact very common, and what allows an application to use a different malloc implementation despite having malloc inside libc .