[Signals] Regressions/crashes on Linux and CodeWarrior
Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs): Run output []: /boost/head-regression/boost/boost/test/minimal.hpp(127): exception "signal: memory access violation" caught in function: 'int main(int, char **)' **** Testing aborted. **** 1 error detected EXIT STATUS: 201 Same for CodeWarrior 8.3 on Windows. Could somebody with access to the environment take a look at it, please? -- Aleksey Gurtovoy MetaCommunications Engineering
On Tue, Sep 21, 2004 at 09:12:46PM -0500, Aleksey Gurtovoy wrote:
Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs):
Run output []:
/boost/head-regression/boost/boost/test/minimal.hpp(127): exception "signal: memory access violation" caught in function: 'int main(int, char **)'
**** Testing aborted. **** 1 error detected
EXIT STATUS: 201
Same for CodeWarrior 8.3 on Windows. Could somebody with access to the environment take a look at it, please?
This test: http://www.meta-comm.com/engineering/boost-regression/developer/output/Marti... (TinyUrl: http://tinyurl.com/6xdfa ) shows that if libstdc++'s debug mode is used then the test fails because the debug mode catches an invalid use of a singular iterator. This is probably what is causing the fails in the other toolsets, except that the debug mode doesn't intercept the error and so it results in a crash. jon -- "A woman drove me to drink, I never had the courtesy to thank her." - W.C. Fields
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m2mzzjt5k1.fsf@meta-comm.com...
Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs):
I'm not sure if this is related, but I noticed what I think is a subtle bug in the named_slot_map::insert function in named_slot_map.cpp. The function creates and returns a named_slot_map::iterator object for the new slot that it is inserting. It appears, however, that the 'slot_assigned' flag in the impl part of this object is never initialized (group, last_group, and slot_ are all set up). When the iterator object is returned, a temporary object is constructed from the iterator_impl object, and then the iterator object is returned from the function by value. In debug mode, the MSVC compiler was constructing a second temp iterator from the first temp iterator for its return value, rather than optimizing out the construction of the second temp. When the copy constructor is used for this second temp, it may or may not actually copy the slot_ member (you are at the mercy of whatever happened to be in the memory now occupied by the uninitialized slot_assigned member in the first temp). If slot_assigned ends up as false and slot_ is not copied, you will get an access violation in signal_base::connect_slot because it assumes the iterator returned from insert is valid and immediately derefences it to call set_controlling() on the related connection object. I think there should be an 'it->slot_assigned = true;' somewhere towards the end of named_slot_map::insert, but since slot_assigned is a private member of named_slot_map_iterator::impl, you'd have to make named_slot_map be a friend or else it won't give you access. You could also make the impl object with the constructor that lets you set up all 4 members, rather than default constructing it and assigning the members by hand, but I didn't think through whether or not this method could leak resources in the event of an exception in the insert function. Does it seem like this could be related to the crashes that were showing up? -Dave
On Sep 22, 2004, at 10:59 AM, Dave Deakins wrote:
I think there should be an 'it->slot_assigned = true;' somewhere towards the end of named_slot_map::insert, but since slot_assigned is a private member of named_slot_map_iterator::impl, you'd have to make named_slot_map be a friend or else it won't give you access. You could also make the impl object with the constructor that lets you set up all 4 members, rather than default constructing it and assigning the members by hand, but I didn't think through whether or not this method could leak resources in the event of an exception in the insert function.
Does it seem like this could be related to the crashes that were showing up?
You are absolutely correct. I've corrected the behavior, and all Signals tests now pass on Linux. Thank you! Doug
Dave Deakins writes:
"Aleksey Gurtovoy" <agurtovoy@meta-comm.com> wrote in message news:m2mzzjt5k1.fsf@meta-comm.com...
Half of the signals tests on Linux -- on both Intel and GCC -- crash with access violation; for instance (from http://tinyurl.com/6esxs):
I'm not sure if this is related, but I noticed what I think is a subtle bug in the named_slot_map::insert function in named_slot_map.cpp.
[snip description of the bug that was causing the crash] Dave, Thank you for tracking this down! -- Aleksey Gurtovoy MetaCommunications Engineering
participants (4)
-
Aleksey Gurtovoy -
Dave Deakins -
Doug Gregor -
Jonathan Wakely