Skip to content

TClassEdit name normalisation fails for unordered_map, leading to a crash in df104_CSVDataSource #18654

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
1 task
hageboeck opened this issue May 8, 2025 · 0 comments · May be fixed by #18625
Open
1 task

Comments

@hageboeck
Copy link
Member

hageboeck commented May 8, 2025

Check duplicate issues.

  • Checked for duplicates

Description

The Python version of df104_CSV frequently crashes on Ubuntu when Cppyy queries types for unordered_map<string,char>. Although a TClass for this might exist, a query for

std::unordered_map<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, char, std::hash<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::equal_to<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >, std::allocator<std::pair<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const, char> > >

might not normalise to the same class, so another TClass instance is created. During its creation, it deletes the instance for unordered_map<string,char>, leading to a dangling pointer and a use-after-free crash.

Reproducer

   auto first = TClass::GetClass("unordered_map<string,char>", true, true);
   std::unordered_map<std::string, char> map;
   auto second = first->GetActualClass(&map);
   EXPECT_EQ(first, second);

ROOT version

Master and v6.36

Installation method

Source

Operating system

All, but the crash manifests on Ubuntu

Additional context

No response

@hageboeck hageboeck added the bug label May 8, 2025
@hageboeck hageboeck self-assigned this May 8, 2025
hageboeck added a commit to hageboeck/root that referenced this issue May 9, 2025
When looking up a TClass via name compared to via typeid, the lookup
returned a name without default template arguments in the former, and
with default arguments in the latter case.
This lead to a situation where
  tclass->GetActualClass(std::map<x,y>*)
could delete itself while performing the lookup, since a new instance
was created that replaced the existing instance.

To make type name normalisation stable, the following was changed in
TClassEdit:
- Improve the handling of a trailing const in the allocator definition.
- Make default allocator check more robust w.r.t. spaces in type
  definition.
- Improve detection of std::basic_string, std::__cxx11::basic_string and
  similar types with/without const and std::
- Add another stripping step to remove default template arguments of STL
  containers when they were looked up in the interpreter.

Fix root-project#18654.
hageboeck added a commit to hageboeck/root that referenced this issue May 9, 2025
When looking up a TClass via name compared to via typeid, the lookup
returned a name without default template arguments in the former, and
with default arguments in the latter case.
This lead to a situation where
  tclass->GetActualClass(std::map<x,y>*)
could delete itself while performing the lookup, since a new instance
was created that replaced the existing instance.

To make type name normalisation stable, the following was changed in
TClassEdit:
- Improve the handling of a trailing const in the allocator definition.
- Make default allocator check more robust w.r.t. spaces in type
  definition.
- Improve detection of std::basic_string, std::__cxx11::basic_string and
  similar types with/without const and std::
- Add another stripping step to remove default template arguments of STL
  containers when they were looked up in the interpreter.

Fix root-project#18654.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Status: No status
1 participant