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 <jpe...@apache.org> wrote: > > > On Nov 8, 2017, at 11:22 AM, Zelkowitz, Evan <evan_zelkow...@comcast.com> > 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 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? > > Looks like TSMgmtStringCreate should check the record type and call either > RecRegisterConfigString or RecRegisterStatString as appropriate. > RecRegisterConfigString should also return an error if it receives an > unsupported record type (currently it just asserts in debug builds). > > > 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 > >> > >> > >> > >> > > > > > > > > > > > >
