acquaman/acquaman — Issue #200: Building in debug mode triggers dacq problem: XAS scans mysteriously disable the energy PV (at least for VESPERSAcquaman)
Author: markboots
Created: 2011-11-20 05:10:24+00:00
State: open
Labels: Bug - Wrong Behaviour, Impact - High, Module - Acquisition

After wasting a week to track down why the multithreading + data view UI upgrades inexplicably broke the dacq for XAS scans, I finally found the offending line and commit. It was introduced in df64ee by a "Darren Hunter" (actually me, during the testing process):

```
acquamanCommong.pri:

+# Debug:
+CONFIG += debug
+
```

SERIOUSLY?

Yup. The config file. Testing using clean builds on the VESPERS OPI (opi1607-103) is absolutely consistent: The problem with (null) column output for the energy PV in XAS dacq scans has NOTHING to do with any code changes; it depends only on whether the executable is compiled in debug mode. The problem can be triggered (/eliminated) at any stage of the commit history by adding (/removing) this line and doing a clean build.

This completely explains why the problem was appearing/disappearing inexplicably without a consistent relationship to the commits we were testing. When working on Darren's laptop, Qt Creator may have applied its own settings for whether to create (and/or run) a debug build. It also explains why clean rebuilds were necessary to diagnose the problem: partial builds with the debug config added/removed would not have re-built all object files.

Currently, the latest master runs reliably on the beamline as long as it is built in release mode. However, to me this problem suggests a dependency on how binary code is laid out in the executable, and therefore I wouldn't expect it to keep working forever as more executable code gets added to the project. This might be a symptom of a serious memory error -- more testing with valgrind for memory violations could be helpful at getting to the root cause.