SdfPath errors in Visual Studio debug build Windows 10

I’m at a bit of a loss here on why this is happening.

When I build an app with Visual Studio in Cmake debug mode I get SdfPath parsing errors with ANY path ( legal or not ) and Stages do not open. When I build in release mode everything works exactly as I would expect, paths can be created, stages opened, etc.

USD is 25.11 built from source. I followed all the versions in the version.md file so VS-17.14 and Cmake-3.26.4, but with Python-3.13

I checked with a dependency tool but both exe are linked to the same libraries except for some std libs.

This is what I get with a debug build that simply creates a stage in memory and then a prim :

Warning: in SdfPath at line 129 of H:\src\OpenUSD\pxr\usd\sdf\path.cpp -- Ill-formed SdfPath <`☺=█¡☻>: :1:1: parse error matching struct pxrInternal_v0_25_11__pxrReserved__::Sdf_PathParser::Path
Coding Error: in _IsValidPathForCreatingPrim at line 3715 of H:\src\OpenUSD\pxr\usd\usd\stage.cpp -- Path must be an absolute path: <>
Path :
H:\Documents\GIT\UsdTest\out\build\x64-debug\UsdTest.exe (process 5236) exited with code -1 (0xffffffff).

And this is in release mode :

Path : /rootPrim
Is Prim Valid : 1

I’ve done lots of Linux C++ USD development without issue, but this is my first USD app on Windows with Visual Studio.

The code :

// UsdTest.cpp : Defines the entry point for the application.
//

#include "UsdTest.h"

#include <pxr/usd/usd/stage.h>
#include <pxr/usd/usd/prim.h>
#include <pxr/usd/sdf/path.h>
#include <pxr/base/tf/token.h>

#include <string>

using namespace std;

int main()
{
	PXR_NS::UsdStageRefPtr test_stage = PXR_NS::UsdStage::CreateInMemory();
	std::string path = std::string("/rootPrim");
	PXR_NS::SdfPath prim_path = PXR_NS::SdfPath(path);
	PXR_NS::TfToken prim_type = PXR_NS::TfToken(std::string("Sphere"));
	PXR_NS::UsdPrim test_prim = test_stage->DefinePrim(prim_path, prim_type);

	cout << "Path : " << prim_path.GetAsString().c_str() << endl;
	cout << "Is Prim Valid : " << std::to_string(test_prim.IsValid()).c_str() << endl;
	return 0;
}

The cmake :

# CMakeList.txt : CMake project for UsdTest, include source and define
# project specific logic here.
#
cmake_minimum_required (VERSION 3.8)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

project ("UsdTest")

find_package(OpenGL REQUIRED)
find_package(pxr REQUIRED)

set(Python_ADDITIONAL_VERSIONS 3.13)
find_package(PythonLibs 3.13 REQUIRED)

include_directories(
    ${OPENGL_INCLUDE_DIR}
    ${PXR_INCLUDE_DIRS}
    ${PYTHON_INCLUDE_PATH}
)

# Add source to this project's executable.
add_executable (UsdTest "UsdTest.cpp" "UsdTest.h")

target_compile_definitions(UsdTest PRIVATE NOMINMAX)

if (CMAKE_VERSION VERSION_GREATER 3.12)
  set_property(TARGET UsdTest PROPERTY CXX_STANDARD 20)
endif()

target_link_libraries(UsdTest
    PUBLIC
        ${PYTHON_LIBRARY}
        ${OPENGL_gl_LIBRARY}
        ${PXR_LIBRARIES}
)

This is the exception thrown :

Exception thrown at 0x00007FFAAA325369 in UsdTest.exe: Microsoft C++ exception: PXR_INTERNAL_NS_pegtl::parse_error at memory location 0x0000005D59EFF668.
Exception thrown at 0x00007FF99F931691 (ucrtbased.dll) in UsdTest.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

Generally speaking on Windows, you only want to link debug executables against debug libraries and release executables against release libraries. Sounds like here you are linking a debug executable against a release USD library.

There are a number of ways in which this can go wrong, and so a number of different possible solutions… Ideally you’d have a debug USD library to link against. Failing that, you might get away with just changing your executable’s project settings to link against the release MSVC runtime libraries (so your code and the USD code are at least using the same code for core functions like new/delete). If that doesn’t work, you might get into the realm of having to carefully define and undefine _DEBUG or other common macros used to fork code based on the debug/release mode.

Hi Mark,

Thanks for that info.

I tried building USD from source again using the debug build mode in the py file. I then swapped out all my env variables to the new location, and confirmed I was picking up the libraries in the new debug build using a dependency tool.

The result however was the same, and debug mode in Visual Studio resulted in malformed paths.

I will try some other things and make sure that it was actually built in debug mode.