5.3.1 double free or corruption (fasttop) on 2nd xrootd.monitor #1488
Comments
|
Hi Adrian,
Can you give me the specific addition to your config file that triggered
this issue so I can reproduce it with statement numbers?
Andy
…On Tue, 3 Aug 2021, Adrian Sevcenco wrote:
Hi! I'm trying to add another instance of xrootd.monitor and i get :
```
*** Error in `/usr/bin/xrootd': double free or corruption (fasttop): 0x00000000011ea040 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81329)[0x7f75bca8c329]
/lib64/libXrdServer.so.3(_ZN17XrdXrootdProtocol4xmonER12XrdOucStream+0x67)[0x7f75bdf6da77]
/lib64/libXrdServer.so.3(_ZN17XrdXrootdProtocol6ConfigEPKc+0x548)[0x7f75bdf6bad8]
/lib64/libXrdServer.so.3(_ZN17XrdXrootdProtocol9ConfigureEPcP18XrdProtocol_Config+0x20a)[0x7f75bdf6bdba]
/lib64/libXrdServer.so.3(XrdgetProtocol+0x5f)[0x7f75bdf7c32f]
/usr/bin/xrootd(_ZN11XrdProtLoad4LoadEPKcS1_PcP18XrdProtocol_Configb+0x48)[0x40f3f8]
/usr/bin/xrootd(_ZN9XrdConfig5SetupEPcS0_+0x249)[0x40b5e9]
/usr/bin/xrootd(_ZN9XrdConfig9ConfigureEiPPc+0xd6e)[0x40d3ce]
/usr/bin/xrootd(main+0x7c)[0x4073ac]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f75bca2d555]
/usr/bin/xrootd[0x407595]
```
any idea on this? i would like to have another monitoring destination with other configuration and content than the first instance...
Thank you!
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#1488
########################################################################
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
|
|
@xrootd-dev so, this is the configuration: uncommenting the second line triggers the breakage |
|
So, this was a holdover from a change we made to how the monitor directive works. The way you did this would not accomplish what you wanted as the second monitor directive would completely override the first (It's always been that way). However, people complained that the directive became way to wordy and difficult to manage. So, we introduced the '...' paradigm which should be used here (your other alternative to use backslash continuation like you do in make files which was the old way of doing it and still supported). Anyway, take a look at |
|
@abh3 well, ok, but ii do not want a continuation .. i just want a different set of metrics to a different destination .. or did i get |
|
Hi Adrian,
The metrics have to be the same between both destinations. The only
difference is what you send to each destination. Both destinations need to
be specified at the same time (i.e. with a single directive).
…On Wed, 4 Aug 2021, Adrian Sevcenco wrote:
@abh3 well, ok, but ii do not want a continuation .. i just want a _different_ set of metrics to a _different_ destination .. or did i get `...` wrong?
would the following work?:
```
xrootd.monitor set_options_1 destination1
xrootd.monitor ... set_options_2 destination2
```
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1488 (comment)
|
|
@abh3 hm.. ok, then, should i fill a "feature request" for distinct instances of monitor, each with own metrics and destination for sending? |
|
Well, you can but it's rather complicated and settling for metrics that
roughly work for both destinations seems like an adequate solution. Yes,
it's not perfect but most people seems to have accepted the compromise. We
went through a refactoring of the code for 5.x (hence the SEGV) and
looking at it while during debugging the issue it sure looks like it would
take a lot of work to add that feature.
…On Wed, 4 Aug 2021, Adrian Sevcenco wrote:
@abh3 hm.. ok, then, should i fill a "feature request" for distinct instances of monitor, each with own metrics and destination for sending?
is it technically possible?
Thanks a lot!
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1488 (comment)
|
|
i see, it's ok then, i can send the reunion of the metrics and each destination filters what it needs... |
|
Hi Adrian,
I guess I misunderstood what you meant by metrtics. Certain global metrics
will be sent to both destinations and you need those regardless. However,
each destination can have different monitoring streams. As noted in
https://xrootd.slac.stanford.edu/doc/dev53/xrd_config.htm#_Toc60181795
You can choose a different set from the following for each destination:
{ccm | files | fstat | io | info | pfc | redir | tcpmon | user}
So, it's not as strict as it would seem.
Andy
…On Wed, 4 Aug 2021, Adrian Sevcenco wrote:
i see, it's ok then, i can send the reunion of the metrics and each destination filters what it needs...
Thanks!
--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#1488 (comment)
|
Hi! I'm trying to add another instance of xrootd.monitor and i get :
any idea on this? i would like to have another monitoring destination with other configuration and content than the first instance...
Thank you!
The text was updated successfully, but these errors were encountered: