As far as I know the cameras on the beamline are running on EPICS base versions ranging from 7.0.1 to 7.0.3, and the camera I am testing is running R7.0.3.1.
I just recompiled everything to make sure it has all been built against the correct base, and reran with valgrind, and it does seem that the issue is memory access:
==32571== Invalid write of size 8
==32571== at 0x10FAD50: ellDelete (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x1110645: free_threadInfo.part.0 (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x111087F: start_routine (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x681C6DA: start_thread (pthread_create.c:463)
==32571== by 0x7AE988E: clone (clone.S:95)
==32571== Address 0x321915f8 is 8 bytes inside a block of size 170 free'd
==32571== at 0x4C30D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32571== by 0x111087F: start_routine (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x681C6DA: start_thread (pthread_create.c:463)
==32571== by 0x7AE988E: clone (clone.S:95)
==32571== Block was alloc'd at
==32571== at 0x4C31B25: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==32571== by 0x11103B6: init_threadInfo (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x1111357: epicsThreadCreateOpt (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x1109E56: epicsThreadCreate (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x10B72D3: req_server (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x11107C7: start_routine (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x681C6DA: start_thread (pthread_create.c:463)
==32571== by 0x7AE988E: clone (clone.S:95)
==32571==
Then finally the pthread error and Segfault, and valgrind lists "access not within mapped region" as the cause
pthread_join error No such process
pthread_join error No such process
==32571==
==32571== Process terminating with default action of signal 11 (SIGSEGV)
==32571== Access not within mapped region at address 0x8
==32571== at 0x10FAD50: ellDelete (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x1110645: free_threadInfo.part.0 (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x1111D8B: epicsThreadMustJoin (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x10B68DE: destroy_tcp_client (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x10B74FC: camsgtask (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x11107C7: start_routine (in /epics/src/support/areaDetector/ADUVC/iocs/adUVCIOC/bin/linux-x86_64/adUVCApp)
==32571== by 0x681C6DA: start_thread (pthread_create.c:463)
==32571== by 0x7AE988E: clone (clone.S:95)
==32571== If you believe this happened as a result of a stack
==32571== overflow in your program's main thread (unlikely but
==32571== possible), you can try to increase the size of the
==32571== main thread stack using the --main-stacksize= flag.
==32571== The main thread stack size used in this run was 8388608.
==32571==
==32571== HEAP SUMMARY:
==32571== in use at exit: 95,935,018 bytes in 345,749 blocks
==32571== total heap usage: 762,443 allocs, 128,925 frees, 8,380,446,680 bytes allocated
==32571==
==32571== LEAK SUMMARY:
==32571== definitely lost: 532,602 bytes in 8,403 blocks
==32571== indirectly lost: 0 bytes in 0 blocks
==32571== possibly lost: 26,580,722 bytes in 37,063 blocks
==32571== still reachable: 68,112,742 bytes in 315,085 blocks
==32571== of which reachable via heuristic:
==32571== newarray : 1,920 bytes in 18 blocks
==32571== suppressed: 0 bytes in 0 blocks
==32571== Rerun with --leak-check=full to see details of leaked memory
==32571==
==32571== For counts of detected and suppressed errors, rerun with: -v
==32571== Use --track-origins=yes to see where uninitialised values come from
==32571== ERROR SUMMARY: 2057 errors from 33 contexts (suppressed: 0 from 0)
Segmentation fault (core dumped)
Now the question becomes what have I done to cause this improper memory access - I ran an IOC from the same sources with ADSimDetector and did not see this issue, at least not in my limited test time.