I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors. I'm having a very hard time making a small example program to demonstrate this behaviour (but I am working on it :). In the meantime if anyone else has experienced this kind of behaviour or has any information that might help, it would be greatly appreciated. TIA Neal
On Dec 6, 2004, at 4:03 PM, Neal Coombes wrote:
I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors.
Which version of Boost are you using? We fixed one such bug between 1.31.0 and 1.32.0. Doug
Doug Gregor wrote:
On Dec 6, 2004, at 4:03 PM, Neal Coombes wrote:
I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors.
Which version of Boost are you using? We fixed one such bug between 1.31.0 and 1.32.0.
Sorry, I should have mentioned that :) I am using 1.31, I've asked our admins to install 1.32 for other problems we've been having with signals and pthread. I'll try it with that and report back. (Any chance any problems with pthread were fixed too? :) Thanks, Neal
Doug Gregor wrote:
Which version of Boost are you using? We fixed one such bug between 1.31.0 and 1.32.0.
Unfortunately upgrading to 1.32 did not fix this bug for me. I'll keep trying to find a simple example, and will put back my work around in the meantime. Thanks, Neal
I'm having a horrible time with a small example program :) In the meantime, I thought I'd post a backtrace. I doubt it will help much, but maybe someone more familiar than I with the signal library will have a clue as to where I might look more carefully. #0 0x00000000 in ?? () #1 0x08351fbf in boost::_mfi::mf0<void, MetaContractPres>::operator() ( this=0x8587c20, p=0x8e76c90) at /opt/app/boost_1_32_0/include/boost-1_32/boost/bind/mem_fn_template.hpp:45 #2 0x08351f4d in boost::_bi::list1<boost::_bi::value<MetaContractPres*>
::operator()<boost::_mfi::mf0<void, MetaContractPres>, boost::_bi::list1<MetaContract*&> > (this=0x8587c28, f=@0x8587c20, a=@0x8046104) at /opt/app/boost_1_32_0/include/boost-1_32/boost/bind.hpp:228 #3 0x08351f18 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, MetaContractPres>, boost::_bi::list1<boost::_bi::value<MetaContractPres*> > ::operator()<MetaContract*> (this=0x8587c20, a1=@0x8046138) at /opt/app/boost_1_32_0/include/boost-1_32/boost/bind/bind_template.hpp:32 #4 0x08351ec9 in boost::detail::function::void_function_obj_invoker1<boost::_bi::bind_t<void, boost::_mfi::mf0<void, MetaContractPres>, boost::_bi::list1<boost::_bi::value<MetaContractPres*> > >, void, MetaContract*>::invoke ( function_obj_ptr= {obj_ptr = 0x8587c20, const_obj_ptr = 0x8587c20, func_ptr = 0x8587c20, data = " "}, a0=0x8cfa3c8) at /opt/app/boost_1_32_0/include/boost-1_32/boost/function/function_template.hpp:128 #5 0x0836def3 in boost::function1<void, MetaContract*, std::allocator<void> >::operator() (this=0x8e7475c, a0=0x8cfa3c8) ---Type <return> to continue, or q <return> to quit--- at /opt/app/boost_1_32_0/include/boost-1_32/boost/function/function_template.hpp:581 #6 0x0836dd01 in boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > ::operator()<boost::signals::detail::connection_slot_pair> (this=0x80462d8, slot=@0x8de1b18) at /opt/app/boost_1_32_0/include/boost-1_32/boost/signals/signal_template.hpp:119 #7 0x0836dc64 in boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > >, boost::signals::detail::named_slot_map_iterator>::dereference (this=0x80462d0) at /opt/app/boost_1_32_0/include/boost-1_32/boost/signals/detail/slot_call_iterator.hpp:68 #8 0x0836dc01 in boost::iterator_core_access::dereference<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > >, boost::signals::detail::named_slot_map_iterator> > (f=@0x80462d0) at /opt/app/boost_1_32_0/include/boost-1_32/boost/iterator/iterator_facade.hpp:516 #9 0x0836dbe2 in boost::iterator_facade<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > >, boost::signals::detail::named_slot_map_iterator>, boost::signals::detail::unusable, boost::single_pass_tr---Type <return> to continue, or q <return> to quit--- aversal_tag, boost::signals::detail::unusable const&, int>::operator* ( this=0x80462d0) at /opt/app/boost_1_32_0/include/boost-1_32/boost/iterator/iterator_facade.hpp:634 #10 0x0836dbc3 in boost::detail::postfix_increment_proxy<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > >, boost::signals::detail::named_slot_map_iterator> ::postfix_increment_proxy ( this=0x8046277, x=@0x80462d0) at /opt/app/boost_1_32_0/include/boost-1_32/boost/iterator/iterator_facade.hpp:144 #11 0x0836bd1c in boost::operator++<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > >, boost::signals::detail::named_slot_map_iterator>, boost::signals::detail::unusable, boost::single_pass_traversal_tag, boost::signals::detail::unusable const&, int> (i=@0x80462d0) at /opt/app/boost_1_32_0/include/boost-1_32/boost/iterator/iterator_facade.hpp:732 #12 0x0836bc51 in boost::last_value<void>::operator()<boost::signals::detail::slot_call_iterator<boost::signals::detail::call_bound1<void>::caller<MetaContract*, boost::function<void ()(MetaContract*), std::allocator<void> > >, boost::signals::detail::named_slot_map_iterator> > (this=0x8cfa884, first=0x80462d0, last=0x8046310) ---Type <return> to continue, or q <return> to quit--- at /opt/app/boost_1_32_0/include/boost-1_32/boost/last_value.hpp:43 #13 0x0836b385 in boost::signal1<void, MetaContract*, boost::last_value<void>, int, std::less<int>, boost::function<void ()(MetaContract*), std::allocator<void> > >::operator() (this=0x8cfa464, a1=0x8cfa3c8) at /opt/app/boost_1_32_0/include/boost-1_32/boost/signals/signal_template.hpp:347 #14 emit signal
Neal Coombes wrote:
I'm having a horrible time with a small example program :)
In the meantime, I thought I'd post a backtrace. I doubt it will help much, but maybe someone more familiar than I with the signal library will have a clue as to where I might look more carefully.
::operator()<boost::_mfi::mf0<void, MetaContractPres>, boost::_bi::list1<MetaContract*&> > (this=0x8587c28, f=@0x8587c20, a=@0x8046104) at /opt/app/boost_1_32_0/include/boost-1_32/boost/bind.hpp:228 228 unwrap(&f, 0)(a[a1_]); (gdb) p f $3 = (mf0<void,MetaContractPres> &) @0x8587c20: {f_ = {__pfn = invalid
In addition, looking through the stack: #2 0x08351f4d in boost::_bi::list1<boost::_bi::value<MetaContractPres*> pointer to member function The destructor for MetaContractPres is called, the destructor for it's base class trackable is called. I can't tell why the signal is not disconnecting (otherwise you'd have the example program by now :) Everything works fine if I disconnect from all signals manually. Is it possible that some of the trackable's connections aren't controlling?? In case it helps: uname -a SunOS dusty 5.9 Generic_112234-08 i86pc i386 i86pc (ie. solaris 2.9 intel) gcc --version gcc (GCC) 3.3.2 ld -V ld: Software Generation Utilities - Solaris Link Editors: 5.9-1.381
On Dec 6, 2004, at 4:03 PM, Neal Coombes wrote:
I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors.
I'm having a very hard time making a small example program to demonstrate this behaviour (but I am working on it :). In the meantime if anyone else has experienced this kind of behaviour or has any information that might help, it would be greatly appreciated.
I now have a test case that exhibits the problem and am looking into the problem. Doug
On Dec 15, 2004, at 5:40 PM, Doug Gregor wrote:
On Dec 6, 2004, at 4:03 PM, Neal Coombes wrote:
I have been experiencing some strange behaviour (on Solaris 2.9 intel) with the signals::trackable object. I'm using it on all my objects that connect to signals and it doesn't seem to disconnect the signals consistently on destroyed objects (these objects are publicly and virtually derived from trackable). I've worked around the problem by manually disconnecting from all signals in the objects destructors.
I'm having a very hard time making a small example program to demonstrate this behaviour (but I am working on it :). In the meantime if anyone else has experienced this kind of behaviour or has any information that might help, it would be greatly appreciated.
I now have a test case that exhibits the problem and am looking into the problem.
Doug
Scratch that. I _don't_ have a test case that exhibits the problem. Even the signals torture test (random_signal_system) isn't detecting any problems. *If* you have some spare time, it might help if you could build the random_signal_system test (in libs/signals/test) from CVS and run it as ./random_signal_system 500 0.01 10000 If the final BOOST_TEST doesn't throw, then we haven't duplicated the problem :( Doug
Doug Gregor wrote:
Scratch that. I _don't_ have a test case that exhibits the problem. Even the signals torture test (random_signal_system) isn't detecting any problems. *If* you have some spare time, it might help if you could build the random_signal_system test (in libs/signals/test) from CVS and run it as
./random_signal_system 500 0.01 10000
If the final BOOST_TEST doesn't throw, then we haven't duplicated the problem :(
I will try this in a spare moment. Thanks, Neal
Doug Gregor wrote:
Scratch that. I _don't_ have a test case that exhibits the problem. Even the signals torture test (random_signal_system) isn't detecting any problems. *If* you have some spare time, it might help if you could build the random_signal_system test (in libs/signals/test) from CVS and run it as
./random_signal_system 500 0.01 10000
If the final BOOST_TEST doesn't throw, then we haven't duplicated the problem :(
I ran this test compiled against both boost 1.31 and boost 1.32 and it appeared to work fine in both (had lots of output that I didn't sift through, I assumed I would have received a failed message if it didn't work). Thanks for trying. I'll take a look at this program and see if there's anything I can do to make it break. I definitely didn't get anywhere with my own test programs. Neal
Doug Gregor wrote:
Scratch that. I _don't_ have a test case that exhibits the problem. Even the signals torture test (random_signal_system) isn't detecting any problems. *If* you have some spare time, it might help if you could build the random_signal_system test (in libs/signals/test) from CVS and run it as
./random_signal_system 500 0.01 10000
If the final BOOST_TEST doesn't throw, then we haven't duplicated the problem :(
I'm just dumb. I didn't even get the file from CVS. Let me get some caffein and I might become more useful :) Neal
Doug Gregor wrote:
Scratch that. I _don't_ have a test case that exhibits the problem. Even the signals torture test (random_signal_system) isn't detecting any problems. *If* you have some spare time, it might help if you could build the random_signal_system test (in libs/signals/test) from CVS and run it as
./random_signal_system 500 0.01 10000
If the final BOOST_TEST doesn't throw, then we haven't duplicated the problem :(
Alright. Finally able to follow basic instructions... The test didn't compile with boost-1.31 which means I must have the right file! It worked fine with 1.32. Thanks, Neal
participants (2)
-
Doug Gregor -
Neal Coombes