Re: Sometimes Xcode Fails to Honor Breakpoints in Projects Including C++ Headers
Re: Sometimes Xcode Fails to Honor Breakpoints in Projects Including C++ Headers
- Subject: Re: Sometimes Xcode Fails to Honor Breakpoints in Projects Including C++ Headers
- From: Jim Ingham <email@hidden>
- Date: Mon, 08 Oct 2012 11:20:01 -0700
I can't reproduce this failure in the simple example you have cited. But since you said that this only sometimes happens, I must not be doing whatever triggers the problem.
Anyway, what does
(lldb) break list
say in the Debugger console? Note that lldb breakpoints have two components, the breakpoint specification, and then the breakpoint location(s). So you can specify a breakpoint, but it won't find any locations that match the breakpoint specification. That's sort of like the way gdb's "future-break" works, except that lldb's breakpoint specifications will remain active as long as the breakpoint is enabled. So anyway, break list will display the breakpoint spec, then any locations set for the breakpoint. Do your breakpoints have actual locations? And if they do, do they seem in a reasonable place? Try:
(lldb) image lookup -v -a <ADDRESS OF LOCATION>
that will tell you what code lldb thinks exists at that address. Does that seem right?
Also, you might try to set the breakpoint by hand with:
(lldb) break set -f main.mm -l <whatever>
Does that set the breakpoint? You can also gather log information about the breakpoint setting by turning on the log:
(lldb) log enable -f /tmp/breakpoint.log lldb break
and then try setting the breakpoint again and see what that says.
If you have the time to gather this info, please file a bug and we'll see if we can figure out what is going on.
Note, I don't think the inlining has anything to do with this, if it is true as you said that it also happens with the GNU stdc++ library, since that library doesn't inline at -O0.
Jim
On Oct 8, 2012, at 4:03 AM, Andreas Grosam <email@hidden> wrote:
> Possibly, this has something to do with:
>
> _LIBCPP_INLINE_VISIBILITY void push_back(const_reference __x);
>
>
> and
>
> #define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"), __always_inline__))
>
>
> The attribute __always_inline__ forces the compiler to inline the code, even in DEBUG configuration. While gdb can manage this - albeit issuing an warning:
> Error in re-setting breakpoint 1:
> Re-enabling shared library breakpoint 1
>
> LLDB silently fails to find the breakpoint.
>
>
>
> Andreas
>
>
> On 08.10.2012, at 10:05, Andreas Grosam wrote:
>
>> For example, in this code snippet Xcode will not stop at the breakpoint:
>> (Note, the issue may not arise when setting up a new project, but it may arise, when adding a new target to an existing project).
>>
>> // main.mm
>> #import <Foundation/Foundation.h>
>> #include <vector>
>>
>> int main(int argc, const char * argv[])
>> {
>> @autoreleasepool {
>>
>>>>> std::vector<int> v;
>> v.push_back(1);
>> NSLog(@"finished");
>> }
>> return 0;
>> }
>>
>>
>>
>> This may happen with any compiler (language Dialect) and with GNU's and clang's standard c++ library.
>>
>> *Sometimes* means, that for unknown reasons this had never worked and will never work for a project, or it just happens for an existing project at an arbitrary event, and once this failure is set, I'm unable to persuade Xcode to behave correctly again.
>>
>>
>> A related issue is maybe that *per default* standard C++ headers without extension will not be recognized by the compiler as proper C++ headers. A possible workaround is NOT to set the Editor's syntax options to C++, because this only enables syntax highlighting (which works fine), but does not let Xcode recognize and gather the symbols defined on the header, nor does it enable us to set breakpoints.
>>
>> I couldn't find any differences in the build settings between projects that do not show the issue and projects that do show the issue.
>>
>>
>> Any hints, what I can do to alleviate this problem?
>>
>>
>> Thanks in advance!
>>
>> Andreas
>> _______________________________________________
>> Do not post admin requests to the list. They will be ignored.
>> Xcode-users mailing list (email@hidden)
>> Help/Unsubscribe/Update your Subscription:
>>
>> This email sent to email@hidden
>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Xcode-users mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden