Yes. Based on those stacks, the problem is that it was being gathered up by
the stat synchronizer without the actual stat infrastructure needed.
On Wed, Nov 8, 2017 at 3:00 PM, James Peach wrote:
>
> > On Nov 8, 2017, at 11:22 AM, Zelkowitz, Evan
> wrote:
> >
> > I think the issue is with using
> On Nov 8, 2017, at 11:22 AM, Zelkowitz, Evan
> wrote:
>
> I think the issue is with using TS_RECORDTYPE_PROCESS (or plugin, I switched
> mine to plugin since that’s where Im creating these values). I changed it to
> TS_RECORDTYPE_CONFIG and I no longer get that crash. I also saw this in th
I think the issue is with using TS_RECORDTYPE_PROCESS (or plugin, I switched
mine to plugin since that’s where Im creating these values). I changed it to
TS_RECORDTYPE_CONFIG and I no longer get that crash. I also saw this in the
docs:
The management role for a management value. In practice onl
This came up with issues #2380 and #2388 and PR #2783. I had been waiting for
some internal feedback on my proposal but since this is now active I am sending
in my API proposal for attaching plugin data to NetVConnections (TSVConn).
https://solidwallofcode.github.io/api/TSVConnArgs.en.html#tsvco
Agreed, if people dont want tsstat to accept strings that should return an
error, can open up an issue for that later
So I got a trace on my linux box that should help a bit, the previous one was
from osx that I mainly just use to test building
#0 0x7f6f2ee25ccb in ?? () from /lib/x86_64-l
