The ptrace options per thread id also fail so I removed that as well. Atm
lldb-server is seg-faulting in ThreadAttach that im trying to work out why.
Mark Chandler
Battle.Net Engineering Systems | Blizzard Entertainment
(P) 949-955-1380 x15353
-Original Message-
From: Pavel Labath [mai
I'm following this discussion, but I don't yet understand what is
going on here completely. What I am sure is that the problem here is
not the S+ state, as that just means "interruptible sleep, foreground
process", and a lot of processes have that state and we attach to them
just fine. I would need
Ill have to talk to the powers to be but for the most part I could check it in.
There is an internal json format that the tool saves it into and a bit of it is
geared towards Blizzard Entertainment server setup though but for the most part
its pretty simple (under 1000 lines).
Mark Chandl
Can someone with linux experience chime in here? It shouldn't be too hard to
figure out which flag 'S' is in. On MacOS we can get a process info structure
from a pid and that will have bits set that indicate 'S'...
If you want to checkin this tool into the LLDB source tree at
trunk/tools/core_t
The biggest tell is that the process state is already 'S' or stopped. I don’t
know lldb at all to make a change to fix this though.
Mark Chandler
Battle.Net Engineering Systems | Blizzard Entertainment
(P) 949-955-1380 x15353
-Original Message-
From: Greg Clayton [mailto:gclay...@apple.
Makes sense about not writing the core file to disk.
Is there a way you can detect this "core" mode where we don't have to waitpid?
Seems like that www.sourceware.org message had ideas on how to detect this case?
Greg
> On Nov 3, 2015, at 4:36 PM, Mark Chandler wrote:
>
> Not able to do that
So you would save the file, create a target:
const char *core_path = ...; // Save STDIN to a file and put path in
"core_path"
const bool source_init_files = false;
debugger = lldb::SBDebugger::Create(source_init_files);
target = debugger.CreateTarget(None);
process = target.LoadCore(core_path);
Stefan Kratochwil wrote:
> [...]
> I am developing a dynamic software updating tool for dynamically
> linked C libraries (in short: I want to patch dynamic libraries
> in-memory).
See also dyninst.
> [...]
> I am currently unaware of what types of information I _really_ need,
> so for now, gett
Not able to do that as the servers have no hard drives (use ram disk and net
boot) and the tool is trying to avoid a core storm that takes down the network
file share. I found out what is causing it to hang, there is a call to waitpid
in NativeLinuxProcess.cpp that waits forever. As the process
One different approach is to have your tool write all STDIN to a file (the core
file comes into the tool as STDIN bytes) and then hand LLDB the core file and
do any needed backtracing and data gathering from the core file instead of
actually attaching to the process for real. All executable and
> On Nov 3, 2015, at 1:12 PM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Be sure to use "frame variable" more as it will never run into these type
>> importation problems when you need to view a variable or members of a
>> variable.
>>
>> It would be interesting to see the output
https://llvm.org/bugs/show_bug.cgi?id=25396
Bug ID: 25396
Summary: Unclear error message when loading PE executable on OS
X
Product: lldb
Version: unspecified
Hardware: PC
OS: MacOS X
Status: NEW
Greg Clayton wrote:
> Be sure to use "frame variable" more as it will never run into these type
> importation problems when you need to view a variable or members of a
> variable.
>
> It would be interesting to see the output of "frame variable" from frame 0
> and frame 4 and see if they differ
> On Nov 3, 2015, at 12:07 PM, Ramkumar Ramachandra wrote:
>
> Greg Clayton wrote:
>> Not really. If you can send me a concrete example of something that isn't
>> working, it might help.
>
> Reporting progress.
>
> 1. `im loo -t` only ever finds one "best match", and the plist seems
> to have
> On Oct 30, 2015, at 3:35 AM, Stefan Kratochwil via lldb-dev
> wrote:
>
> Hi Greg,
>
> thanks for your reply.
>
> I am developing a dynamic software updating tool for dynamically linked C
> libraries (in short: I want to patch dynamic libraries in-memory).
>
> My goal is to achieve that wi
Greg Clayton wrote:
> Not really. If you can send me a concrete example of something that isn't
> working, it might help.
Reporting progress.
1. `im loo -t` only ever finds one "best match", and the plist seems
to have no effect on it.
2. The plist parsing code does get executed. I checked with
16 matches
Mail list logo
