Migrate all assert macros in ApplicationLibCode to CAF_ASSERT and remove every
use of cvfAssert.h.
CVF_ASSERT is replaced one to one. CVF_TIGHT_ASSERT is also replaced by
CAF_ASSERT, which is semantically exact: CVF_ENABLE_TIGHT_ASSERTS is 1 only
under _DEBUG, and that is what CAF_ASSERT now does. The two CVF_FAIL_MSG sites
become CAF_ASSERT( false && "message" ), preserving the message with the idiom
already used elsewhere in the code base.
Counts before and after: CVF_ASSERT 1044 to 0, CVF_TIGHT_ASSERT 66 to 0,
CVF_FAIL_MSG 2 to 0, cvfAssert.h references 154 to 0.
Include handling: files that included cvfAssert.h directly now include
cafAssert.h instead, includes left dead by the migration are removed, and files
that were relying on cvfAssert.h transitively get an explicit cafAssert.h. Files
that reach cafAssert.h through another caf header are left unchanged; a missing
include here is a compile error, not a silently disabled assert.
ResultStatisticsCache links only LibCore and therefore had no path to
cafAssert.h. Add the cafPdmCore directory as a private include path rather than
linking the library, since cafAssert.h is header only.
Note that this stops these asserts from firing in Release and RelWithDebInfo,
where CVF_ASSERT was previously active.
Address sanitizer detected a memory leak in CmdFeatureMenuBuilder::MenuItem
objects caused by RiuContextMenuLauncher objects that were never deleted.
Problem: The RiuContextMenuLauncher class has two constructors:
1. RiuContextMenuLauncher(widget, CmdFeatureMenuBuilder&) - sets parent ✓
2. RiuContextMenuLauncher(widget, QStringList&) - missing parent ✗
The second constructor was missing the parent initialization, causing all
RiuContextMenuLauncher objects created with QStringList (used in 10+ locations)
to never be deleted, leading to memory leaks of their internal MenuItem vectors.
Root cause: Missing parent-child relationship meant Qt couldn't automatically
clean up these objects when their associated widgets were destroyed.
Fix: Added `: QObject( widget )` to the second constructor to match the first
constructor's behavior. This ensures Qt's automatic parent-child cleanup
handles the RiuContextMenuLauncher lifecycle properly.
This fixes the systemic issue affecting multiple plot types including:
- Correlation plots, Analysis plots, VFP plots, Well allocation plots
- All locations using `new RiuContextMenuLauncher(widget, {commands})`
Address sanitizer detected a memory leak in CmdFeatureMenuBuilder::MenuItem
objects allocated during context menu creation.
Problem: The RiuContextMenuLauncher constructor was creating a temporary
CmdFeatureMenuBuilder object, populating it with menu items, then copying
the entire object to the member variable m_menuBuilder. This caused
unnecessary memory allocation and copying of std::vector<MenuItem> data.
Root cause: Inefficient constructor implementation:
caf::CmdFeatureMenuBuilder menuBuilder; // temp object
for (cmd : commandIds) menuBuilder << cmd; // populate temp
m_menuBuilder = menuBuilder; // copy entire vector (leak source)
Fix: Build the menu directly into the member variable instead of creating
a temporary object and copying it:
for (cmd : commandIds) m_menuBuilder << cmd; // direct construction
This eliminates the unnecessary temporary object creation and copy operation
that was causing the MenuItem vector allocation detected by the sanitizer.
The fix maintains identical functionality while being more efficient.
* Add plotContentAsText() to bar chart builder
* Add show plot data to analysis plot
* Refactor analysis plot
* Enable context menu in Analysis Plot
* Add show plot data for general RimPlots
* Show plot data for correlation report in three separate text dialogs
Magne Sjaastad
Kristian Bendiksen
Gaute Lindkvist