boost::bind triggers seg fault if compiled with gcc optimizations
Hello, I'm using boost::bind to bind some member function of class two arguments, making it a nullary function call. If I compile things with any optimizations, then the resulting code causes seg-faults. Without optimizations, everything is fine. Any ideas? Some possible workaround? BTW, boost::lambda::bind results in the same behavior. My versions: gcc 4.1.3 on ubuntu gutsy, boost 1.35.0 Greetings, Sebastian Weber
Sebastian Weber:
Hello,
I'm using boost::bind to bind some member function of class two arguments, making it a nullary function call. If I compile things with any optimizations, then the resulting code causes seg-faults. Without optimizations, everything is fine. Any ideas? Some possible workaround? BTW, boost::lambda::bind results in the same behavior.
My versions: gcc 4.1.3 on ubuntu gutsy, boost 1.35.0
Can you please post the code? Does bind_test.cpp (in libs/bind/test) work when compiled with optimizations, or does it segfault too? Can you post a backtrace of the crash?
Hi Peter! bind_test passes for my compiler. I actually cannot sent you a senseful backtrace, since the compilation in debugging mode always yields a executable which works as it should (even though optimizations are on). Only compiling in release mode with -Ox x>0 yields a crashing executable. Seems like a gcc bug to me, but I thought some Problems like this are known. Attached is the affected code. Greetings, Sebastian Weber On Mon, 2008-04-07 at 14:38 +0300, Peter Dimov wrote:
Sebastian Weber:
Hello,
I'm using boost::bind to bind some member function of class two arguments, making it a nullary function call. If I compile things with any optimizations, then the resulting code causes seg-faults. Without optimizations, everything is fine. Any ideas? Some possible workaround? BTW, boost::lambda::bind results in the same behavior.
My versions: gcc 4.1.3 on ubuntu gutsy, boost 1.35.0
Can you please post the code? Does bind_test.cpp (in libs/bind/test) work when compiled with optimizations, or does it segfault too? Can you post a backtrace of the crash?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Sebastian Weber:
Hi Peter!
bind_test passes for my compiler. I actually cannot sent you a senseful backtrace, since the compilation in debugging mode always yields a executable which works as it should (even though optimizations are on). Only compiling in release mode with -Ox x>0 yields a crashing executable. Seems like a gcc bug to me, but I thought some Problems like this are known. Attached is the affected code.
Nothing wrong with the code... You could try removing the "const" from the const key_type k in the declaration of undo_put. Another thing I see is that your commented-out detail::undo_put stores the property map by value, whereas the bind expression uses ref(rpa). Could this make a difference? Is it possible that the undo action is executed after rpa has been destroyed?
Hi! Aaaahrg, it was actually a problem of objects going out of scope at some other place. Sorry, for suspecting a Bug and thanks a lot for your effort. Greetings, Sebastian Weber On Mon, 2008-04-07 at 17:05 +0300, Peter Dimov wrote:
Sebastian Weber:
Hi Peter!
bind_test passes for my compiler. I actually cannot sent you a senseful backtrace, since the compilation in debugging mode always yields a executable which works as it should (even though optimizations are on). Only compiling in release mode with -Ox x>0 yields a crashing executable. Seems like a gcc bug to me, but I thought some Problems like this are known. Attached is the affected code.
Nothing wrong with the code... You could try removing the "const" from the const key_type k in the declaration of undo_put. Another thing I see is that your commented-out detail::undo_put stores the property map by value, whereas the bind expression uses ref(rpa). Could this make a difference? Is it possible that the undo action is executed after rpa has been destroyed?
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (2)
-
Peter Dimov -
Sebastian Weber