vsg::Object cast<T>() sometimes returns nullptr on macOS Sonoma arm64 Release builds #1575

hearga · 2025-09-02T14:25:52Z

Description

Addressed an issue where vsg::Object::cast() would sometimes return nullptr on macOS Sonoma (Apple Silicon, arm64) in Release builds.
Updated the casting logic to use dynamic_cast<T*>(), matching the approach already used in the previous function " template
ref_ptr readObject(const char* propertyName)"

Type of change

Bug fix (non-breaking change which fixes an issue)

…arm64 Release builds

robertosfield · 2025-09-02T14:47:11Z

We need to get to the bottom of why cast<> is failing, not go around relacing all of it's usage across the VSG.

Is that are particular object type that is failing?

hearga · 2025-09-02T15:36:12Z

I agree... I did, but I couldn't find anything.

The object type is uintArray, here

VulkanSceneGraph/src/vsg/text/Font.cpp

Line 30 in 28b6b81

input.readObject("charmap", charmap);

robertosfield · 2025-09-02T15:47:09Z

Could you have a look at this thread, I believe it touches upon the issue you are seeing:

#899

It looks like an issue with clang generating different type_info results for different libraries in certain circumstances. At the end of the above thread there are suggestions for solutions.

… IDs during casting

hearga · 2025-09-02T20:55:18Z

It works using explicit template instantiation. It resolves the different type_info hash IDs during casting.

- vsg::Array<vsg::DrawIndexedIndirectCommand> - vsg::Array<vsg::VkGeometryInstance> - cast l.size() to uint32_t in assign() to match parameter type and avoid warnings - rename core/Array.cpp to core/ArrayInstantiations.cpp

robertosfield · 2025-09-03T07:38:55Z

Thanks for the changes, I've done a first past review and it feels like a rather heavy handed approach, forcing lots of extra code that we don't need other than for working around a problem with a specific compiler's build settings.

The changes would also need to be rolled out to all the other use of templates such as vsg::Value, Array2D, Array3D and perhaps even use of vsg::Inherit.

Did you test building as dynamic library?

…e hatch when desired; drop explicit instantiations - CMake: * BUILD_SHARED_LIBS=OFF (static, Clang) -> by default define VSG_EXPORTS to export Array<T>; if VSG_USE_DYNAMIC_CAST is requested, define VSG_USE_DYNAMIC_CAST instead to switch cast<T>() to dynamic_cast. - Remove ArrayInstantiations.cpp: explicit template instantiations are no longer needed.

hearga · 2025-09-09T14:28:16Z

Thanks for the review, I’ve reworked this to a minimal fix that targets the actual Clang issue (hidden visibility causing divergent &typeid(Array) across TUs):

Export the class: Array to stabilize typeid.
No explicit instantiations: removed ArrayInstantiations.cpp.
Opt-in escape hatch: VSG_USE_DYNAMIC_CAST switches cast() to dynamic_cast for those who prefer it.

If this approach looks good, we can apply the same small change to Value, Array2D/Array3D, etc., as needed, no project-wide mass changes required.

Shared libs: not tested, sorry, I have limited time to work on this; in shared builds, we already define the import/export macro, so the type info should be default-visible and typeid stable—no additional changes expected.

robertosfield · 2025-11-20T10:19:05Z

src/vsg/CMakeLists.txt

    target_compile_definitions(vsg INTERFACE VSG_SHARED_LIBRARY)
+else()
+    if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
+        if (VSG_USE_DYNAMIC_CAST)


Where in CMake scripts is VSG_USE_DYNAMIC_CAST set & controlled? Is there a missing CMake option for this?

robertosfield · 2025-11-20T10:20:50Z

include/vsg/core/Object.h

 #include <vsg/core/ref_ptr.h>
 #include <vsg/core/type_name.h>

+#ifdef VSG_USE_DYNAMIC_CAST


Why use both VSG_USE_DYNAMIC_CAST and VSG_CAST_DYNAMIC?

FYI the include/vsg/core/Version.h is a CMake generated file that is set up via the src/vsg/core/Version.h.in file using various CMake options to control the settings. Perhaps this approach could avoid this clumsy ifdef?

robertosfield · 2025-11-20T10:21:41Z

