The following error is printed during a valgrind test run

```
impossible to invoke method "write": no defined method or unknown method
    while executing
"my rpc write otto-$hdl"
    (class "::MkObjectRpc" destructor line 2)
```

Above does not show if oo-35.7.1 and oo-35.7.2 are disabled or outside of valgrind.

Note no test failures are reported, only the above message is printed to output. Further, the message is printed while the file following oo.test - process.test - is running. Running oo.test by itself does not print the error. This makes me suspect it is some background error that is being printed at a later point. Running oo.test by itself probably exits before the error is printed (conjecture).

This turned out to be not very serious after all. Phew!

What was happening was that those tests were pitching errors into the background error mechanism (because they arise at a point when we've gone through a C API that *can't* produce errors). Not sure why the valgrind runs were running `update` but the fix was to install our own logging `bgerror` and put the `update` inside the test. Then *all* builds see that *expected error* and the test will in fact fail without it.

It was mostly working as designed except for the error handling. No C changes needed.

The error is *printed* because when you're tangled that far down inside deletion traces and namespace deletion callbacks, there's simply no route to report it sanely except via the background error message mechanism (and that's got a simple message printer attached).

Anyway, the questions are:

1. Why does this let this message through with valgrind in use?
2. Why does this *not happen* in other configurations?

The *problem* is that this is trying to do a callback into an object that is in an advanced state of dying, and where that callback is being done from a destructor on an object deleted during that main deletion process. Ugh! Be aware that this will *never* work as written (or rather as originally written; these two failing tests are cut down versions of it designed to determine whether things were crashing, which they were originally); the `write` method implementation in question is definitely not callable at that point.

Not that I think we ought to alter these tests. They're making sure we don't do really bad things.

I'm actually more interested in why enabling valgrind is causing an empty call chain to be generated (which is what this particular error message is reporting) when otherwise there is no error. That makes me suspicious that there's a Use-After-Free present or that some flag isn't being set correctly...

NB: I can't run valgrind on this machine.

[7842f33a5c] is indeed related.

sebres ›	apn, related to 7c934f4a3d5fbe0c (oo error), I saw the same without valgrind, but testing with -singleproc 1