Fixing #165 #167
Fixing #165 #167
Conversation
|
✅ Build pvAccessCPP 1.0.6 completed (commit 8990fc5e92 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.12 failed (commit 6bdc5fc043 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.16 failed (commit 448cc527ac by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.18 failed (commit 6188e43175 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.19 failed (commit d5cd826d62 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.20 failed (commit b81c4dc135 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.21 failed (commit cbf4c97ff8 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.22 failed (commit b42fd91bae by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.23 failed (commit 31cab43e42 by @anjohnson) |
|
@anjohnson fyi. If you rebase this branch you should (for the 7.0 builds) have automatic analysis of any tests which crash. |
Loop the tests so we check for destroying the caProvider. Move the shutdown call inside the try/catch.
Moved duplicated EXCEPTION_GUARD macro to private header file. Removed all DEBUG_LEVEL and similar prints. Some reformatting and code simplification.
This passes the tests (on MacOS).
Channel connection notifications are now handled by connectNotifier, getDone, putDone and monitor events handled by resultNotifier. A notifierConveyor is generic, and contains a queue and a thread. You pass a Notification pointing to a NotifierClient to a Conveyor's notifyClient() method, and the thread will call the client's notifyClient() method once it reaches the front of the queue. The conveyor threads stop when the caProvider is destroyed. The queue stores weak pointers, so queued notifications won't prevent client objects from being destroyed.
Each instance of the caContext class represents a separate CA context, so each CAChannelProvider creates one and keeps a shared_ptr to it, making that available to its channels and channel operations. These also take their own shared_ptr to it as well so the context cannot be destroyed while it might be needed. A related caContext Attach object is intended to be short-lived, and to be allocated on the stack. When created it saves the current CA context for the thread, replacing it from the caContext given to its constructor. CA operations will now use the attached context. When the Attach destructor runs it detaches the thread from the current context (checking still has the expected value) and re-attaches the thread to any context that was saved by the constructor.
This is still broken if a client method (notify() or the destructor) deletes the conveyor, which accesses data members before exiting.
|
Assuming the Appveyor builds don't fail, I think this is now done. I added a separate test program for the notifyConveyor, and restructured the |
|
❌ Build pvAccessCPP 1.0.28 failed (commit 512c477b0e by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.29 failed (commit 20f60679e3 by @anjohnson) |
|
❌ Build pvAccessCPP 1.0.30 failed (commit 3342b91076 by @anjohnson) |
|
The 3.15 DLL builds fail with: wrt. I've yet to find a good explanation for what is happening. LNK1318 seems to mean something went wrong with a (the?) local debug symbol server. Given the intermittent occurrences, one "resolution" stands out to me:
Maybe this could be avoided by preemptively launching a single instance? (MSVC debug symbol handling is so complicated...) |
|
✅ Build pvAccessCPP 1.0.31 completed (commit 61a224643b by @anjohnson) |
|
The appveyor build passed once. I've restarted it, and will likely do so a couple of more times, in an attempt to provoke a hang. If not, then I'll merge. |
|
❌ Build pvAccessCPP 1.0.32 failed (commit 61a224643b by @anjohnson) |
|
This build failure occurred while linking In an earlier failed build the same random error has happened while linking Thanks for re-triggering the build just now, I still don't have the ability to manage/configure the projects in the epics-base account. |
Well I am convinced that it has nothing whatsoever to do with caProvider. I see this error occasionally with other projects. It just seems to happen more often with pvAccessCPP. Go figure. Another CI nuisance which will eventually be sorted out. |
|
We appear to have switched between |
|
If you are looking for something to try, |
|
❌ Build pvAccessCPP 1.0.33 failed (commit 61a224643b by @anjohnson) |
|
✅ Build pvAccessCPP 1.0.34 completed (commit 61a224643b by @anjohnson) |
|
Four runs with no hang. That's good enough for now. |
|
Thanks. We already use
The error is coming from the linker and I don't see any relevant flags for that. |
I've been paying more attention to these failures in the past week. I've only seen this error with VS 2017 builds. Not 2015 nor 2019. Maybe this really is a toolchain bug? |
|
Possibly, this might confirm that. They all seem to be 2017 static debug builds; maybe we should just exclude that particular combination? |
Incomplete, hoping this PR will trigger an Appveyor build...