Comment 103 for bug 1835296

I have the fear that we are curing symptoms, but not yet have found the root cause.

Yesterday I have got a new crash with similar cause, after compiling with debug symbols. All we have seen here is always about the initialization of the device count number that ngspice uses, and only when we add the XSPICE devices like spice2poly.

This device count number gets inconsistent, and thus may create a buffer overflow, when trying to read the device parameters. Yesterday's crash occured occured early in the ngspice initialization routine because the device number had already been set (that typically is done later during the initialization).

What may be the reason?
- Calling ngspice initialization twice (currently ngspice does not safeguard against this request)
- Loading the codemodels before initialization
- ... ?

And there has been a change in the ngspice code for creating this number (in between ngspice-26 and ngspice-27 releases). It used to be hard-wired before, now it is evaluated dynamically (ngspice/src/spicelib/devices/dev.c), thus taking into account various (seldom used) compile options concerning device selections. And therefore it has become sensitive to double initialization ...

Unfortunately the crashes are not easily to reproduce because of some macOS internal states. When I manage to achive that, I will look into this (I am not a fan of command line debuggers like lldb). It the should be easily possible to safeguard against double initialization in ngspice. There is code in eeschma ngspice.cpp to prevent double initialization, but what if this is called from a different thread? And why do we need libngspice-0.dylib twice in the distribution?