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
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@gmail.com> wrote:On 8/7/07, Jaime Rios <xdev74@gmail.com> 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@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
-Jaime
http://www.jaimerios.com