LinearSVC crashes with no errors when `max_iter` is hit

### Describe the bug

LinearSVC seems to fail with no warnings.
I think  it is when the number of iterations hit `max_iter` .
I've set `verbose=1` and `max_iter=1000`, and the exact moment it printed `iter 1000` the program crashed


### Steps/Code to Reproduce

The data consists of character-ngrams of various short texts by using `CountVectorizer` i.e `CountVectroizer(analyer="char_wb",ngram_range=(3,5), binary = True)`.

A dictionary consisting of the data can be found [here](https://github.com/Jakobhenningjensen/public/blob/main/sklearn_bugs/LinearSVC/linearSVC_data_dict.pkl)

```python
from sklearn.svm import LinearSVC
import pickle

with open("linearSVC_data_dict.pkl","rb") as f:
    data = pickle.load(f)

X_train = data["train"] # sparse matrix
y_train = data["target"]

model = LinearSVC(dual = True)
model.fit(X_train,y_train)
```


### Expected Results

The program does not crash or some error function atleast is raised

### Actual Results

There is no traceback. 
If I run the script directly as `python train.py` the script suddenly is just "done".

Doing it in an interactive window, the python-console just crashes with a non-zero exit status and the message `0xC0000005`

Running the training in Google Vertex I get at SIGSEV(139) error.

Note, I have used a machine with 664 GB RAM, which I assume should be enough. The error occurs if `n_jobs=-1`, `n_jobs=5`, `n_jobs=1` thus I don't think it's a memory issue

### Versions

```shell
System:
    python: 3.10.0 (tags/v3.10.0:b494f59, Oct  4 2021, 19:00:18) [MSC v.1929 64 bit (AMD64)]
executable: C:\Users\Hennings\AppData\Local\pypoetry\Cache\virtualenvs\transtovat-2_ekYx-D-py3.10\Scripts\python.exe
   machine: Windows-10-10.0.22621-SP0
Python dependencies:
      sklearn: 1.2.2
          pip: 22.3.1
   setuptools: 67.7.2
        numpy: 1.24.3
        scipy: 1.10.1
       Cython: None
       pandas: 1.5.3
   matplotlib: 3.7.1
       joblib: 1.2.0
threadpoolctl: 3.1.0
Built with OpenMP: True
threadpoolctl info:
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: C:\Users\Hennings\AppData\Local\pypoetry\Cache\virtualenvs\transtovat-2_ekYx-D-py3.10\Lib\site-packages\numpy\.libs\libopenblas64__v0.3.21-gcc_10_3_0.dll
        version: 0.3.21
threading_layer: pthreads
   architecture: SkylakeX
    num_threads: 16
       user_api: blas
   internal_api: openblas
         prefix: libopenblas
       filepath: C:\Users\Hennings\AppData\Local\pypoetry\Cache\virtualenvs\transtovat-2_ekYx-D-py3.10\Lib\site-packages\scipy.libs\libopenblas-802f9ed1179cb9c9b03d67ff79f48187.dll
        version: 0.3.18
threading_layer: pthreads
   architecture: Prescott
    num_threads: 16
       user_api: openmp
   internal_api: openmp
         prefix: vcomp
       filepath: C:\Users\Hennings\AppData\Local\pypoetry\Cache\virtualenvs\transtovat-2_ekYx-D-py3.10\Lib\site-packages\sklearn\.libs\vcomp140.dll
        version: None
    num_threads: 16
```

COMMENT:
> Perhaps the large number of support vectors in a large space is causing a problem? Are they being converted from sparse to dense somewhere?

But shouldn't that throw an `OOM` error?

Labels: Needs Reproducible Code