oneTBB icon indicating copy to clipboard operation
oneTBB copied to clipboard

Segfault in tbbmalloc when used in Freedesktop runtime

Open RobotRoss opened this issue 11 months ago • 5 comments

Summary

tbbmalloc.so will segfault when ran from within the Freedesktop runtime

Version

v2022.0.0 , v2021.11.0

Environment

Provide any environmental details that you consider significant for reproducing the issue. The following information is important:

  • Framework 16 w/ GPU module https://frame.work/gb/en/products/laptop16-diy-amd-7040?tab=specs
  • Freedesktop Runtime 24.08 (running on Fedora Silverblue 41)

Observed Behavior

Using Davinci Resolve ( https://github.com/pobthebuilder/resolve-flatpak ) as an example, gcc gives the following backtrace:

Core was generated by `/app/bin/resolve'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2116
2116	    freeList = result->next;
[Current thread is 1 (Thread 0x7f90aa7da000 (LWP 2))]
(gdb) bt full
#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2116
        result = 0xe0000101001f0209
        result = <optimized out>
#1  rml::internal::Block::allocate (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2144
        result = <optimized out>
        result = <optimized out>
#2  rml::internal::internalPoolMalloc (memPool=0x7f90cdc86f40 <rml::internal::defaultMemPool_space>, size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2617
        result = <optimized out>
        bin = 0x7f90a19fbd10
        mallocBlock = 0x7f9031b84000
        tls = <optimized out>
#3  0x00007f90cdc799cb in rml::internal::internalMalloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2665
#4  0x00007f90cdc79e62 in scalable_malloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2943
        ptr = <optimized out>
#5  0x00007f90cda6a6f5 in InternalOperatorNew (sz=48) at ../../src/tbbmalloc/proxy.cpp:337
        res = <optimized out>
#6  operator new (sz=48) at ../../src/tbbmalloc/proxy.cpp:338
#7  0x00007f90afb5d9bd in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::push_back(char) () at /app/bin/../libs/libc++.so.1
#8  0x00000000028b356a in ??? ()
#9  0x00007f90afb684ae in std::__1::basic_streambuf<char, std::__1::char_traits<char> >::xsputn(char const*, long) () at /app/bin/../libs/libc++.so.1
#10 0x00000000028d3107 in ??? ()
#11 0x00000000028d2f4e in ??? ()
#12 0x0000000004f70aa0 in ??? ()
#13 0x0000000004f70317 in ??? ()
#14 0x00007f90a0442140 in <signal handler called> () at /usr/lib/x86_64-linux-gnu/libc.so.6
#15 0x00007f90a04a9ee5 in free () at /usr/lib/x86_64-linux-gnu/libc.so.6
#16 0x00007f90cda6a2d0 in free (object=0xc000403810507) at ../../src/tbbmalloc/proxy.cpp:221
#17 0x000000000a842428 in ??? ()
#18 0x000000000a841b79 in ??? ()
#19 0x000000000a841fae in ??? ()
#20 0x000000000a8409e9 in ??? ()
#21 0x00000000028d46a3 in ??? ()
#22 0x00000000028d352a in ??? ()
#23 0x00000000028b127d in ??? ()
#24 0x0000000002899171 in ??? ()
#25 0x0000000002899a64 in ??? ()
#26 0x000000000289fc4e in ??? ()
#27 0x00000000028a0ccd in ??? ()
#28 0x000000000289ae2e in ??? ()
#29 0x00007f90a042b188 in __libc_start_call_main () at /usr/lib/x86_64-linux-gnu/libc.so.6
#30 0x00007f90a042b24b in __libc_start_main () at /usr/lib/x86_64-linux-gnu/libc.so.6
#31 0x000000000289907b in ??? ()

Expected Behavior

OneTBB should not segfault and application should launch.

RobotRoss avatar Feb 26 '25 23:02 RobotRoss

Hi @RobotRoss,

Thank you for reporting the issue and providing the backtrace.

It appears that the libtbbmalloc_proxy.so that is used comes from v2020.3

#5  0x00007f90cda6a6f5 in InternalOperatorNew (sz=48) at ../../src/tbbmalloc/proxy.cpp:337
#6  operator new (sz=48) at ../../src/tbbmalloc/proxy.cpp:338
...
#16 0x00007f90cda6a2d0 in free (object=0xc000403810507) at ../../src/tbbmalloc/proxy.cpp:221

while the libtbbmalloc.so that it is calling comes from v2022.0.0

#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2116
#1  rml::internal::Block::allocate (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2144
#2  rml::internal::internalPoolMalloc (memPool=0x7f90cdc86f40 <rml::internal::defaultMemPool_space>, size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2617
#3  0x00007f90cdc799cb in rml::internal::internalMalloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2665
#4  0x00007f90cdc79e62 in scalable_malloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2943

Could you please double-check the library configuration that is used in your application?

dnmokhov avatar Feb 27 '25 01:02 dnmokhov

Hi @RobotRoss,

Thank you for reporting the issue and providing the backtrace.

It appears that the libtbbmalloc_proxy.so that is used comes from v2020.3

#5  0x00007f90cda6a6f5 in InternalOperatorNew (sz=48) at ../../src/tbbmalloc/proxy.cpp:337
#6  operator new (sz=48) at ../../src/tbbmalloc/proxy.cpp:338
...
#16 0x00007f90cda6a2d0 in free (object=0xc000403810507) at ../../src/tbbmalloc/proxy.cpp:221

while the libtbbmalloc.so that it is calling comes from v2022.0.0

#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2116
#1  rml::internal::Block::allocate (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2144
#2  rml::internal::internalPoolMalloc (memPool=0x7f90cdc86f40 <rml::internal::defaultMemPool_space>, size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2617
#3  0x00007f90cdc799cb in rml::internal::internalMalloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2665
#4  0x00007f90cdc79e62 in scalable_malloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2943

Could you please double-check the library configuration that is used in your application?

I've ran a build using the 2020.3 version, however the same crash is occurring.


Core was generated by `/app/bin/resolve'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at ../../src/tbbmalloc/frontend.cpp:2094
2094	    freeList = result->next;
[Current thread is 1 (Thread 0x7f8cc23fd000 (LWP 2))]
(gdb) bt full
#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at ../../src/tbbmalloc/frontend.cpp:2094
        result = 0xe0000101001f0209
        result = <optimized out>
#1  rml::internal::Block::allocate (this=<optimized out>) at ../../src/tbbmalloc/frontend.cpp:2122
        result = <optimized out>
        result = <optimized out>
#2  rml::internal::internalPoolMalloc (memPool=0x7f8ce57d2160 <rml::internal::defaultMemPool_space>, size=<optimized out>) at ../../src/tbbmalloc/frontend.cpp:2579
        result = <optimized out>
        bin = 0x7f8cb95fbd10
        mallocBlock = <optimized out>
        tls = <optimized out>
#3  0x00007f8ce57c52c0 in rml::internal::internalMalloc (size=<optimized out>) at ../../src/tbbmalloc/frontend.cpp:2639
#4  0x00007f8ce57c5322 in scalable_malloc (size=<optimized out>) at ../../src/tbbmalloc/frontend.cpp:2925
        ptr = <optimized out>
#5  0x00007f8ce566b6f5 in InternalOperatorNew (sz=48) at ../../src/tbbmalloc/proxy.cpp:337
        res = <optimized out>
#6  operator new (sz=48) at ../../src/tbbmalloc/proxy.cpp:338
#7  0x00007f8cc775d9bd in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::push_back(char) () at /app/bin/../libs/libc++.so.1
#8  0x00000000028b356a in ??? ()
#9  0x00007f8cc77684ae in std::__1::basic_streambuf<char, std::__1::char_traits<char> >::xsputn(char const*, long) () at /app/bin/../libs/libc++.so.1
#10 0x00000000028d3107 in ??? ()
#11 0x00000000028d2f4e in ??? ()
#12 0x0000000004f70aa0 in ??? ()
#13 0x0000000004f70317 in ??? ()
#14 0x00007f8cb8042140 in <signal handler called> () at /usr/lib/x86_64-linux-gnu/libc.so.6
#15 0x00007f8cb80a9ee5 in free () at /usr/lib/x86_64-linux-gnu/libc.so.6
#16 0x00007f8ce566b2d0 in free (object=0xc000403810507) at ../../src/tbbmalloc/proxy.cpp:221
#17 0x000000000a842428 in ??? ()
#18 0x000000000a841b79 in ??? ()
#19 0x000000000a841fae in ??? ()
#20 0x000000000a8409e9 in ??? ()
#21 0x00000000028d46a3 in ??? ()
#22 0x00000000028d352a in ??? ()
#23 0x00000000028b127d in ??? ()
#24 0x0000000002899171 in ??? ()
#25 0x0000000002899a64 in ??? ()
#26 0x000000000289fc4e in ??? ()
#27 0x00000000028a0ccd in ??? ()
#28 0x000000000289ae2e in ??? ()
#29 0x00007f8cb802b188 in __libc_start_call_main () at /usr/lib/x86_64-linux-gnu/libc.so.6
#30 0x00007f8cb802b24b in __libc_start_main () at /usr/lib/x86_64-linux-gnu/libc.so.6
#31 0x000000000289907b in ??? ()

RobotRoss avatar Feb 27 '25 12:02 RobotRoss

Ran another build with the v2022.0.0 version with the correct proxy library in use, again seems to be the same crash.

Core was generated by `/app/bin/resolve'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2116
2116	    freeList = result->next;
[Current thread is 1 (Thread 0x7fcffdffd000 (LWP 2))]
(gdb) bt full
#0  rml::internal::Block::allocateFromFreeList (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2116
        result = 0xe0000101001f0209
        result = <optimized out>
#1  rml::internal::Block::allocate (this=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2144
        result = <optimized out>
        result = <optimized out>
#2  rml::internal::internalPoolMalloc (memPool=0x7fd025fc5f40 <rml::internal::defaultMemPool_space>, size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2617
        result = <optimized out>
        bin = 0x7fcff9dfbd10
        mallocBlock = 0x7fcf7cba8000
        tls = <optimized out>
#3  0x00007fd025fb89cb in rml::internal::internalMalloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2665
#4  0x00007fd025fb8e62 in scalable_malloc (size=<optimized out>) at /run/build/onetbb/src/tbbmalloc/frontend.cpp:2943
        ptr = <optimized out>
#5  0x00007fd025fa0b25 in InternalOperatorNew (sz=48) at /run/build/onetbb/src/tbbmalloc_proxy/proxy.cpp:84
        res = <optimized out>
        res = <optimized out>
        handler = <optimized out>
#6  operator new (sz=48) at /run/build/onetbb/src/tbbmalloc_proxy/proxy.cpp:312
#7  0x00007fd007ed79bd in std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::push_back(char) () at /app/bin/../libs/libc++.so.1
#8  0x00000000028b356a in ??? ()
#9  0x00007fd007ee24ae in std::__1::basic_streambuf<char, std::__1::char_traits<char> >::xsputn(char const*, long) () at /app/bin/../libs/libc++.so.1
#10 0x00000000028d3107 in ??? ()
#11 0x00000000028d2f4e in ??? ()
#12 0x0000000004f70aa0 in ??? ()
#13 0x0000000004f70317 in ??? ()
#14 0x00007fcff8842140 in <signal handler called> () at /usr/lib/x86_64-linux-gnu/libc.so.6
#15 0x00007fcff88a9ee5 in free () at /usr/lib/x86_64-linux-gnu/libc.so.6
#16 0x00007fd025fa063a in free (object=0xc000403810507) at /run/build/onetbb/src/tbbmalloc_proxy/proxy.cpp:200
#17 0x000000000a842428 in ??? ()
#18 0x000000000a841b79 in ??? ()
#19 0x000000000a841fae in ??? ()
#20 0x000000000a8409e9 in ??? ()
#21 0x00000000028d46a3 in ??? ()
#22 0x00000000028d352a in ??? ()
#23 0x00000000028b127d in ??? ()
#24 0x0000000002899171 in ??? ()
#25 0x0000000002899a64 in ??? ()
#26 0x000000000289fc4e in ??? ()
#27 0x00000000028a0ccd in ??? ()
#28 0x000000000289ae2e in ??? ()
#29 0x00007fcff882b188 in __libc_start_call_main () at /usr/lib/x86_64-linux-gnu/libc.so.6
#30 0x00007fcff882b24b in __libc_start_main () at /usr/lib/x86_64-linux-gnu/libc.so.6
#31 0x000000000289907b in ??? ()

RobotRoss avatar Feb 27 '25 12:02 RobotRoss

@lplewa, could you please take a look this tbbmalloc/tbbmalloc_proxy crash?

dnmokhov avatar Feb 27 '25 19:02 dnmokhov

This crash is still present in Fedora 42

RobotRoss avatar May 06 '25 12:05 RobotRoss