include/vsg/core/Array.h

            _size(0)
        {
-            assign(data, offset, stride, l.size());
+            assign(data, offset, stride, static_cast<uint32_t>(l.size()));


I presume this is just a warning fix? If so should be applied independently from any other changes.

robertosfield · 2025-11-20T10:23:35Z

include/vsg/core/Array.h


    template<typename T>
-    class Array : public Data
+    class VSG_DECLSPEC Array : public Data


If Array requires VSG_DECLSPEC then Value, Array2D and Array3D will also require it.

robertosfield · 2025-11-20T10:26:31Z

After a crazy busy period of client work I'm now back catching up with PRs, sorry for taking so long to get back to this.

I've done another code review and added comments into the various changes. I think some of the changes might be sensible to merge separately so if there are ones that aren't directly dependent on the dynamic_cast<> usage then it would be good to get these fixed as separate commits/PRs. I'm happy to do some of this, just point me in the right direction.

move VSG_USE_DYNAMIC_CAST to version.h.in

hearga · 2025-11-24T15:43:31Z

I agree. I’ve removed the warning from this PR and added the suggestions you proposed.

robertosfield · 2025-11-25T17:54:49Z

Changes look good, I have merged them as branch and will now try things out. It's near end of day so I'll probably not attempt to merge with master today:

https://github.com/vsg-dev/VulkanSceneGraph/tree/hearga-fix-cast-arm64

I'm thinking we need a test for this to make sure we are getting the expected results and the performance differences.

robertosfield · 2025-11-25T18:28:16Z

After review the CMake and Version.h.in I have changed to use CMake option and changed the capitalization of the define to be a more direct about what it maps too: 0d7cc5e

robertosfield · 2025-11-26T15:52:22Z

I have created vsgcast test that can test the performance of running vsg::Object::cast<>:

vsg-dev/vsgExamples@c3e758d

This is the output for when I build the VSG, vsgXchange and vsgExamples with VSG_USE_dynamic_cast OFF (default) and ON:

robert@Vorlich:~/dev/VulkanSceneGraph$ vsgcast 
Using typeid() based RTTI vsg::Object::cast<> implementation - faster than using dynamic_cast<>.
Time 938.224ms count = 100100000
Cast and traverse per second 106690930

robert@Vorlich:~/dev/VulkanSceneGraph$ vsgcast 
Using dynamic_cast<> based RTTI vsg::Object::cast<> implementation.
Time 3470.26ms count = 100100000
Cast and traverse per second 28845095

The dynamic_cast<> implementation is 2.8 times slower!

With this testing and the refinements I've made I'm now happy with the branch so have merged with VSG master.

Fix: vsg::Object cast<T>() sometimes returns nullptr on macOS Sonoma …

063bfeb

…arm64 Release builds

Explicit template instantiation resolves the different type_info hash…

0135bfd

… IDs during casting

- Add explicit template instantiations for:

62a47b1

- vsg::Array<vsg::DrawIndexedIndirectCommand> - vsg::Array<vsg::VkGeometryInstance> - cast l.size() to uint32_t in assign() to match parameter type and avoid warnings - rename core/Array.cpp to core/ArrayInstantiations.cpp

retrigger checks

b7d2c30

robertosfield reviewed Nov 20, 2025

View reviewed changes

Apply VSG_DECLSPEC to Array2D, Array3D, and Value;

4bd274f

move VSG_USE_DYNAMIC_CAST to version.h.in

robertosfield merged commit 1581af7 into vsg-dev:master Nov 26, 2025
8 checks passed

vsg::Object cast<T>() sometimes returns nullptr on macOS Sonoma arm64 Release builds #1575

vsg::Object cast<T>() sometimes returns nullptr on macOS Sonoma arm64 Release builds #1575

Uh oh!

Conversation

hearga commented Sep 2, 2025

Description

Type of change

Uh oh!

robertosfield commented Sep 2, 2025

Uh oh!

hearga commented Sep 2, 2025

Uh oh!

robertosfield commented Sep 2, 2025

Uh oh!

hearga commented Sep 2, 2025

Uh oh!

robertosfield commented Sep 3, 2025

Uh oh!

hearga commented Sep 9, 2025

Uh oh!

robertosfield Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

robertosfield Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

robertosfield Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

robertosfield Nov 20, 2025

Choose a reason for hiding this comment

Uh oh!

robertosfield commented Nov 20, 2025

Uh oh!

hearga commented Nov 24, 2025

Uh oh!

robertosfield commented Nov 25, 2025

Uh oh!

robertosfield commented Nov 25, 2025

Uh oh!

Uh oh!

robertosfield commented Nov 26, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants