date:20160304

Re: [lldb-dev] How to use the C++ API? No useful documentation?

2016-03-04 Thread Pavel Labath via lldb-dev

Hi Paul,

I believe you are experiencing the same problem as a couple of other
people before you (see
,
).
Basically, you need to ignore the events with the "restarted" flag  by
checking the GetRestartedFromEvent value for Stopped events. Linux
broadcasts this event on initial start, but other targets don't. This
is not a particularly well documented feature, and we would welcome
any improvements to the documentation. :)

Let me know if you still have problems after adding the check for the
restarted flag.

cheers,
pl


On 3 March 2016 at 15:26, Pavel Labath  wrote:
> Thanks for the explanation. I'll look this over tomorrow.
>
> cheers,
> pl
>
> On 3 March 2016 at 15:23, Paul Peet  wrote:
>> Hi Pavel,
>>
>> This is the code:
>>
>> int main() {
>>   using namespace lldb;
>>
>>   SBDebugger::Initialize();
>>   SBDebugger debugger = SBDebugger::Create(true);
>>
>>   if(!debugger.IsValid()) {
>> return 1;
>>   }
>>
>>   SBTarget target = 
>> debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
>>
>>   if(!target.IsValid()) {
>> return 1;
>>   }
>>
>>   SBBreakpoint bp1 = target.BreakpointCreateByLocation(
>> "/home/cynecx/dev/helloWorld/main.cpp", 7);
>>
>>   if(!bp1.IsValid()) {
>> return 1;
>>   }
>>
>>   bp1.SetEnabled(true);
>>
>>   const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
>>   const char* env[] = { 0 };
>>
>>   SBLaunchInfo launch_info(args);
>>   launch_info.SetEnvironmentEntries(env, true);
>>   launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
>>   launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>>
>>   SBError error;
>>   SBProcess process = target.Launch(launch_info, error);
>>
>>   if(!process.IsValid() || !error.Success()) {
>> return 1;
>>   }
>>
>>   error = process.Continue();
>>   if(!error.Success()) {
>> return 1;
>>   }
>>
>>   while(true) {
>> SBEvent event;
>> SBListener listener = debugger.GetListener();
>>
>> if(listener.WaitForEvent(6, event)) {
>>   if(!event.IsValid()) {
>> break;
>>   }
>>
>>   const uint32_t event_type = event.GetType();
>>
>>   if (!SBProcess::EventIsProcessEvent(event)) {
>> continue;
>>   }
>>
>>   if(event_type == SBProcess::eBroadcastBitStateChanged) {
>> const StateType state = SBProcess::GetStateFromEvent(event);
>>
>> switch(state) {
>>   default:
>> continue;
>>   case eStateStopped: {
>> //static bool runOnce = false;
>> //
>> //if(runOnce == false) {
>> //  sleep(1);
>> //  runOnce = true;
>> //}
>>
>> SBThread thread = process.GetThreadAtIndex(0);
>> SBStream stream;
>>
>> thread.GetStatus(stream);
>> event.GetDescription(stream);
>>
>> std::cout << stream.GetData() << std::endl;
>>
>> auto threadStopReason = thread.GetStopReason();
>> if(threadStopReason == eStopReasonBreakpoint) {
>>   uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
>>
>>   if(bpId == static_cast(bp1.GetID())) {
>> std::cout << "Stopped at breakpoint" << std::endl;
>> thread.StepOver();
>>   }
>> } else if (threadStopReason == eStopReasonPlanComplete) {
>>   std::cout << "Stopped at step" << std::endl;
>> }
>>
>> break;
>>   }
>> }
>>   } else if (SBProcess::eBroadcastBitSTDOUT) {
>> char buffer[1024];
>> size_t num_bytes = 0;
>> do
>> {
>>   num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
>>   if (num_bytes > 0)
>> printf("%*s", (int)num_bytes, buffer);
>> } while (num_bytes == sizeof(buffer));
>>   }
>>
>>   std::cout << "--" << std::endl;
>> } else {
>>   break;
>> }
>>   }
>>
>>   SBDebugger::Terminate();
>>
>>   return 0;
>> }
>>
>> main.cpp:
>>
>> #include 
>> #include 
>> #include 
>>
>> int main() {
>>
>>   std::cout << "Hello World" << std::endl;
>>
>>   int i = 0;
>>   std::cin >> i;
>>
>>   if (i == 1) {
>> return 1;
>>   }
>>
>>   return 0;
>> }
>>
>>
>> So the problem is that I am not getting correct thread information
>> when receiving an eStateStopped event. It kinda seems that when
>> "thread.GetStatus(stream);", the thread hasn't stopped yet so I always
>> getting non-determine thread information.
>> I found out that on my linux vm, it works properly so I thought it
>> might be an issue with the kernel and stuff but I kinda found a
>> workaround by simply putting a sleep(1) before querying the thread
>> information. As expected it gave me correct thread information, also
>> the step-over worked properly because the thread plan used correct
>> line information.
>>
>> To compare both outputs:

