#133 XSPICE: reused plot names after destroy all can reconnect stale event data

[George]

While extending NgspiceTclBridge’s lifecycle tests, I found an issue with repeated mixed-signal simulations after deleting numeric plots.

The attached patch targets official SourceForge commit a80f6e3e95d51534905b1f23410a951802666656 (ngspice-47).

Observed behaviour

Running a mixed-signal simulation, executing destroy all, and running it again can produce:

• Missing digital-node callbacks during transient analysis.
• Stale digital values from ngGet_Evt_NodeInfo() during OP/DC analysis.

For example, an ADC input swept through 0 V, 1 V and 2 V initially returns 0s, Us, 1s. After destroying plots and repeating the sweep, the queried digital state can remain 1s throughout.

The issue reproduces without invoking the shared library’s command-memory cleanup operation.

Cause

Numeric plot names such as tran1 or dc1 can be reused after destroy all, while older XSPICE event jobs remain associated with the circuit.

During new plot initialization, plot_setcur() can select an older event job with the same name. Subsequently, EVTsetup_plot() records the new job’s plot name and index but does not restore its event-data pointers.

Also, EVTswitch_plot() searches from the oldest job, so duplicate names can select stale data.

Proposed fix

The patch updates src/xspice/evt/evtsetup.c to:

• Restore the new job’s node, state, message and statistics pointers in EVTsetup_plot().
• Search matching event jobs from newest to oldest in EVTswitch_plot().

Validation

On Linux, shared-library integration tests reproduced the failures before the fix and passed afterward. Coverage includes transient reruns, repeated transient/OP/DC transitions, plot destruction and 1,000 iterations per circuit/collection-mode combination.

Could you please review whether restoring the new job’s pointers at this point is the appropriate fix?

[Giles Atkinson]

Hard to make much sense of this: perhaps user error with LLM "assistance"? The "destroy" command is not documented to touch XSPICE event history, nor should it.

[George]

Hello, I am not proposing that destroy all should delete the XSPICE event history, I use destroy all to release numerical plots after collecting their results.

The issue here is that subsequent simulations can reuse numeric plot names, such as tran1, dc1, etc, and reconnect the event data assosiated with older job. In tests it produces stale digital values or missing callback in a new run. The proposed patch preserve history, but attempt to ensure that new analysis uses it's own event data.

Aside of that, what is the recommended way to release accumulated XSPICE event history between independent simulations while retaining the loaded circuit?

[George]

Small reproducer of the issue attached.

c -std=c99 -Wall -Wextra -I/path/to/ngspice/src/include event_plot_reuse.c \
-L/path/to/ngspice/src/.libs -Wl,-rpath,/path/to/ngspice/src/.libs \
-lngspice -o event_plot_reuse

Run with the matching digital.cm:

./event_plot_reuse /path/to/digital.cm
./event_plot_reuse /path/to/digital.cm --keep-plots

The program loads one ADC bridge and runs two identical DC sweeps. By default
it executes destroy all between sweeps. --keep-plots omits that command.
It prints the analog input and the latest digital state at each accepted DC point.

Expected on both sweeps:
V(in)=0 d=0s
V(in)=1 d=Us
V(in)=2 d=1s

Without the plot-reuse fix, the second sweep after destroy all instead gives:
V(in)=0 d=1s
V(in)=1 d=1s
V(in)=2 d=1s

Keeping plots, or applying ngspice-event-plot-reuse-fix.patch, gives the expected
values on both sweeps.

[Giles Atkinson]

Thank you for the test case. Your chatbot writes better code than description, but still mostly slop. The proposed fix looks plausible, but does not target the underlying cause and misses an opportunity to tidy up.

That cause is interesting: a bug in an unsuspected (at least by me) feature of "setplot": if you change the current plot to one generated by a previous simulation, saved XSPICE node history from that run is silently restored. As it is undocumented, that may be considered a horrible bug even if working properly. A good one to find!

I think a fix should include both documentation and a way to turn it off: with the original (and still default) behaviour of saving all XSPICE node history, it is a memory hog. I am amazed that such a thing was written at a time when 16Mb of main memory was considered generous for tens of simultaneous users.