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 only
TS_RECORDTYPE_CONFIG is usable.
So the only usable type for a MgmtString is CONFIG?
On 11/8/17, 1:26 AM, "Zelkowitz, Evan" <evan_zelkow...@comcast.com> wrote:
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 0x00007f6f2ee25ccb in ?? () from /lib/x86_64-linux-gnu/libgcc_s.so.1
#1 0x00007f6f2ee27668 in _Unwind_Backtrace () from
/lib/x86_64-linux-gnu/libgcc_s.so.1
#2 0x00007f6f2eb62b0f in __GI___backtrace (array=<optimized out>,
size=<optimized out>) at ../sysdeps/x86_64/backtrace.c:110
#3 0x00007f6f30c2a577 in ink_stack_trace_dump () at ink_stack_trace.cc:63
#4 0x00007f6f30c3ba08 in signal_crash_handler (signo=11) at signals.cc:180
#5 0x000000000050e36d in crash_logger_invoke (signo=11,
info=0x7f6f2d2218b0, ctx=0x7f6f2d221780) at Crash.cc:169
#6 <signal handler called>
#7 0x0000000200000002 in ?? ()
#8 0x000000000078b555 in RecExecRawStatSyncCbs () at RecRawStats.cc:585
#9 0x000000000078cf0d in raw_stat_sync_cont::exec_callbacks
(this=0x1cb8730) at RecProcess.cc:146
#10 0x00000000005112b2 in Continuation::handleEvent (this=0x1cb8730,
event=2, data=0x1cbea00)
at
/home/evan/projects/trafficserver/iocore/eventsystem/I_Continuation.h:153
#11 0x0000000000790a5f in EThread::process_event (this=0x7f6f2d72c010,
e=0x1cbea00, calling_code=2) at UnixEThread.cc:122
#12 0x0000000000790dc9 in EThread::execute_regular (this=0x7f6f2d72c010) at
UnixEThread.cc:205
#13 0x0000000000790fb1 in EThread::execute (this=0x7f6f2d72c010) at
UnixEThread.cc:262
#14 0x000000000078fde8 in spawn_thread_internal (a=0x1ca7ed0) at
Thread.cc:91
#15 0x00007f6f2f8c36ba in start_thread (arg=0x7f6f2d222700) at
pthread_create.c:333
#16 0x00007f6f2eb543dd in clone () at
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
still, pretty much the same, just easier to read
________________________________________
From: James Peach <jpe...@apache.org>
Sent: Tuesday, November 7, 2017 8:30 PM
To: <dev@trafficserver.apache.org>
Subject: Re: API Proposal - TSStatGet/SetString
> On Nov 7, 2017, at 1:39 PM, Zelkowitz, Evan <evan_zelkow...@comcast.com>
wrote:
>
> If that would be picked up by stats that would probably work, but seems
to generate a segv for me:
> TSMgmtStringCreate(TS_RECORDTYPE_PROCESS, "my.interface.name",
"default value",
> TS_RECORDUPDATE_DYNAMIC, TS_RECORDCHECK_NULL, NULL /* check_regex */,
TS_RECORDACCESS_READ_ONLY);
>
> traffic_server: received signal 11 (Segmentation fault: 11)
> traffic_server - STACK TRACE:
> 0 traffic_server 0x0000000107ef361b
_Z19crash_logger_invokeiP9__siginfoPv + 139
> 1 libsystem_platform.dylib 0x00007fff977e3b3a _sigtramp + 26
> 2 ??? 0x0000000023500180 0x0 + 592445824
> 3 traffic_server 0x0000000108201b48
_ZN18raw_stat_sync_cont14exec_callbacksEiP5Event + 24
> 4 traffic_server 0x0000000107ef4a60
_ZN12Continuation11handleEventEiPv + 112
> 5 traffic_server 0x0000000108206616
_ZN7EThread13process_eventEP5Eventi + 294
> 6 traffic_server 0x0000000108206c30
_ZN7EThread15execute_regularEv + 256
> 7 traffic_server 0x0000000108206f95
_ZN7EThread7executeEv + 213
> 8 traffic_server 0x00000001082059ec
_ZL21spawn_thread_internalPv + 156
> 9 libsystem_pthread.dylib 0x00007fff977ed93b _pthread_body
+ 180
> 10 libsystem_pthread.dylib 0x00007fff977ed887 _pthread_body
+ 0
> 11 libsystem_pthread.dylib 0x00007fff977ed08d thread_start +
13
>
> only happens with that line added, got it on both osx and linux
Bug? Though that stack trace doesn’t inspire confidence.
At any rate, TSMgmtStringCreate fronts the same subsystem that TSStat
(eventually) does, so this would be the right way to do it today. TSStatCreate
can’t directly support string stats; we should make it check the data type and
fail appropriately.
FWIW, stats and configuration records are all backed by the same internal
subsystem, so they are basically the same thing internally. Configuration
values are either TS_RECORDTYPE_CONFIG or TS_RECORDTYPE_LOCAL; other record
types are metrics.
>
> On 11/7/17, 10:46 AM, "James Peach" <jpe...@apache.org> wrote:
>
>
>> On Nov 7, 2017, at 8:35 AM, Zelkowitz, Evan <evan_zelkow...@comcast.com>
wrote:
>>
>> Proposing adding stat string support
>>
>> TSReturnCode TSStatGetString(int id, char *string, int len);
>> TSReturnCode TSStatSetString(int id, char *string, int len);
>>
>> This way we can store stat strings for retrieval by TS stats. Some
examples of things we currently have work arounds for are the interface name
that TS is running on, its negotiated speed, load averages, other proc values,
etc.
>>
>> I believe the stats will currently allow you to create a string stat,
there is just no way to interface with it. I will create a plugin that uses the
string functionality since the main reason of this is to be able to open source
a currently proprietary plugin that uses this sort of functionality.
>
> To do this, you'd just create the record directly.
>
> TSMgmtStringCreate(TS_RECORDTYPE_PROCESS, "my.great.metric.name",
"default value",
> TS_RECORDUPDATE_DYNAMIC, TS_RECORDCHECK_NULL, nullptr /*
check_regex */, TS_RECORDACCESS_READ_ONLY);
>
> J
>
>
>
>
