don't print rpc_name pointer after handler exec

[carns]

• bug fix: the rpc_name is an internal pointer that may not necessarily be valid after completion of an RPC handler if the process unregisters an RPC fast enough

Alternatively we could strdup the rpc name to make sure the RPC wrapper has a copy that stays in scope, but I don't think the information is worth the memory allocation. The handle pointer value is sufficient to map back to the preceding trace message if needed.

[carns]

FWIW, I never triggered this until testing Mercury 2.4.0 RCs, I think just a slight timing difference made it trip the address sanitizer on my system.

[mdorier]

I think I had some issues as well in the past caused by the fact that you are allowed to deregister an RPC inside the RPC itself. I don't remember the details, though.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 57.54%. Comparing base (eb83582) to head (8302b0f).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #284      +/-   ##
==========================================
+ Coverage   57.51%   57.54%   +0.03%     
==========================================
  Files          70       70              
  Lines        9910     9910              
  Branches     1282     1282              
==========================================
+ Hits         5700     5703       +3     
+ Misses       3422     3418       -4     
- Partials      788      789       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[carns]

In my case I think the thread doing the deregistration (outside of the handler) is just getting ahead of the thread running the handler.

[mdorier]

Feel free to merge the PR; I was going to say we could reference-count the string, but we don't actually need it anywhere anyway at that point of the RPC so removing it from the logging works just fine.