![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
billroperThe locking fixes that I put in seem to be working. Unfortunately, the client side of the product is now failing as we try to update reports using an external COM library. Better yet, it only fails in a release build when it isn't running under the debugger. This makes finding the problem exciting.
It turns out that we've stored a great many copies of the pointer to the COM object, so I figured if I eliminated all of the extra copies, maybe I could eliminate the bug.
Then I discovered that every once in a while, we use a different copy of the COM object that isn't the big shared one. So now I need to put the pointer back in the objects that collectively were holding too many copies of the pointer to the shared COM object, but ignore the value that's there when I should be using the shared pointer.
My brain hurts. I hate modifying other people's code, especially when it could use just a wee bit more documentation.
*sigh*
It turns out that we've stored a great many copies of the pointer to the COM object, so I figured if I eliminated all of the extra copies, maybe I could eliminate the bug.
Then I discovered that every once in a while, we use a different copy of the COM object that isn't the big shared one. So now I need to put the pointer back in the objects that collectively were holding too many copies of the pointer to the shared COM object, but ignore the value that's there when I should be using the shared pointer.
My brain hurts. I hate modifying other people's code, especially when it could use just a wee bit more documentation.
*sigh*