Threads, FunctionPtr and stepping through code
Hi, I'm working on a project that uses the Boost thread library. The code is pretty simple and creates one thread to a function. To test out the code I created, I create a console app and tested the code on 2 platforms: Mac OS X for Intel and Mac OS X for PowerPC. The code worked fine in the console app so I incorporated the code into my main project, which is a dylib. The code worked fine on the Intel Mac, but when I debugged the dylib on the PowerPC Mac, I get a EXC_BAD_ACCESS error. 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: (gdb) print f $1 = (void (*)(void)) 0x33658e4 <MyWorkerThread()> When I get the EXC_BAD_ACCESS error, the debugger stops at the following line: On line 95 of file function_template.hpp struct BOOST_FUNCTION_VOID_FUNCTION_INVOKER { static BOOST_FUNCTION_VOID_RETURN_TYPE invoke(any_pointer function_ptr BOOST_FUNCTION_COMMA BOOST_FUNCTION_PARMS) { HERE--> FunctionPtr f = reinterpret_cast<FunctionPtr>(function_ptr.func_ptr); BOOST_FUNCTION_RETURN(f(BOOST_FUNCTION_ARGS)); } }; The address at this point is the following: (gdb) print f $2 = (void (*)(void)) 0xf0798dd0 I went over the code over and over again but I cannot figure out what is causing the original function address to be changed. Now for the question! How can I debug this better? The problem that I am finding is that my debugger jumps to different parts of the project, but I cannot pinpoint the actual code that is causing this problem. Any suggestions? Thanks in advance! -Jaime
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
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
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@gmail.com> 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@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
Well, I found the problem using Shark. What had happened was that my dylibs were using a copy of the function0 template from a dylib other then my own, which would only cause problems on the PowerPC build. Once I statically included the source code, I got rid of the problem. -- -Jaime http://www.jaimerios.com
Sounds exactly like what I've seen. It is because of alignment/packing differences. boost.threads enforces 8 byte alignment using boost ABI headers. boost.function does not - it uses whatever alignment you have set up. previous versions of function<> didn't have alignment issues - it started with the small object optimizations. I think the fix is to force is to have function enforce alignment the same way threads does, although I'm still contemplating the 'philosophical ramifications'. Tony On 8/7/07, Jaime Rios <xdev74@gmail.com> wrote:
Hi, I'm working on a project that uses the Boost thread library. The code is pretty simple and creates one thread to a function. To test out the code I created, I create a console app and tested the code on 2 platforms: Mac OS X for Intel and Mac OS X for PowerPC. The code worked fine in the console app so I incorporated the code into my main project, which is a dylib. The code worked fine on the Intel Mac, but when I debugged the dylib on the PowerPC Mac, I get a EXC_BAD_ACCESS error.
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:
(gdb) print f $1 = (void (*)(void)) 0x33658e4 <MyWorkerThread()>
When I get the EXC_BAD_ACCESS error, the debugger stops at the following line:
On line 95 of file function_template.hpp struct BOOST_FUNCTION_VOID_FUNCTION _INVOKER { static BOOST_FUNCTION_VOID_RETURN_TYPE invoke(any_pointer function_ptr BOOST_FUNCTION_COMMA BOOST_FUNCTION_PARMS)
{ HERE--> FunctionPtr f = reinterpret_cast<FunctionPtr>(function_ptr.func_ptr); BOOST_FUNCTION_RETURN(f(BOOST_FUNCTION_ARGS)); } };
The address at this point is the following:
(gdb) print f $2 = (void (*)(void)) 0xf0798dd0
I went over the code over and over again but I cannot figure out what is causing the original function address to be changed.
Now for the question! How can I debug this better? The problem that I am finding is that my debugger jumps to different parts of the project, but I cannot pinpoint the actual code that is causing this problem. Any suggestions? Thanks in advance!
-Jaime _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Chris Uzdavinis -
Gottlob Frege -
Jaime Rios