You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have an application A consumed library B two years ago, which introduced USD build C dylibs dependence, this module name is libusd_ms.dylib.
Currently, we also used USD 3p as library D in application A, we build it from source codes and renamed the module name to libusd_msx.dylib.
By renaming module we can avoid compile issues and running issue if USD version is mostly compatible. But currently we upgraded USD D to 23.11, it's not compatible with library B's USD C version 22.xx. So it leads to a crash when startup application A.
The root causes is USD wrote many initial/destroy functions address in __DATA, pxrctor/pxrdtor sections. USD build C would be loaded first in our case, then get a function lists via iterating all sections named 'pxrctor' from all loaded modules( via function _dyld_register_func_for_add_image), and then call each of them. In one word, intialized. After that, while loading USD build D, the initialization process would also get a function lists in the same way, and theh lists would also contains the functions lists collected from USD build C. Again, all functions would be called, including those from USD build C. That means those functions from USD build C would be called twice. And it leads to crash in our case.
The related codes are in /pxr/base/arch/attributes.h, /pxr/base/arch/attributes.cpp.
In order to fix this issue, we renamed this two __DATA names if allow USD C and USD D coexist temporarily. We also created a internal fix to allow user to specify a suffix to the section name via build-args .
Steps to Reproduce
build two different version monolithic USD
build the following code to generate an executable, with command clang++ -o load -O2 -g a.cpp -std=c++17 -ldl
#include <dlfcn.h>
#include <iostream>
#include <vector>
int main(int argc, char** argv){
std::vector<void*> handles;
for (int i = 1; i < argc; ++i){
auto file = argv[i];
std::cout << "dlopen: " << file << "\n";
auto h = dlopen(argv[i], RTLD_NOW|RTLD_GLOBAL);
if (!h)
std::cout << "Error: " << dlerror();
handles.push_back(h);
}
for(auto h : handles)
dlclose(h);
}
Description of Issue
We have an application A consumed library B two years ago, which introduced USD build C dylibs dependence, this module name is libusd_ms.dylib.
Currently, we also used USD 3p as library D in application A, we build it from source codes and renamed the module name to libusd_msx.dylib.
By renaming module we can avoid compile issues and running issue if USD version is mostly compatible. But currently we upgraded USD D to 23.11, it's not compatible with library B's USD C version 22.xx. So it leads to a crash when startup application A.
The root causes is USD wrote many initial/destroy functions address in __DATA, pxrctor/pxrdtor sections. USD build C would be loaded first in our case, then get a function lists via iterating all sections named 'pxrctor' from all loaded modules( via function _dyld_register_func_for_add_image), and then call each of them. In one word, intialized. After that, while loading USD build D, the initialization process would also get a function lists in the same way, and theh lists would also contains the functions lists collected from USD build C. Again, all functions would be called, including those from USD build C. That means those functions from USD build C would be called twice. And it leads to crash in our case.
The related codes are in /pxr/base/arch/attributes.h, /pxr/base/arch/attributes.cpp.
In order to fix this issue, we renamed this two __DATA names if allow USD C and USD D coexist temporarily. We also created a internal fix to allow user to specify a suffix to the section name via build-args .
Steps to Reproduce
clang++ -o load -O2 -g a.cpp -std=c++17 -ldl
System Information (OS, Hardware)
OS: MacOS 13.3.1
Xcode: 14.3.1 (14E300c)
Hardware: Apple M1 Pro 2021, 32 GB Memory
Package Versions
23.11, 22.xx
Build Flags
python3 build_scripts/build_usd.py --no-python --no-imaging --build-monolithic --build-variant debug
The text was updated successfully, but these errors were encountered: