Hello, I hope someone can point me in a new direction for tracking down a segfault. Code that has been running fine for months started seg faulting after a directory reorganization. Valgrind says "Use of uninitialized value of size 4". A simplified version is below. void MyClass:: SomeFunc() { // void f() is a member function of MyClass typedef boost::function<void ()> VoidFunc; VoidFunc vf = boost::bind(&MyClass::f, this); f(); // fine this->f(); // fine; vf(); // segfaults } gcc 3.4.5 on RedHat, boost 1.34 Any suggestions would be greatly appreciated. Thanks, Randy
Ormond, Randy wrote:
Hello,
I hope someone can point me in a new direction for tracking down a segfault.
Code that has been running fine for months started seg faulting after a directory reorganization.
Valgrind says "Use of uninitialized value of size 4".
A simplified version is below.
void MyClass::
SomeFunc()
{ // void f() is a member function of MyClass typedef boost::function<void ()> VoidFunc;
VoidFunc vf = boost::bind(&MyClass::f, this);
f(); // fine
this->f(); // fine;
vf(); // segfaults }
Infinite Recursion? At least for this sample code? Jeff Flinn
Jeff, Thanks for the quick reply. But I don't see the recursion. Is MyClass::f() somehow the same as MyClass::SomeFunc() ? Thanks, Randy -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: Friday, November 09, 2007 3:51 PM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault Ormond, Randy wrote:
Hello,
I hope someone can point me in a new direction for tracking down a segfault.
Code that has been running fine for months started seg faulting after a directory reorganization.
Valgrind says "Use of uninitialized value of size 4".
A simplified version is below.
void MyClass::
SomeFunc()
{ // void f() is a member function of MyClass typedef boost::function<void ()> VoidFunc;
VoidFunc vf = boost::bind(&MyClass::f, this);
f(); // fine
this->f(); // fine;
vf(); // segfaults }
Infinite Recursion? At least for this sample code? Jeff Flinn _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG Ormond, Randy <Randy.Ormond <at> mdnt.com> writes:
Jeff,
Thanks for the quick reply.
But I don't see the recursion. Is MyClass::f() somehow the same as MyClass::SomeFunc() ?
I don't see any recursion either. Does the simple example segfault? Can you post a *complete* program? Do these two variations segfault? this->MyClass::f(); boost::bind(&MyClass::f, this)() In Christ, Steven Watanabe
Steven, Thanks for the suggestions.
I don't see any recursion either. Does the simple example segfault? Can you post a *complete* program?
I wish I could.
Do these two variations segfault? this->MyClass::f(); boost::bind(&MyClass::f, this)()
Both of those are fine. There's a clue here that would help me if I were smart enough. The segfault goes away if I change the order of linking the object files. Maybe a duplicate symbol but I haven't found it yet. Thanks, Randy -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Friday, November 09, 2007 6:32 PM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault AMDG Ormond, Randy <Randy.Ormond <at> mdnt.com> writes:
Jeff,
Thanks for the quick reply.
But I don't see the recursion. Is MyClass::f() somehow the same as MyClass::SomeFunc() ?
I don't see any recursion either. Does the simple example segfault? Can you post a *complete* program? Do these two variations segfault? this->MyClass::f(); boost::bind(&MyClass::f, this)() In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG Ormond, Randy <Randy.Ormond <at> mdnt.com> writes:
Steven,
Thanks for the suggestions.
I don't see any recursion either. Does the simple example segfault? Can you post a *complete* program?
I wish I could.
Do these two variations segfault? this->MyClass::f(); boost::bind(&MyClass::f, this)()
Both of those are fine.
There's a clue here that would help me if I were smart enough. The segfault goes away if I change the order of linking the object files. Maybe a duplicate symbol but I haven't found it yet.
Thanks, Randy
It sound to me like an order of initialization problem. What version of boost are you using? Can you try stepping through the initializtion of the boost::function<...> and watching the value especially of the vtable? In Christ, Steven Watanabe
Steven,
It sound to me like an order of initialization problem. What version of boost are you using? Can you try stepping through the initializtion of the boost::function<...> and watching the value especially of the vtable?
I was deep into stepping through the initialization and noticed that gdb was using two different funtion_template.hpp files ! I think there is conflict between my projects installation of 1.34.1 and the RedHat-supplied 1.32.0. Now to find someone here with root access... Does that seem reasonable? Thanks, Randy -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Monday, November 12, 2007 9:52 AM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault AMDG Ormond, Randy <Randy.Ormond <at> mdnt.com> writes:
Steven,
Thanks for the suggestions.
I don't see any recursion either. Does the simple example segfault? Can you post a *complete* program?
I wish I could.
Do these two variations segfault? this->MyClass::f(); boost::bind(&MyClass::f, this)()
Both of those are fine.
There's a clue here that would help me if I were smart enough. The segfault goes away if I change the order of linking the object files. Maybe a duplicate symbol but I haven't found it yet.
Thanks, Randy
It sound to me like an order of initialization problem. What version of boost are you using? Can you try stepping through the initializtion of the boost::function<...> and watching the value especially of the vtable? In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
AMDG Ormond, Randy <Randy.Ormond <at> mdnt.com> writes:
I was deep into stepping through the initialization and noticed that gdb was using two different funtion_template.hpp files ! I think there is conflict between my projects installation of 1.34.1 and the RedHat-supplied 1.32.0. Now to find someone here with root access...
Does that seem reasonable?
Yep. In Christ, Steven Watanabe
I took my project's Boost out of the include path and the problem went away. I don't really understand how the RedHat /usr/include/boost got involved. Since I can't control /usr/include, I guess I'll have to be content with 1.32 Without your suggestion, I would never have found the problem. Thank you. Randy -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Monday, November 12, 2007 11:11 AM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault AMDG Ormond, Randy <Randy.Ormond <at> mdnt.com> writes:
I was deep into stepping through the initialization and noticed that gdb was using two different funtion_template.hpp files ! I think there is conflict between my projects installation of 1.34.1 and the RedHat-supplied 1.32.0. Now to find someone here with root access...
Does that seem reasonable?
Yep. In Christ, Steven Watanabe _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Nov 12, 2007 at 01:56:14PM -0500, Ormond, Randy wrote:
I took my project's Boost out of the include path and the problem went away. I don't really understand how the RedHat /usr/include/boost got involved. Since I can't control /usr/include, I guess I'll have to be content with 1.32
You have access to /usr/include! At least you can tell gcc to ignore standard include directories (-nostdinc) and specify it again before or after other include directories. Compare also -isystem, ... I wonder why there is no requirement to use either #include <boost/...> or #include "boost/..." Currently both is used which probably affects the include search path. Should this be fixed? Jens
You have access to /usr/include! At least you can tell gcc to ignore standard include directories (-nostdinc) and specify it again before or after other include directories. Compare also -isystem, ...
The local boost headers are the first thing on my include path. I'm not sure why the /usr/include/boost files are ever used, but they are.
I wonder why there is no requirement to use either #include <boost/...> or #include "boost/..." Currently both is used which probably affects the include search path.
Maybe that's the problem. Thanks, Randy -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jens Seidel Sent: Monday, November 12, 2007 2:46 PM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault On Mon, Nov 12, 2007 at 01:56:14PM -0500, Ormond, Randy wrote:
I took my project's Boost out of the include path and the problem went away. I don't really understand how the RedHat /usr/include/boost got involved. Since I can't control /usr/include, I guess I'll have to be content with 1.32
You have access to /usr/include! At least you can tell gcc to ignore standard include directories (-nostdinc) and specify it again before or after other include directories. Compare also -isystem, ... I wonder why there is no requirement to use either #include <boost/...> or #include "boost/..." Currently both is used which probably affects the include search path. Should this be fixed? Jens _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
My apologies. The explanation came to me in my sleep (which is fitting because I must have been asleep when I made the mistake). The recently added directories did not have our local 1.34.1 boost in the include path. Of course they compiled fine using the RedHat 1.32 boost but the two version collided with a segfault during execution. Sorry for the noise. -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jens Seidel Sent: Monday, November 12, 2007 2:46 PM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault On Mon, Nov 12, 2007 at 01:56:14PM -0500, Ormond, Randy wrote:
I took my project's Boost out of the include path and the problem went away. I don't really understand how the RedHat /usr/include/boost got involved. Since I can't control /usr/include, I guess I'll have to be content with 1.32
You have access to /usr/include! At least you can tell gcc to ignore standard include directories (-nostdinc) and specify it again before or after other include directories. Compare also -isystem, ... I wonder why there is no requirement to use either #include <boost/...> or #include "boost/..." Currently both is used which probably affects the include search path. Should this be fixed? Jens _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Ormond, Randy wrote:
Jeff,
Thanks for the quick reply.
But I don't see the recursion. Is MyClass::f() somehow the same as MyClass::SomeFunc() ?
Thanks, Randy
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Jeff Flinn Sent: Friday, November 09, 2007 3:51 PM To: boost@lists.boost.org Subject: Re: [boost] [bind] segfault
Ormond, Randy wrote:
Hello,
I hope someone can point me in a new direction for tracking down a segfault.
Code that has been running fine for months started seg faulting after a directory reorganization.
Valgrind says "Use of uninitialized value of size 4".
A simplified version is below.
void MyClass::
SomeFunc()
{ // void f() is a member function of MyClass typedef boost::function<void ()> VoidFunc;
VoidFunc vf = boost::bind(&MyClass::f, this);
f(); // fine
this->f(); // fine;
vf(); // segfaults }
Infinite Recursion? At least for this sample code?
Jeff Flinn
Oops, reader error. :( Jeff Flinn
participants (4)
-
Jeff Flinn -
Jens Seidel -
Ormond, Randy -
Steven Watanabe