Segfault and memory leak on large data creation

[ThomasMalletCodra]

Windows crash in long-running test sessions due to GDI handle exhaustion (suspected object lifetime/cache issue)

Describe the bug

On Windows, PythonQwt may crash with an access violation during long-running test sessions.

The failure appears after extended execution (on a large test run on Windows), which is consistent with Windows GDI handle exhaustion. Windows limits GDI handles to roughly 10,000 per process, and the process seems to exceed that limit over time.

Current analysis suggests the issue is linked to object lifecycle and cache management in PythonQwt, especially for internal private data objects backed by Qt/C++ resources.

Regression might be introduced after optimization : #93

To Reproduce

1. Run a large PythonQwt-dependent test suite on Windows in a single process with large data creation
2. Monitor process GDI handle count over time (for example with Task Manager or Process Explorer).
3. Continue until late-stage execution.
4. Observe continuous handle growth and eventual crash/access violation near the GDI limit.

Ideas

• Reintroduce QObject inheritance for the three affected PrivateData classes to ensure proper destruction and Qt-managed lifetime behavior.
• Remove slots in these classes (suspected to interact poorly with asynchronous deallocation/lifetime expectations).
• Add a defensive cache size limit.

[ThomasMalletCodra]

@dappham-CODRA

I think the right direction is to derive a dedicated PythonQwt non-regression test from the scenario that exposed the issue in DataLab, without keeping any DataLab-specific dependency.

Reference scenario

The DataLab test that revealed the problem is based on a very simple idea: create a large synthetic dataset, turn it into many logical signals, load them through the real GUI path, and let the rendering layer deal with a large amount of object creation and painting work.

In other words, the interesting part is not the CSV import itself, nor the DataLab object model, but the pressure created by:

• large in-memory signal data,
• many graphical objects created from that data,
• real Qt show / paint / event cycles,
• repeated lifecycle operations on widgets/items.

What should be kept vs removed

For a PythonQwt regression test, we should keep the stress pattern but remove everything that belongs to DataLab:

Keep:

• large synthetic datasets,
• many objects created from those datasets,
• real rendering through Qt,
• repeated create/show/processEvents/close/destroy cycles.

Remove:

• CSV generation,
• pandas I/O,
• DataLab SignalPanel,
• DataLab SignalObj / application workflow,
• save/load application logic.

Why the existing PythonQwt loadtests are not enough

We already have useful performance-oriented tools:

• qwt/tests/test_loadtest.py
• scripts/bench_plotpy_loadtest.py
• scripts/lineprofile_loadtest.py

These are very helpful for benchmark/profiling work, especially around issue #93, but they are not really aimed at resource-lifetime regression detection.

Their main question is essentially:

• “how long does construction/rendering take?”

For issue #107, the question is different:

• “does repeated creation/render/destruction stay stable over time on Windows, or do GDI handles / memory usage drift until failure?”

Proposed dedicated regression test

I would suggest adding a dedicated pytest test focused on stability rather than speed.

The test idea would be:

1. Generate signal data directly with NumPy.
2. Create many curves / labels / plot-related objects in PythonQwt.
3. Attach them to real widgets/plots.
4. Call show() and QApplication.processEvents() to force actual rendering.
5. Close and destroy everything.
6. Repeat this cycle enough times to expose leaks or lifetime issues.

This keeps the scenario close to what exposed the bug originally, while making it fully PythonQwt-native.

So I would consider such a script optional, not the primary deliverable.

Optional VS Code task

It may also make sense to add a dedicated VS Code task for manual non-regression runs, for example to launch:

• the dedicated leak/stability test,
• or a longer stress/benchmark script for Windows validation.

I would keep that as a manual or opt-in task, not part of the default fast CI path, because:

• these tests may be slower,
• they may be more environment-sensitive,
• and benchmark-like checks tend to be noisy on shared runners.

Summary

So the proposal would be:

• add a dedicated PythonQwt non-regression test inspired by the DataLab large-signal scenario,
• keep it independent from DataLab,
• focus on repeated object creation / rendering / destruction,
• keep any extra stress script optional,
• and optionally expose it through a manual VS Code task for Windows validation.

This would complement the current performance loadtests with an actual regression guard for the segfault / memory leak / GDI exhaustion class of issues.