Be careful about this sort of thing, there are all sorts of gnarly corner
cases, like a breakpoint command that does:
(lldb) break command add
Enter your debugger command(s). Type 'DONE' to end.
settings set auto-confirm true
process kill
DONE
The process kill gets executed while you
Be careful about this sort of thing, there are all sorts of gnarly corner
cases, like a breakpoint command that does:
(lldb) break command add
Enter your debugger command(s). Type 'DONE' to end.
settings set auto-confirm true
process kill
DONE
The process kill gets executed while you are
Hi,
please see my comments inline:
In http://reviews.llvm.org/D7692#125375, @labath wrote:
Greetings,
I have been following this discussion, and would like to add my 2 cents. I'll
start with my thoughts on virtual functions.
On 17 February 2015 at 18:44, Oleksiy Vyalov
Greetings,
I have been following this discussion, and would like to add my 2 cents. I'll
start with my thoughts on virtual functions.
On 17 February 2015 at 18:44, Oleksiy Vyalov ovya...@google.com wrote:
On Tue, Feb 17, 2015 at 10:01 AM, Tamas Berghammer tbergham...@google.com
wrote:
As far as I know NativeProcessLinux is still fully functional during the
execution of it's destructor. The only difference is that the members in
GDBRemoteCommunicationServerLLGS defined after the NativeProcessLinux smart
pointer are already destructed. If this ordering is the problem then it
I don't understand this:
NativeProcessLinux initiates ThreadStateCoordinator termination from its own
destructor, but in the same time ThreadStateCoordinator references
NativeProcessLinux by itself.
Where is the reference from ThreadStateCoordinator to NativeProcessLinux?
I also don't see
Hi vharron, tberghammer,
ninja-check-lldb with LLGS_LOCAL on produces plenty of core dumps - SIGSEGVs
happen in llgs by following reasons:
- NativeProcessLinux doesn't join on ThreadStateCoordinator thread;
- NativeProcessLinux initiates ThreadStateCoordinator termination from its own
