Skip to content

[Bug]: Compiler Flag Drift May Affect matplotlib ABI Stability via Memory Assumptions #30064

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
BryteLite opened this issue May 18, 2025 · 2 comments
Labels
status: needs clarification Issues that need more information to resolve.

Comments

@BryteLite
Copy link

BryteLite commented May 18, 2025

Bug summary

Summary

Matplotlib may be vulnerable to ABI and memory alignment issues caused by C23 default behaviors in GCC 15.1. Silent adoption of padding behavior changes — particularly in union or struct definitions used in NumPy or Pandas C extensions — may lead to unpredictable runtime behavior.

This issue was originally identified in NumPy, Cython and Meson. As Matplotlib includes Meson and relies on NumPy for internal memory layout, it is downstream vulnerable.

These compiled pieces are sensitive to pointer alignment, ABI expectations, or padding behaviors — especially across environments.

##Reproducible Example

Please see section below

Possibly related to:

Bug: interpolation_stage="data" removes too many pixels in the vicinity of nans in upsampled, interpolated images
Bug: memory baking figure is not freed when figure is closed
Missing type hints for matplotlib.dates.DateFormatter
MNT: Python 3.14.0a7 test failures

While these examples originate from different baselines, they exhibit a common theme: ABI drift between independently compiled modules. This behavior may also be present in earlier releases where build procedures lacked explicit compilation flags across Python packages.

Report for more context:
Report

Code for reproduction

import numpy as np
import matplotlib.pyplot as plt

# Create a matrix with a single NaN value
matrix = np.ones((5, 5))
matrix[2, 2] = np.nan

fig, axs = plt.subplots(1, 2, figsize=(10, 5), layout="constrained")

# Interpolation at data stage
axs[0].imshow(matrix, interpolation="bilinear", interpolation_stage="data")
axs[0].set_title("Stage: data (NaN overspill?)")

# Interpolation at RGBA stage
axs[1].imshow(matrix, interpolation="bilinear", interpolation_stage="rgba")
axs[1].set_title("Stage: rgba (Expected NaN spread)")

plt.suptitle("NaN Propagation Comparison by Interpolation Stage")
plt.show()

Actual outcome

Interpolating at the data stage causes NaN values to overspill far beyond their origin, resulting in unexpected blank areas in plots. By contrast, the same data interpolated at the rgba stage shows localized NaN effects, which aligns with user expectation.

This may reflect memory interpretation differences in how NaNs are detected in interpolated image data, potentially tied to buffer access order or build settings.

Expected outcome

NaNs should propagate locally during bilinear interpolation. The presence of a single NaN should not render large swaths of the image as undefined when interpolating at the data stage.

Additional information

Matplotlib version: e.g., 3.10.3

Backend: Agg or default interactive backend

Python version: 3.13.X

NumPy version: 2.2.5 (2.2.6 was just recently released)

Operating system

No response

Matplotlib Version

3.10.3

Matplotlib Backend

No response

Python version

3.13.3

Jupyter version

No response

Installation

None

@eli-schwartz
Copy link

@jklymak jklymak added the status: needs clarification Issues that need more information to resolve. label May 18, 2025
@jklymak
Copy link
Member

jklymak commented May 18, 2025

Agreed - this reads like it is bot generated. Also even if this were an in good faith report, GitHub is not the replace to make the report. https://github.com/matplotlib/matplotlib/security

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: needs clarification Issues that need more information to resolve.
Projects
None yet
Development

No branches or pull requests

3 participants