Thanks for the explanation. I'll look this over tomorrow.

cheers,
pl

On 3 March 2016 at 15:23, Paul Peet <paulpee...@gmail.com> 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<uint64_t>(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 <cstddef>
> #include <cstdint>
> #include <iostream>
>
> 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:
>
> Correct one (with sleep(1)):
>
> * thread #1: tid = 5862, 0x0000000000400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
>     frame #0: 0x0000000000400953 main`main + 35 at main.cpp:7
>    4
>    5   int main() {
>    6
> -> 7    std::cout << "Hello World" << std::endl;
>    8
>    9    int i = 0;
>    10    std::cin >> i;
> 0x7f1dc4000930 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> ----------
> * thread #1: tid = 5862, 0x0000000000400953 main`main + 35 at
> main.cpp:7, name = 'main', stop reason = breakpoint 1.1
>     frame #0: 0x0000000000400953 main`main + 35 at main.cpp:7
>    4
>    5   int main() {
>    6
> -> 7    std::cout << "Hello World" << std::endl;
>    8
>    9    int i = 0;
>    10    std::cin >> i;
> 0x7f1dc4001640 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> Stopped at breakpoint
> ----------
> Hello World
> ----------
> * thread #1: tid = 5862, 0x0000000000400978 main`main + 72 at
> main.cpp:9, name = 'main', stop reason = step over
>     frame #0: 0x0000000000400978 main`main + 72 at main.cpp:9
>    6
>    7    std::cout << "Hello World" << std::endl;
>    8
> -> 9    int i = 0;
>    10    std::cin >> i;
>    11
>    12    if (i == 1) {
> 0x7f1dc4003ae0 Event: broadcaster = 0x55da93268068 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x55da93268030
> (pid = 5862), state = stopped}
> Stopped at step
> ----------
>
> And the one with non-determinism:
>
> * thread #1: tid = 9097, 0x0000000000400830 main`_start, name = 'main'
>     frame #0: 0x0000000000400830 main`_start
> main`_start:
>     0x400830 <+0>: xorl   %ebp, %ebp
>     0x400832 <+2>: movq   %rdx, %r9
>     0x400835 <+5>: popq   %rsi
>     0x400836 <+6>: movq   %rsp, %rdx
> 0x7fbdd0000930 Event: broadcaster = 0x564549feffa8 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x564549feff70
> (pid = 9097), state = stopped}
> ----------
> * thread #1: tid = 9097, 0x0000000000400830 main`_start, name =
> 'main', stop reason = breakpoint 1.1
>     frame #0: 0x0000000000400830 main`_start
> main`_start:
>     0x400830 <+0>: xorl   %ebp, %ebp
>     0x400832 <+2>: movq   %rdx, %r9
>     0x400835 <+5>: popq   %rsi
>     0x400836 <+6>: movq   %rsp, %rdx
> 0x7fbdd0001640 Event: broadcaster = 0x564549feffa8 (lldb.process),
> type = 0x00000001 (state-changed), data = { process = 0x564549feff70
> (pid = 9097), state = stopped}
> Stopped at breakpoint
> ----------
> Hello World
> ----------
>
> 2016-03-03 14:57 GMT+01:00 Pavel Labath <lab...@google.com>:
>> Hi Paul,
>>
>> I haven't followed this discussion from the start, and I am now having
>> trouble understanding what is the issue at hand here. Could you just
>> briefly repeat what is the problem, and maybe send the code for
>> reproducing the problem again? Maybe I'll be able to help...
>>
>> pl
>>
>> On 3 March 2016 at 13:04, Paul Peet via lldb-dev
>> <lldb-dev@lists.llvm.org> wrote:
>>> Sorry to bring this up again, but I am not sure if this is really a
>>> linux kernel issue anymore, see the following code:
>>>
>>> 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); // sleep a second
>>>         runOnce = true;
>>>       }
>>>
>>>       SBThread thread = process.GetThreadAtIndex(0);
>>>       SBStream stream;
>>>
>>> As I said before that strangely it worked on the vm with kernel 4.4 so
>>> I tried using kernel 4.4 and it still didn't work.
>>>
>>> Next thing I did was enabling lldb's logging and what I noticed was
>>> that when the first thread plan is being made it had wrong instruction
>>> information that's probably because the thread was still running. So
>>> what I tried was this runOnce with a sleep(1) and the result was as I
>>> expected, the thread plan contained the correct instruction
>>> information and the following breakpoints and step-overs were
>>> correctly made.
>>>
>>> Any chance that this issue lies deep in lldb? Would the lldb log help
>>> to trace back the issue?
>>>
>>> 2016-02-29 19:58 GMT+01:00 Greg Clayton <gclay...@apple.com>:
>>>>
>>>>> On Feb 28, 2016, at 2:17 PM, Paul Peet <paulpee...@gmail.com> wrote:
>>>>>
>>>>> Hey,
>>>>>
>>>>> Just to let you know that I think I made some progress in determine the 
>>>>> problem.
>>>>> I've basically setup an vm (archlinux, linux 4.4, lldb 3.7.1) and
>>>>> tried the code on it. To my surprise it gave me proper output without
>>>>> non-determinism. YEY.
>>>>> I still don't have any idea why it's not working on my host system. I
>>>>> might try testing linux 4.4 like I did on the vm.
>>>>>
>>>>> Do you have any idea/suspicion why it might not work on my system. (I
>>>>> can provide additional information if needed).
>>>>
>>>> I don't. Maybe some of the linux experts out there might be able to help 
>>>> you. Are are working with top of tree LLDB sources right? You might post 
>>>> the exact linux setup you have in case that might allow people to help you 
>>>> out...
>>>>
>>>> Greg
>>>>
>>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to