Re: [lldb-dev] [3.8 Release] 'final' has been tagged

2016-03-04 Thread Ben Pope via lldb-dev


On Thursday, March 03, 2016 08:33 AM, Hans Wennborg via lldb-dev wrote:

Dear testers,

My list of blockers is empty, and there were no new problems
discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].

Please build the final binaries and upload to the sftp.


Uploaded:

clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-15.10.tar.xz
clang+llvm-3.8.0-x86_64-linux-gnu-ubuntu-14.04.tar.xz

Ben

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to use the C++ API? No useful documentation?

2016-03-04 Thread Paul Peet via lldb-dev

Hi Pavel,

First of all, thank you for looking into this. I really appreciate it.
Secondly,  the check with GetRestartedFromEvent did the trick.
I am finally getting correct information. Thank You very much.

About the documentation, I really think it can be much better and I
would also help in this case but my english isn't my first language as
I am also not good at expressing the intention of every lldb feature
because obviously I am also just a beginner.

Although I think it would be helpful for other users, that if there
would have been a valid C++ debugging example like my issue
reproduction code.

:)

~Paul



2016-03-04 13:09 GMT+01:00 Pavel Labath :
> Hi Paul,
>
> I believe you are experiencing the same problem as a couple of other
> people before you (see
> ,
> ).
> Basically, you need to ignore the events with the "restarted" flag  by
> checking the GetRestartedFromEvent value for Stopped events. Linux
> broadcasts this event on initial start, but other targets don't. This
> is not a particularly well documented feature, and we would welcome
> any improvements to the documentation. :)
>
> Let me know if you still have problems after adding the check for the
> restarted flag.
>
> cheers,
> pl
>
>
> On 3 March 2016 at 15:26, Pavel Labath  wrote:
>> Thanks for the explanation. I'll look this over tomorrow.
>>
>> cheers,
>> pl
>>
>> On 3 March 2016 at 15:23, Paul Peet  wrote:
>>> Hi Pavel,
>>>
>>> This is the code:
>>>
>>> int main() {
>>>   using namespace lldb;
>>>
>>>   SBDebugger::Initialize();
>>>   SBDebugger debugger = SBDebugger::Create(true);
>>>
>>>   if(!debugger.IsValid()) {
>>> return 1;
>>>   }
>>>
>>>   SBTarget target = 
>>> debugger.CreateTarget("/home/cynecx/dev/helloWorld/main");
>>>
>>>   if(!target.IsValid()) {
>>> return 1;
>>>   }
>>>
>>>   SBBreakpoint bp1 = target.BreakpointCreateByLocation(
>>> "/home/cynecx/dev/helloWorld/main.cpp", 7);
>>>
>>>   if(!bp1.IsValid()) {
>>> return 1;
>>>   }
>>>
>>>   bp1.SetEnabled(true);
>>>
>>>   const char* args[] = { "/home/cynecx/dev/helloWorld/main", 0 };
>>>   const char* env[] = { 0 };
>>>
>>>   SBLaunchInfo launch_info(args);
>>>   launch_info.SetEnvironmentEntries(env, true);
>>>   launch_info.SetWorkingDirectory("/home/cynecx/dev/helloWorld");
>>>   launch_info.SetLaunchFlags(eLaunchFlagStopAtEntry);
>>>
>>>   SBError error;
>>>   SBProcess process = target.Launch(launch_info, error);
>>>
>>>   if(!process.IsValid() || !error.Success()) {
>>> return 1;
>>>   }
>>>
>>>   error = process.Continue();
>>>   if(!error.Success()) {
>>> return 1;
>>>   }
>>>
>>>   while(true) {
>>> SBEvent event;
>>> SBListener listener = debugger.GetListener();
>>>
>>> if(listener.WaitForEvent(6, event)) {
>>>   if(!event.IsValid()) {
>>> break;
>>>   }
>>>
>>>   const uint32_t event_type = event.GetType();
>>>
>>>   if (!SBProcess::EventIsProcessEvent(event)) {
>>> continue;
>>>   }
>>>
>>>   if(event_type == SBProcess::eBroadcastBitStateChanged) {
>>> const StateType state = SBProcess::GetStateFromEvent(event);
>>>
>>> switch(state) {
>>>   default:
>>> continue;
>>>   case eStateStopped: {
>>> //static bool runOnce = false;
>>> //
>>> //if(runOnce == false) {
>>> //  sleep(1);
>>> //  runOnce = true;
>>> //}
>>>
>>> SBThread thread = process.GetThreadAtIndex(0);
>>> SBStream stream;
>>>
>>> thread.GetStatus(stream);
>>> event.GetDescription(stream);
>>>
>>> std::cout << stream.GetData() << std::endl;
>>>
>>> auto threadStopReason = thread.GetStopReason();
>>> if(threadStopReason == eStopReasonBreakpoint) {
>>>   uint64_t bpId = thread.GetStopReasonDataAtIndex(0);
>>>
>>>   if(bpId == static_cast(bp1.GetID())) {
>>> std::cout << "Stopped at breakpoint" << std::endl;
>>> thread.StepOver();
>>>   }
>>> } else if (threadStopReason == eStopReasonPlanComplete) {
>>>   std::cout << "Stopped at step" << std::endl;
>>> }
>>>
>>> break;
>>>   }
>>> }
>>>   } else if (SBProcess::eBroadcastBitSTDOUT) {
>>> char buffer[1024];
>>> size_t num_bytes = 0;
>>> do
>>> {
>>>   num_bytes = process.GetSTDOUT(buffer, sizeof(buffer));
>>>   if (num_bytes > 0)
>>> printf("%*s", (int)num_bytes, buffer);
>>> } while (num_bytes == sizeof(buffer));
>>>   }
>>>
>>>   std::cout << "--" << std::endl;
>>> } else {
>>>   break;
>>> }
>>>   }
>>>
>>>   SBDebugger::Terminate();
>>>
>>>   return 0;
>>> }
>>>
>>> main.cpp:
>>>
>>> #include 
>>> #include 
>>> #include 
>>

