...

• When increasing the number of monReqServer queues (with the -q option) it is necessary to increase the number of buffers (with the -n option, defaults to 8) because this line shares the total number of buffers among all the queues: https://github.com/slac-lcls/lcls2/blob/5301f172c23b448dc8904f7eee20e508b4adc2e9/psalg/psalg/shmem/XtcMonitorServer.cc#L594.  So far we have been using twice the number of buffers as queues (i.e. 2 buffers per queue)

• Some of the various "plumbing" message queues (that the users don't see) create queues with the full number of buffers (set with the -n option).  This can easily exceed the default linux system limit (currently 10) set in /proc/sys/fs/mqueue/msg_max.  This can create an mq_open error because the mq_maxmsg value of the mq_attr struct is too large.  The system limit needs to be set appropriately.  An example of the error:

  Code Block
  mq_open output: Invalid argument name: '/PdsToMonitorEvQueue_tmo_6' mq_attr: mq_flags 0x800 mq_maxmsg 0xc mq_msgsize 0x10 mq_curmsgs 0x0

epicsArch

epicsArch can segfault on configure if the number of variables gets large because the configure transition can exceed the dgram transition buffer size (see: https://github.com/slac-lcls/lcls2/blob/18401ef85dda5f7027e9321119a82410a00bad1e/psdaq/epicsArch/epicsArch.cc#L609).  There are checks done afterwords, but the segfault can happen earlier than the checks.  The transition buffer size can be specified on the epicsArch command line with the "-T" option (currently 1MB).

Right answer might be to have a "safe" Xtc::alloc method that would prevent the dgram from going past the end of the buffer, but that's a significant change.