SVG importer crashing with a simple, large file from Inkscape 0.48 #38191
Labels
No Label
Interest
Animation & Rigging
Interest
Blender Cloud
Interest
Collada
Interest
Core
Interest
Documentation
Interest
Eevee & Viewport
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
Import and Export
Interest
Modeling
Interest
Modifiers
Interest
Nodes & Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds, Tests & Devices
Interest
Python API
Interest
Rendering & Cycles
Interest
Sculpt, Paint & Texture
Interest
Translations
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Meta
Good First Issue
Meta
Papercut
Module
Add-ons (BF-Blender)
Module
Add-ons (Community)
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender-addons#38191
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Ubuntu 13.10, NVIDIA Quadro 1000M
Blender Version
Broken: 2.69.0 r60991
Short description of error
While trying to import a very simple but large svg file I prepared (), Blender crashes.
The svg was originally generated in the browser with d3.js, then saved, read into inkscape 0.48, and from there exported as Plain SVG.
It contains some ~30 graphs (no fill, black stroke) , the markup is dead simple and can be easily read with a text editor.
The crash occurs still inside the python import script, this is the traceback:
Exact steps for others to reproduce the error
Changed status to: 'Open'
Added subscriber: @simonrepp
I'll look a bit into it, feel free to beat me to it in case you're familiar with the code and able to provide a fast fix.
Especially let me know if you think my svg file is the actual problem here ... Not that I created anything fancy there, but you never know ... :)
Thought i'd run the file through http://validator.w3.org ... and it validates.
That makes it less likely an Inkscape related problem, i guess.
Back to reading code ...
So the error occurs when the importer generates the geometry inside blender. (That is, after parsing, which seems to work fine)
Inside
class SVGGeometryPATH
an object (curve) is created, a bezier spline is added to it, then the script starts adding bezier points, copying over the coordinates from the parsed data.When printing the spline's bezier_points array length it becomes apparent that the error occurs right when an overflow happens:
32764
32765
32766
32767 (= signed 16 bit int range upper border)
So now the question is: Is this by design?
If Blender internally only allows splines with a maximum of 32767 points - and intentionally so - then this is not really a bug of the importer, but rather a shortcoming in gracefully handling this case and reporting that Blender does not support curves with that many points. If on the other hand, we would actually want Blender to be able to handle such an amount of spline data, we probably have to dig deeper and fix how (or in other words: with which type) the bezier points are allocated internally.
I hope my assessment of the situation is correct and I didn't overlook something else.
In any case, I would now need feedback to continue. TIA :)
Here's two little python snippets for triggering the issue directly from the console:
Create Curve (= 2 points) and add 32765 points = 32767 points - works
Create Curve (= 2 points) and add 32766 points = 32768 points - crashes
Added subscribers: @Sergey, @brecht
It seems reasonable to me to bump some members in the curve data structures like pntsu from short to int, since this seems quite low. But you'd need to carefully check all the files where such member variables are used, since they may still be assigned to shorts in some computations.
Changed status from 'Open' to: 'Resolved'
Fixed in D212