[lldb-dev] [Bug 26842] New: LLDB GUI segfault when continuing with the thread frame list expanded

2016-03-04 Thread via lldb-dev

https://llvm.org/bugs/show_bug.cgi?id=26842

Bug ID: 26842
Summary: LLDB GUI segfault when continuing with the thread
frame list expanded
Product: lldb
Version: 3.8
Hardware: Macintosh
OS: MacOS X
Status: NEW
Severity: normal
Priority: P
Component: All Bugs
Assignee: lldb-dev@lists.llvm.org
Reporter: kknb1...@gmail.com
CC: llvm-b...@lists.llvm.org
Classification: Unclassified

Created attachment 15986
--> https://llvm.org/bugs/attachment.cgi?id=15986&action=edit
Example backtrace of a crash, plus the proposed patch to fix

I have a fix for this, but I wasn't sure if the correct etiquette is to file a
bug report before posting a patch to lldb-commits?

If the frame stack changes while the list is expanded in the Threads window,
there will be a high likelihood of a segfault. For example, expanding the list
and then "continue" to another breakpoint where the list is different. I can
give a specific program and instructions if required but any program should do
it. An example stack trace is attached.

This is with the version of lldb shipped with XCode 7.2.1 (lldb-340.4.119.1) as
well as the current head (as at 04/Mar/16).

