Bug 2370942 - Incompatibility between vtk and expat on reading XML files with AppendedData
Summary: Incompatibility between vtk and expat on reading XML files with AppendedData
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: vtk
Version: 43
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Orion Poplawski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2025-06-07 10:31 UTC by Théodore Papadopoulo
Modified: 2026-06-25 16:24 UTC (History)
4 users (show)

Fixed In Version: vtk-9.2.6-45.fc43
Clone Of:
Environment:
Last Closed: 2026-06-25 16:24:21 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Data file (21.03 KB, application/xml)
2025-06-07 10:32 UTC, Théodore Papadopoulo
no flags Details
Source code showing the problem (523 bytes, text/x-csrc)
2025-06-07 10:33 UTC, Théodore Papadopoulo
no flags Details
Python code showing the proper output and that the python module uses its own vtk libs (206 bytes, text/plain)
2025-06-07 10:34 UTC, Théodore Papadopoulo
no flags Details
Patch to use for the vtk spec (2.41 KB, patch)
2025-06-07 11:51 UTC, Théodore Papadopoulo
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Fedora Package Sources vtk pull-request 33 0 None None None 2026-06-09 11:17:50 UTC

Description Théodore Papadopoulo 2025-06-07 10:31:31 UTC
vtk-9.2.6-36 and expat-2.7.1-1 seem to be incompatible when reading XML files with a field AppendedData. The problem seems to be identified (https://gitlab.kitware.com/vtk/vtk/-/commit/db8f9efca220c9d16a30958e179abae3379d0011) and a commit has been committed to the git repository for more than one year. Unfortunately, there is no released version containing that patch since then !

In consequence, all software that attempt to read such XML files are broken. Notable exceptions are paraview and the python-vtk module which seem to bundle their own versions of vtk... 

I have tried older versions of libexpat with LD_LIBRARY_PATH but libexpat.so.1.10.0 has the same failure and libexpat.so.1.9.0 has symbol issues (as it can have been expected).

Thus there seems to be no simple workaround to the problem besides patching either vtk (I'm currently re-building the vtk rpm with the above patch) or libexpat (which seems complicated to me).

Reproducible: Always

Steps to Reproduce:
1.Compile the small program given in attachment with the command
  g++ -O3 -I/usr/include/vtk -o vtp vtp.cxx -lvtksys -lvtkIOXML -lvtkCommonCore
2.Execute the program with the file provided in attachment
 ./vtp HeadNNa2.vtp
3. The python script (in attachment) shows the proper output (and indicates that the python uses a vtk/expat variant different from the installed libraries).

Actual Results:
2025-06-07 11:59:29.033 (   0.015s) [        7BE90B40]       vtkXMLParser.cxx:375    ERR| vtkXMLDataParser (0x23c43a70): Error parsing XML in stream at line 34, column 14, byte index 2433: not well-formed (invalid token)
2025-06-07 11:59:29.037 (   0.015s) [        7BE90B40]       vtkXMLReader.cxx:521    ERR| vtkXMLPolyDataReader (0x23c3e520): Error parsing input file.  ReadXMLInformation aborting.
2025-06-07 11:59:29.037 (   0.016s) [        7BE90B40]       vtkExecutive.cxx:740    ERR| vtkCompositeDataPipeline (0x23c2cde0): Algorithm vtkXMLPolyDataReader (0x23c3e520) returned failure for request: vtkInformation (0x23c41580)
  Debug: Off
  Modified Time: 90
  Reference Count: 1
  Registered Events: (none)
  Request: REQUEST_INFORMATION
  ALGORITHM_AFTER_FORWARD: 1
  FORWARD_DIRECTION: 0


0 0


Expected Results:
528 1062

Additional Information:
Potentially all apps using vtk may be affected.

Comment 1 Théodore Papadopoulo 2025-06-07 10:32:41 UTC
Created attachment 2093339 [details]
Data file

Comment 2 Théodore Papadopoulo 2025-06-07 10:33:48 UTC
Created attachment 2093340 [details]
Source code showing the problem

Comment 3 Théodore Papadopoulo 2025-06-07 10:34:49 UTC
Created attachment 2093341 [details]
Python code showing the proper output and that the python module uses its own vtk libs

Comment 4 Théodore Papadopoulo 2025-06-07 11:50:33 UTC
Just checked that the patch in vtk corrects the problem (by interposing a small shared library with the current git code for vtkXMLDataParser).
Thus adding the patch in attachment to the vtk rpm build should solve the problem.

Comment 5 Théodore Papadopoulo 2025-06-07 11:51:47 UTC
Created attachment 2093357 [details]
Patch to use for the vtk spec

Comment 6 Steve Holland 2025-07-13 19:05:55 UTC
Looks like VTK 9.4 or above would have this issue solved.

Comment 7 Fedora Release Engineering 2026-05-06 13:10:41 UTC
This message is a reminder that Fedora Linux 42 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 42 on 2026-05-13.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '42'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 42 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 8 Aoife Moloney 2026-06-08 17:27:12 UTC
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 9 Théodore Papadopoulo 2026-06-09 10:43:40 UTC
But the error is still present on Fedora 43, which remains with the same vtk version !!!

Comment 10 Aoife Moloney 2026-06-09 11:16:01 UTC
Fedora Linux 42 entered end-of-life (EOL) status on 2026-05-27.

Fedora Linux 42 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 11 Ankur Sinha (FranciscoD) 2026-06-09 11:17:51 UTC
Hi Theodore,

I've opened a PR here with the patch included. It built fine on my local machine, but we'll wait for CI to run it on all targets. We should then be able to push it as an update for F43 too.

Sorry for the delay. In the long run, it's probably better to upgrade to F44, since older releases do not get new major package updates in Fedora, as per the updates policy:

I've bumped the release here to prevent the bug from being automatically closed again.

Cheers,

Comment 12 Ankur Sinha (FranciscoD) 2026-06-09 11:18:35 UTC
Forgot the link to the policy:

https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#stable-releases

Comment 13 Théodore Papadopoulo 2026-06-10 09:38:29 UTC
(In reply to Ankur Sinha (FranciscoD) from comment #11)
> Hi Theodore,
> 
> I've opened a PR here with the patch included. It built fine on my local
> machine, but we'll wait for CI to run it on all targets. We should then be
> able to push it as an update for F43 too.
> 
> Sorry for the delay. In the long run, it's probably better to upgrade to
> F44, since older releases do not get new major package updates in Fedora, as
> per the updates policy:

Thank you very much.
For the upgrade I agree, but I'm not totally free to make the step (normally, we are allowed
to switch a little after the release).

Yet, the bug remains for all the users of F43 (and F42 before) and that was why I reported it.
For OpenMEEG (which is where I detected the bug), I made a interposition library to workaround
the problem, so I'm no longer exposed to it for my own use (and that of OpenMEEG users).

Thank you again.

Comment 14 Fedora Update System 2026-06-16 09:47:06 UTC
FEDORA-2026-4036ef95fe (vtk-9.2.6-45.fc43) has been submitted as an update to Fedora 43.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-4036ef95fe

Comment 15 Fedora Update System 2026-06-17 08:31:20 UTC
FEDORA-2026-4036ef95fe has been pushed to the Fedora 43 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-4036ef95fe`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-4036ef95fe

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2026-06-25 16:24:21 UTC
FEDORA-2026-4036ef95fe (vtk-9.2.6-45.fc43) has been pushed to the Fedora 43 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.