Unexpected class instance : IceStorm 3.4.1 / Mac OS 10.6.5

Hello,
Im trying to port a windows application to Mac OS but i can't explain the following exception :

on the publisher side i have :

-! 09/08/10 08:53:55.846 Node1Server: warning: dispatch exception: Exception.cpp:30: Ice::UnexpectedObjectException:
   unexpected class instance of type `::O3SRemote::SynchronizedDictionary'; expected instance of type `::O3SRemote::SynchronizedDictionary':
   expected element of type `::O3SRemote::SynchronizedDictionary' but received '::O3SRemote::SynchronizedDictionary
   identity: 2DB70D48-002F-4834-8750-D3C279E63C5F
   facet: 
   operation: update

on the subscriber side i have :

Subscriber: 0xc565f0 97C94905-5D2A-4BBA-8206-72608B15CFF1: subscriber errored out: OutgoingAsync.cpp:680: Ice::UnknownLocalException:
   unknown local exception:
   Exception.cpp:30: Ice::UnexpectedObjectException:
   unexpected class instance of type `::O3SRemote::SynchronizedDictionary'; expected instance of type `::O3SRemote::SynchronizedDictionary':
   expected element of type `::O3SRemote::SynchronizedDictionary' but received '::O3SRemote::SynchronizedDictionary
     libIce.34.dylib: IceInternal::Ex::throwUOE(std::string const&, std::string const&)
     libo3s.core.dictionary.synchronizer.dylib: O3SRemote::__patch__SynchronizedDictionaryPtr(void*, IceInternal::Handle<Ice::Object>&)
     libIce.34.dylib: IceInternal::BasicStream::patchPointers(int, std::_Rb_tree_const_iterator<std::pair<int const, IceInternal::Handle<Ice::Object> > >, std::_Rb_tree_iterator<std::pair<int const, std::vector<IceInternal::BasicStream::PatchEntry, std::allocator<IceInternal::BasicStream::PatchEntry> > > >)
     libIce.34.dylib: IceInternal::BasicStream::read(void (*)(void*, IceInternal::Handle<Ice::Object>&), void*)
     libIce.34.dylib: IceInternal::BasicStream::readPendingObjects()
     libo3s.core.dictionary.synchronizer.dylib: O3SRemote::VariableDictionaryObserver::___update(IceInternal::Incoming&, Ice::Current const&)
     libo3s.core.dictionary.synchronizer.dylib: O3SRemote::VariableDictionaryObserver::__dispatch(IceInternal::Incoming&, Ice::Current const&)
     libIce.34.dylib: IceInternal::Incoming::invoke(IceInternal::Handle<IceInternal::ServantManager> const&)
     libIce.34.dylib: Ice::ConnectionI::invokeAll(IceInternal::BasicStream&, int, int, unsigned char, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&)
     libIce.34.dylib: Ice::ConnectionI::dispatch(IceUtil::Handle<Ice::ConnectionI::StartCallback> const&, std::vector<IceInternal::Handle<IceInternal::OutgoingAsyncMessageCallback>, std::allocator<IceInternal::Handle<IceInternal::OutgoingAsyncMessageCallback> > > const&, unsigned char, int, int, IceInternal::Handle<IceInternal::ServantManager> const&, IceInternal::Handle<Ice::ObjectAdapter> const&, IceInternal::Handle<IceInternal::OutgoingAsync> const&, IceInternal::BasicStream&)
     libIce.34.dylib: Ice::ConnectionI::message(IceInternal::ThreadPoolCurrent&)
     libIce.34.dylib: IceInternal::ThreadPool::run(IceUtil::Handle<IceUtil::Thread> const&)
     libIce.34.dylib: IceInternal::ThreadPool::EventHandlerThread::run()
     libIceUtil.34.dylib: IceUtil::Thread::start(unsigned long)
     libSystem.B.dylib: _pthread_start()
     libSystem.B.dylib: thread_start() retry: 0/0

It's strange because it tells me that the expected and received elements type are different, but it seems that they are the same.

Thanks for your help if you have any idea,
Laurent

Thats a strange error. It means that a dynamic cast to that type failed, even though the object is apparently of the required type. The most likely cause of such errors is a build flags problem. You should your build flags against those used when building the Ice library.

Thank you for your answer,
I will check the flags.
Laurent

Hi, I'm back.

I couldn't solve my problem.
I didn't find the wrong option.

But, I can't explain why the classical RPC works well (even from windows to mac os), but not the publisher / subscriber.

Thanks
Laurent

For more assistance you'll have to provide more information. For example, the build flags used. Better yet, try and produce a self-contained example that demonstrates the problem (most of the time when producing such an example you'll discover the solution). Usually the simplest way to produce such an example is to modify one of the working IceStorm demos that accompanies Ice.

compiler flags

As Matthew suggested, we fixed a similar problem by making the compiler options consistent. Our CMake process built parts of the project with a different BUILD_TYPE which in turn caused the different compiler options (-02 I believe).