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