Free umpire's reference to our thread sync's error buffer

[lindsayad]

Else we get a seg fault due to attempting to publish to a buffer that's already been deleted. Umpire allocates it's OutputBuffer class via static singletons so luckily they publish this API for us otherwise we'd be screwed

[moosebuild]

Job Coverage, step Generate coverage on eaf03ef wanted to post the following:

Coverage

Coverage did not change

Full coverage report

This comment will be updated on new commits.

[roystgnr]

I'm impressed you found this (my PETSc v3.23.5 build from July predates them adding Umpire in September; I wouldn't even have been able to replicate the problem!), but could we elaborate a bit in that comment? I had to dig into ostream_proxy.h before I realized that our "proxy" is so thin that it's outright sharing a buffer with the underlying target stream, and so Umpire is getting a hold of the buffers from std::cout and std::cerr despite never getting its hands on libMesh::out and libMesh::err.

I also feel like there just must be a better fix for this sort of thing than "wait for each new package that breaks and then add an API call to them" ... but I sure can't figure out what it would be.

[lindsayad]

How's the expanded comment?

[roystgnr]

Looks good; thanks!