Python Segmentation fault (core dumped) bei Nutzung von matplotlib.pyplot

[Woodz]

Hallo.

Ich habe die Frage auch schon bei stackoverflow gepostet und wollte es auch hier nochmal probieren.

Aktuell bekomme ich einen seqmentation fault, wenn ich mit Hilfe von matplotlib eine Karte erstellen will.

import matplotlib.pyplot as plt
import cartopy.crs as ccrs


print(f'backend used: {plt.get_backend()}\n')

ax = plt.axes(projection=ccrs.NorthPolarStereo(central_longitude=10.0))
ax.set_extent([6.2, 14.6, 47.1, 55]) # <-- hier findet das Problem statt.

Es macht auch keinen Unterschied welches Backend ich mit matplotlib nutze 'agg' oder 'tkagg'. Der Fehler findet immer statt.
Hier noch die Versionen der von mir verwendeten Module:
matplolib: 3.7.1
cartopy: 0.21.1
shapely: 2.1.1

Auf einem anderen System (minimized Ubuntu Server) ohne GUI läuft das script ohne Probleme.

Beste Grüße

 

[NameHere]

Auf einem anderen System (minimized Ubuntu Server) ohne GUI läuft das script ohne Probleme.

python Version auch gleich?
Würde auch anderen Pakete abgleichen.

 

[Skudrinka]

Bin bei sowas immer neugierig ob und wie gut die KI ist.
Daher poste ich mal ihre Antwort und bin gespannt, ob es helfen kann

Hallo! Danke für die ausführliche Beschreibung – das hilft sehr.


Ein Segmentation Fault in Python (insbesondere mit Matplotlib/Cartopy) weist häufig auf ein Problem in einer darunterliegenden nativen Bibliothek (C/C++-Abhängigkeiten) hin – typischerweise:

• GEOS (von Shapely genutzt),
• Proj (für Kartentransformationen),
• GDAL,
• oder matplotlib selbst im Zusammenspiel mit GUI-Backends (Tkinter, Qt, etc.).

---

🧩 Mögliche Ursachen & Lösungen​

1.​

Cartopy 0.21.1 ist nicht vollständig kompatibel mit Shapely >= 2.0, da Shapely 2.x einige interne APIs verändert hat.


Das führt oft zu Segfaults, besonders wenn set_extent() aufgerufen wird – wie bei dir!

✅ Lösung:​

Installiere Shapely 1.8.x, z. B.:


pip install "shapely&lt;2.0"<br>

Oder in Conda:


conda install shapely=1.8<br>

Danach unbedingt alle Caches löschen oder ein neues Environment nutzen.

---

2.​

Wenn du Cartopy über pip installiert hast, kann es sein, dass es gegen andere native Bibliotheken gelinkt ist als shapely.

✅ Empfehlung:​

Nutze conda, um ein frisches Environment zu erstellen, z. B.:


conda create -n kartentest python=3.10 cartopy matplotlib shapely=1.8<br>conda activate kartentest<br>

So stellst du sicher, dass alles konsistent ist.

---

3.​

Um sicherzugehen, dass das Problem nicht woanders liegt, kannst du ein minimales Script testen:


import matplotlib.pyplot as plt<br>import cartopy.crs as ccrs<br><br>print(f'backend used: {plt.get_backend()}')<br><br>fig, ax = plt.subplots(subplot_kw=dict(projection=ccrs.NorthPolarStereo(central_longitude=10.0)))<br>ax.coastlines()<br>plt.show()<br>

Wenn das geht, aber set_extent() crasht: sehr wahrscheinlich Shapely 2.x Bug.

---

4.​

Als Test – funktioniert set_extent() mit einer einfachen Projektion?


ax = plt.axes(projection=ccrs.PlateCarree())<br>ax.set_extent([6.2, 14.6, 47.1, 55])<br>

Wenn das geht, liegt es sehr wahrscheinlich an der Kombination aus Projektion + Shapely/GEOS.

---

🧪 Fazit​

Dein Setup ist sehr wahrscheinlich instabil, weil Cartopy 0.21.1 nicht mit Shapely 2.1.1 getestet wurde. Das Problem ist auch auf Github in mehreren Issues dokumentiert, z. B.:

• https://github.com/SciTools/cartopy/issues/1825

---

Möchtest du, dass ich dir ein funktionierendes conda-Environment für diesen Fall vorschlage?

 

[Drexel]

Ohne die Lib zu kennen. Hatte ein Segmentation Fault mal bei Qt für Python. Die Qt Binaries für ARM64 vom Installer waren unter Ubuntu erstellt worden, ich wollte sie auf einem Raspberry nutzen. Aber die C oder C++ Standard Library Version unter Ubuntu war eine andere als unter RaspberryOS und das hat den Segmentation Fault verursacht, musste mir die Binaries unter RaspberryOS selbst bauen...

 

[Woodz]

Ich erhalte bei sämtlichen Beispielscripts diesen Fehler - interessant.
Es scheint also nicht an set_extents() zu liegen.

 

