Delta V Software Forums

Posted: **Sun Mar 24, 2013 12:22 pm**

Hi Jarl,

I'm not sure if I should file this as a bug or to the wish list (so it goes here).

In my environment I build RCF as a shared library with a specific set of configuration macros.
Later on I use RCF to link my executables against it.
I've noticed that in case I do not use exactly the same set of configuration macros in respect to serialization (for example omitting boost.serialization) this surely leads to a segmentation violation due to illegal use of a NULL pointer.

You mention this in your documentation but I would like to add some extra guards to prevent this from happening because I find it difficult to track the error back to the root cause.
One solution I could imagine of is to add some symbols to the library that would force the same set of configuration macros (either during the linking process or during initialization of RCF).

Do you have a best practice for this problem ?

Regards,

Volker

Posted: **Mon Mar 25, 2013 4:39 am**

First off, I'm leaning towards just throwing an exception, instead of dereferencing the NULL pointer... Do you have a stack trace of the null pointer?

Triggering a linker error to detect mismatches at build-time, is definitely a good idea too - I'll have a look at what we can do there.

Posted: **Mon Mar 25, 2013 4:10 pm**

System configuration : Ubuntu 12.04 x86_64, g++ 4.6.3, RCF 2.0.0.2670, boost 1.52.0

Fortunately the call stack is astonishingly flat ...

Code: Select all


Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7120530 in RCF::ClientStub::init (this=0x69d7b0, interfaceName=..., fnId=1, rcs=RCF::Twoway) at Marshal.cpp:145
145	            mpParameters->write(mOut);
(gdb) where
#0  0x00007ffff7120530 in RCF::ClientStub::init (this=0x69d7b0, interfaceName=..., fnId=1, rcs=RCF::Twoway) at Marshal.cpp:145
#1  0x000000000045cae6 in echo::RcfClient<echo::I_ECHO>::echo() ()
#2  0x00000000004397c2 in main ()
(gdb) print mpParameters
$1 = (RCF::I_Parameters *) 0x0
(gdb)

I removed the configuration macro 'RCF_USE_BOOST_SERIALIZATION', so only 'RCF_USE_SF_SERIALIZATION' remains defined.

Posted: **Tue Mar 26, 2013 10:30 am**

Due to how the RCF_USE_BOOST_SERIALIZATION define is used, it's difficult to detect a mismatch at runtime. However, I've added code to the RCF initialization functions to trigger a linker error if there there is a mismatch, and that should take care of things.

We should have a new build out for you, in the next couple of days.

Delta V Software Forums

Configuration macro mismatch leads to ungracious termination

Configuration macro mismatch leads to ungracious termination

Re: Configuration macro mismatch leads to ungracious termina

Re: Configuration macro mismatch leads to ungracious termina

Re: Configuration macro mismatch leads to ungracious termina