Evergreen 3.2 (though likely affects all supported versions)
Jason Stephenson mentioned in IRC that he was seeing pcrud crashes on app servers caused by calling a pcrud method with a null authtoken. Checking my own servers I've seen similar things and may have tracked down a possible cause. In every case I could find today the same 3 calls were made in rapid enough succession that they had consecutive threadtrace numbers: open-ils.auth.session.retrieve, open-ils.auth.session.delete, and then the open-ils.pcrud.search.pgt call with a null authtoken. In every case the authtoken used in those session.retrieve and delete calls were logged in with a login_type of temp, which has a default of 5 minutes. Redacted log selections as of this afternoon are attached; I didn't include the thread trace showing the login but did verify that all were temp logins.
Testing this from the web client is difficult because it doesn't happen every time an operator change times out and I haven't found what combination of use and backgrounding, etc. is required to trigger it. As far as simply testing a fix to the pcrud service you can trigger a pcrud segfault on demand by entering 'request open-ils.pcrud open-ils.pcrud.search.pgt null {"id": {">":0}}' in srfsh.
Since pcrud drones are expected to recycle themselves on occasion this doesn't cause significant issue when it happens organically but because of the possibility of DOS attack by throwing a rapid succession of "pcrud.crash" calls at your infrastructure I've set this to private security. If that's shown to be overly-cautious it can always be downgraded later.
I have found an instance that I am fairly certain does not involve operator change. I found a case where a pcrud segfault happened at 00:44 last night. The session for the authtoken was deleted at 00:44:15 and at 00:44:16 there was a pcrud segfault with the following call:
CALL: open-ils.pcrud open-ils. pcrud.search. pgt null,{" parent" :null}, {"flesh" :-1,"flesh_ fields" :{"pgt" :["children" ]}}
The trace id for the session delete is 1 less than that of the pcrud search.
Combing through the other longs, the prior activity for the authtoken occurred at 21:44. The auth.staff_timeout setting for this library is 3 hours.
I will keep looking to see if there are any other apparent causes for these segfaults, but so far, the only ones that I have seen are related to staff logins timing out.