Unhandled access‑violation in BandGenLinLapackSolver::solve (DGBSV) — should inputs be pre‑validated?

[fabioflemingleitao]

When running a transient (seismic) analysis via OpenSeesPy with the BandGeneral solver, under certain dynamic loading the call to the LAPACK routine DGBSV in BandGenLinLapackSolver::solve() receives invalid arguments—such as mismatched band‑matrix dimensions or uninitialized pointers—and triggers a Windows “Access Violation” crash (0xC0000005). The Python kernel simply dies with no catchable error, making it impossible to handle the failure gracefully in Tcl/Python.

This issue started to appear in some of my analyses (NLTH in buildings). The code simply crashes.
I have a minimal working example (MWE) here: https://github.com/fabioflemingleitao/clean_model

Recently, I managed to debug the OpenSees C++ source using a Python input file via Visual Studio.
I identified that the problem occurs in the BandGenLinLapackSolver.cpp file, exactly at line 122 (DGBSV), as shown in the image.
At a certain point during the analysis, the input variables to the DGBSV function seem to have incompatible values, which causes the program to crash.
It might be worth implementing error handling for this situation, or adding a compatibility check of the variables before the function is executed.

[mhscott]

The MWE is the same you posted about a couple months ago. The script takes a long time to run and goes through many cases before the error appears. Please provide an example script that goes straight to the problem.

[fabioflemingleitao]

Hi Mr. Scott,

I believe I’ve found the cause of the issue. During some NLDA using OpenSees with the BandGenLinLapackSolver, I observed that the solution vector Xptr sometimes contains invalid values like "-nan(ind)" right before the solver call.

This appears to be the root cause of the crash when the LAPACK routine DGBSV is called within the BandGenLinLapackSolver::solve() function. Since DGBSV receives these invalid values, it likely fails during the factorization process and causes the program to terminate unexpectedly.

To confirm this, I added a simple check to print Xptr before the solver is called, and observed outputs like the one shown in the attached image.

This may be caused by numerical instability in the stiffness matrix assembly or residual force vector, perhaps due to a singular matrix, zero diagonal terms, or improper boundary conditions.

It would be very helpful if OpenSees included a validation step before calling DGBSV, to check whether key inputs like Xptr contain invalid numbers (e.g., NaN, inf, etc.). A simple check could help prevent a crash and at least allow the program to issue a warning or exit gracefully.

[mhscott]

A simple example would be still be helpful to track down the issue.