The problem is that, when creating the updated list it is done with

vector::resize( , );

(via calls to TreeItem::Resize in IOHandler.cpp lines 3312 and 3422). The
intention of the code is to fill the m_children vector with copies of , but std::vector::resize only uses the for new values -
items already in the vector are left untouched. Hence all items up to the old
size will have invalid pointers to parent etcetera, and subsequent Draw calls
will screw up.

I propose to insert a call to TreeItem::ClearChildren() immediately before the
TreeItem::Resize(..) calls so that all children correctly take on the new
value.

A patch is attached, but I could only append one file so it's after the
backtrace.

--
You are receiving this mail because:
You are the assignee for the bug.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged

2016-03-04 Thread Nikola Smiljanic via lldb-dev

Uploaded Fedora and openSUSE binaries

5bc4bb9b1cadb37567328430c87e958b916049d8
 clang+llvm-3.8.0-i586-opensuse13.2.tar.xz
76d64a4cec71b95263bdf9b46bb3367f4b747c53
 clang+llvm-3.8.0-i686-fedora23.tar.xz
716d09d8d27f715ffcd795a138184033f83a7703
 clang+llvm-3.8.0-x86_64-fedora23.tar.xz
3f68b54a7c9be391c8908b0bb2d67e7a87107dc4
 clang+llvm-3.8.0-x86_64-opensuse13.2.tar.xz

On Fri, Mar 4, 2016 at 12:07 PM, Brian Cain via Release-testers <
release-test...@lists.llvm.org> wrote:

>
>
> On Wed, Mar 2, 2016 at 6:33 PM, Hans Wennborg via Release-testers <
> release-test...@lists.llvm.org> wrote:
>
>> Dear testers,
>>
>> My list of blockers is empty, and there were no new problems
>> discovered with rc3, so I have gone ahead and tagged 3.8.0-final [1].
>>
>> Please build the final binaries and upload to the sftp.
>>
>> For others following along: yes, this means 3.8.0 is complete, but it
>> takes a couple of days to get the source and binary tarballs built. I
>> will send the release announcement when everything's ready.
>>
>>
>>
> Uploaded clang+llvm-3.8.0-x86_64-sles11.3-linux-gnu.tar.xz
> and clang+llvm-3.8.0-linux-armhf-vivid.tar.xz
>
> 7388c9ec1c9680a3366dd40e0bb8acc655b3e3ec
>  clang+llvm-3.8.0-linux-armhf-vivid.tar.xz
> c33ab986d5b8dce7af88ca1b748240f98c4ed2c5
>  clang+llvm-3.8.0-x86_64-sles11.3-linux-gnu.tar.xz
>
>
>
>
> --
> -Brian
>
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] How to use the C++ API? No useful documentation?

Re: [lldb-dev] [3.8 Release] 'final' has been tagged

Re: [lldb-dev] How to use the C++ API? No useful documentation?

[lldb-dev] [Bug 26842] New: LLDB GUI segfault when continuing with the thread frame list expanded

Re: [lldb-dev] [Release-testers] [3.8 Release] 'final' has been tagged

5 matches

Site Navigation

Mail list logo

Footer information