[KingLz]

Also ich finde .set_extent in der api für Axes nicht:

https://matplotlib.org/stable/api/axes_api.html

In der Suche gab es set_extent nur für Image/Axesimage:

https://matplotlib.org/stable/api/image_api.html

Ohne es auszuprobieren denke ich da fehlt der Zwischenschritt mit dem Axesobjekt ein AxesImageobjekt zu erstellen:

irgendwie sowas in der art:

axi = plt.image.AxesImage(ax)
axi.set_extent(....)

Wie gesagt, habe es nicht ausprobiert, kann auch sein dass ich falsch liege.

 

[Woodz]

@KingLz Ja, da hab ich mich falsch ausgedrückt. Eigentlich werden durch plt.axes() "GeoAxes" erstellt, denen ich dann bestimmte Abmaße zuordne. Auf diesen GeoAxen kann ich dann später einen plot ausführen.



Ich hab bei matplotlib mal einen bug report erstellt und hoffe, dass di emir dort weiterhelfen können.

Ergänzung (31. Juli 2025)

python Version auch gleich?
Würde auch anderen Pakete abgleichen.

Python Version ist gleich
matplotlib ist gleich
shapely und cartopy sind auch gleich

 

[KingLz]

Wo hast du den Code her?

Altes Beispiel von einer alten Matplotlib?

 

[Woodz]

Der code ist von mir. An sich läuft der auch seit Jahren.
Ich sehe aber, dass ich wahrscheinlich vor 10 Tagen ein reguläres Systemupdate gefahren habe und auf dem anderen System, auf dem die Scripte laufen, nicht.

Da legt die Vermutung nahe, dass da im Hintergrund wirklich irgendwelche Bibliotheken aktualisiert wurden.

 

[KingLz]

Nach meiner Recherche existiert .set_extent für Axes aus Matplotlib eigentlich nicht.
(Also ich finde dazu in der Doku nichts oder bin blind)

Für GeoAxes (Aus Cartopy, erbt von Axes) existiert .set_extent allerdings schon:

https://scitools.org.uk/cartopy/docs/v0.13/matplotlib/geoaxes.html

GeoAxes statt Axes benutzen evtl?

 

[Woodz]

Ok. Ich scheine das Problem behoben zu haben.
Ich habe matplotlib, shapely und cartopy nun mal auf die aktuellsten Versionen angehoben:

• matplotlib: 3.10.5
• shapely: 2.1.1
• cartopy: 0.24.1

und das Programm läuft durch.
Mal schaun, ob das update der module nun nicht an anderer Stelle Probleme macht.

Ich danke Euch erst einmal für euren Beistand.

 

[SaschaHa]

Hat nicht unmittelbar mit dem Problem zu tun, aber auch ich hatte (und habe) aktuell Probleme mit Python. Zur Zeit nutze ich WinPython 3.13.3 und wollte gestern auf 3.13.5 upgraden. Ganz egal, mit welchen Mitteln ich die Migration versucht habe, es gab immer irgendwelche Konflikte mit zuvor funktionierenden Modulen, die plötzlich "inkompatibel" waren oder nicht normal installiert werden wollten. Das Problem ließ sich auch nach zahlreichen unterschiedlichen Lösungsansätzen und vielen Stunden der Verzweiflung nicht lösen, sodass ich nun erstmal bei der aktuell installierten Version bleibe und einen neuen Versuch erst mit Version 3.14.x starten werde.

Schlussfolgerung für mich war: Don't change a running system! In deinem Fall passt das zwar nicht, da du ja etwas ändern musstest (während das bei mir die Fehlerursache war), aber es zeigt halt, dass Python offenbar große Kompatibilitätsprobleme bei unterschiedlichen Modul- und Python-Versionen hat, auch in Bezug auf die verwendete Plattform. Zumindest 3.13.3 funktioniert bei mir zumindest relativ gut, wobei ich für ComfyUi eine Abhängigkeit zu einer inoffiziellen Version ändern musste, deren offizielle Version immer noch inkompatibel ist.

 

[Woodz]

Was mich halt ärgert, sind Abhängigkeiten von Bibliotheken außerhalb der Pythonwelt. Was ich mich schon mit Tkinter, GDAL und jetzt Cartopy rumgeärgert habe, weil die unter der Haube auf externe Bibliotheken zurückgreifen. Da helfen conda und pip environment nur bedingt und du weißt gar nicht was das Problem ist, weil du an deinem "Universum" ja gar nichts verändert hast.

 

[Drexel]

Ja Python ist halt Dreck, nur leider weit verbreiteter Dreck. =)

 

[N.N.]

Python ist halt Dreck

Na ja... Dreck würde ich nicht unbedingt sagen, aber es ist eben eine Scriptsprache, und afaik keine (high-/low-level) general-purpose programming language. Außerdem ist Python nicht primär object-oriented, oder? Und es ist schwach- bis gar nicht typisiert: https://de.wikipedia.org/wiki/Duck-Typing

Aber ich kann mich auch irren.