Segmentation fault when appending None to Collection types #1680
Labels
bug
A problem, flaw, or broken functionality.
good first issue
If you're looking for a way to contribute, but not sure where to start. This is a good first issue.
Comments
|
OpenTimelineIO/src/py-opentimelineio/opentimelineio/core/_core_utils.py Lines 359 to 360 in 17e9297 Here is the backtrace with OTIO built in debug mode: |
|
A fix could simply be something like diff --git a/src/py-opentimelineio/opentimelineio-bindings/otio_serializableObjects.cpp b/src/py-opentimelineio/opentimelineio-bindings/otio_serializableObjects.cpp
index c52ab4c..37c5957 100644
--- a/src/py-opentimelineio/opentimelineio-bindings/otio_serializableObjects.cpp
+++ b/src/py-opentimelineio/opentimelineio-bindings/otio_serializableObjects.cpp
@@ -521,9 +521,9 @@ Should be subclassed (for example by :class:`.Track` and :class:`.Stack`), not u
index = adjusted_vector_index(index, c->children());
c->remove_child(index, ErrorStatusHandler());
}, "index"_a)
- .def("__internal_insert", [](Composition* c, int index, Composable* composable) {
+ .def("__internal_insert", [](Composition* c, int index, Composable &composable) {
index = adjusted_vector_index(index, c->children());
- c->insert_child(index, composable, ErrorStatusHandler());
+ c->insert_child(index, &composable, ErrorStatusHandler());
}, "index"_a, "item"_a)
.def("__contains__", &Composition::has_child, "composable"_a)
.def("__len__", [](Composition* c) {which gives us what you want: |
|
I personally always wondered why OTIO uses pointer parameters for these things instead of reference parameters in the python bindings. |
reinecke
added
the
good first issue
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug Report
Incorrect Functionality and General Questions
When
Noneis passed to theappendmethod on a collection, the python interpreter exits with a Segmentation Fault. I first encountered this inTrack, but traced the behavior up the object hierarchy toCollectionand verified inStackas well.TrackStackCompositionSerializableCollectionInterestingly,
SerializableCollectionbehaves differently, but still incorrectly:To Reproduce
Apple clang version 15.0.0 (clang-1500.0.40.1)
Target: arm64-apple-darwin22.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
Expected Behavior
We should throw a
TypeErrorexception as in the following example:Logs
Full crash log from macOS crash report:
The text was updated successfully, but these errors were encountered: