duplicate DiagsConfigState::enable instance.

[bluestn]

Under trafficserver 8.0.6,
I found when I set CONFIG proxy.config.diags.debug.enabled INT 1, this setting does not take effect.

gdb debug the traffic_server, when program runs at at the point

DiagsConfig.cc

 74   e = (int)REC_readInteger("proxy.config.diags.debug.enabled", &found);
75   if (e && found) {
76    c.enabled[DiagsTagType_Debug] = e; // implement OR logic
77  }

I found that after line 76, c.enabled[DiagsTagType_Debug] is still 0

use the following command, and we can see:

nm ./src/traffic_server/.libs/traffic_server |grep DiagsConfigState00000000002db857 W _Z8ink_zeroI16DiagsConfigStateEvRT_000000000074c638 B _ZN16DiagsConfigState7enabledE

nm ./src/tscore/.libs/libtscore.so|grep DiagsConfigState
00000000003dd628 B _ZN16DiagsConfigState7enabledE
both the traffic_server & libtscore.so have DiagsConfigState::enabled instance.

so this is the root cause.

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. Marking it stale to flag it for further consideration by the community.

[bryancall]

I am closing this as resolved by later restructuring. The code referenced here was from 8.0.6, which is long past end-of-life. The duplicate DiagsConfigState::enabled instance came from a public static array that could be linked into both the traffic_server binary and libtscore.so. In #8581 (first released in 10.0.0) DiagsConfigState was reworked so the flag is a single private static (int _enabled[2], defined once in src/tscore/Diags.cc) accessed only through static accessor methods, removing the direct public-array write that this report describes. If you still see proxy.config.diags.debug.enabled not taking effect on a current release, please open a new issue with details.