thank you
I am a bts newb, so apologies for any transgressions.
> > There are any number of possible resolution paths.
> >
> > 1 - replace pstack binary with shellscript around gdb as RHEL has done
>
> I don't see the point of doing this. Depending on gdb would ruin the purpose.
> I think pstack is interesting as a lightweight solution.
Agreed pstack executable can be faster than gdb, which is very
helpful.
For reference, the RHEL method is to introduce a flag in gdb
implementation that skips all the symbol loading flow, which reduces
it from an interruption that lasts tens of seconds to an interruption
that lasts a portion of a second.
> > 2 - pass this upstream
> >
> > 3 - enhance pstack to be able to discover all the running threads. For
> > example, strace has functionality to accomplish thist that is more or
> > less maintained.
>
> Original upstream is dead so I took over the project and maintain it myself.
> I'm sorry for not having worked on pstack for a while, I was busy working on
> tcc. I'll see what I can do but have no idea how much time it will require.
>
> Thanks for the report, I didn't realize there was this problem.
I took a stab at beginning to look through the implementation (and of
strace) but made the determination that this is honestly beyond me.
:-(
--
JRodman - Splunk Sustaining Engineering
___.___
c[_]`=--/ Diving deep into your data.
| ___.___
| \--='[_]b
| /\ |
&\ / \ |
`.` / , / .,' &
~~~&~~~&~~~``'"'"'"'"~~~~~~~~~`&~~~~~~~~~~~~~~~sl
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
