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
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,
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
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
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
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: