Re: [Boost-users] Threads, FunctionPtr and stepping through code

From: Jaime Rios (xdev74_at_[hidden])
Date: 2007-08-08 22:47:45

In order to fix this problem, I had to abandon the Boost threading library
and use POSIX threading instead. The code was simple enough where this
wasn't a problem to reimplement, and thankfully, the new code worked on both
Intel and PowerPC processors .

If there is time to spare, I would like to further investigate this issue
and understand why the function pointer lost it's original address when
boost::thread() was called.

-- 
-Jaime
http://www.jaimerios.com
On 8/8/07, Jaime Rios <xdev74_at_[hidden]> wrote:
>
> Thanks for the advice :) My gut feeling told me that my problem is in the
> xcode project settings since the code works fine on the Intel version of Mac
> OS, works fine as an application on PowerPC but fails when used on the
> PowerPC processor.
>
> Like your experience, I feel that this is something that is going to take
> me a while to figure out since I didn't start the project and it has a long
> history behind it. Thanks again and if there is anything else you, or anyone
> else, can think of, I'm all ears!
>
> Thanks again!
>
> -Jaime
>
> On 8/7/07, Chris Uzdavinis <cuzdav_at_[hidden]> wrote:
> >
> > On 8/7/07, Jaime Rios <xdev74_at_[hidden]> wrote:
> >
> > > After spending many hours trying to find out what the cause of the
> > problem
> > > is, the only thing I could derive was that the address that Boost was
> > using
> > > to access my function was wrong. Before the error, I have the
> > following
> > > address to my function:
> >
> > I'm not sure if this helps, but in a different context unrelated to
> > Boost, we ran into a case where addresses seemed to randomly change.
> > After hours and hours of debugging, we decided it was the compiler
> > generating code strangely.  In the end, we discovered that the build
> > options for the shared library differed from the main executable in
> > such a way as to affect the binary object layout.  When an object was
> > passed across the boundary (from the executable to a library
> > function), addresses "shifted" since functions in the library did
> > different offset calculations to find members, etc.  Perhaps you could
> > review your build options to ensure it's not something along those
> > lines.  Fixing our makefile and recompiling solved the bug for us.
> > (It has been years now, but it's the kind of bug I will never forget.)
> >
> > Chris
> > _______________________________________________
> > Boost-users mailing list
> > Boost-users_at_[hidden]
> > http://lists.boost.org/mailman/listinfo.cgi/boost-users
> >
>
>
>
> --
> -Jaime
> http://www.jaimerios.com