SIGSEGV on launched application when running with RenderDocCmd on arm64 build

[andrew673]

Description

Hi! I'm trying to integrate renderdoccmd into a Linux image necessary for an i.MX NXP board.
My main objective on this is to capture frames on Vulkan applications, but at this point I only trying to do this only on GLES samples, for validation puposes.

The renderdoccmd build is sourced on a custom aarch64 SDK and has the following params:

      -DCMAKE_BUILD_TYPE=Debug \
      -DENABLE_PYRENDERDOC=OFF \
      -DENABLE_QRENDERDOC=OFF \
      -DENABLE_RENDERDOCCMD=ON \
      -DENABLE_XLIB=ON \
      -DENABLE_XCB=ON \
      -DENABLE_GL=ON \
      -DENABLE_VULKAN=ON \
      -DUSE_INTERCEPTOR_LIB=OFF \ #I tried with this ON and OFF having the same bug
      -Bbuild -H.	\
      -DCMAKE_TOOLCHAIN_FILE=/opt/fsl-imx-internal-xwayland/4.19-thud/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake \

At this point, everytime I run renderdocmd with to capture option on a GLES sample, the console tells that the application has lauched, but in fact, it was terminated with SIGSEGV, as I have seen this from dmesg, and even modified the code a bit here to see what signal did terminate the graphical application launched by RenderDoc (here is some example with dmesg):

[19407.131965] audit: type=1701 audit(1564581738.063:108): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=9837 comm="glmark2-es2-way" exe="/usr/bin/glmark2-es2-wayland" sig=11 res=1

I have also printed the environment from the code, before this execve() call to see if anything is out of place:

    Launching '/opt/imx-gpu-sdk/GLES3/Bloom/Bloom_Wayland'
    DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/0/bus
    DISPLAY=:0
    HOME=/home/root
    INVOCATION_ID=704916A2850A42C6BDC1913F19623452
    JOURNAL_STREAM=8:13717
    LD_LIBRARY_PATH=/home/root:/home/root/../lib:/home/root
    LD_PRELOAD=librenderdoc.so
    LOGNAME=root
    MAIL=/var/spool/mail/root
    PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
    PS1=\u@\h:\w\$ 
    PWD=/home/root
    QT_QPA_PLATFORM=wayland
    RENDERDOC_CAPFILE=
    RENDERDOC_CAPOPTS=ababaaaaaaaicaiaaaaaaaaaaaaaaaaaabaaaaaa
    RENDERDOC_DEBUG_LOG_FILE=/tmp/RenderDoc/RenderDoc_2019.08.01_07.52.10.log
    SHELL=/bin/sh
    SHLVL=1
    TERM=xterm
    TZ=UTC
    USER=root
    XDG_RUNTIME_DIR=/run/user/0
    XDG_SESSION_ID=c2
    _=./renderdoccmd
    Launched as ID 38921

But it doesn't seem like the new process is launched incorrectly.
Here is the output of the log file:

    RDOC 010592: [07:52:10]             core.cpp( 352) - Log     - RenderDoc v1.5 Linux 64-bit Development (bb3b94b0924a828df810f206277fcc2258cd7ce4) loaded in replay application
    RDOC 010593: [07:52:10]             core.cpp( 352) - Log     - RenderDoc v1.5 Linux 64-bit Development (bb3b94b0924a828df810f206277fcc2258cd7ce4) capturing application
    RDOC 010593: [07:52:10]   posix_libentry.cpp(  56) - Log     - Using delay for debugger 0
    RDOC 010593: [07:52:10]   posix_libentry.cpp(  69) - Log     - Loading into /opt/imx-gpu-sdk/GLES3/Bloom/Bloom_Wayland
    RDOC 010593: [07:52:10]         gl_hooks.cpp( 245) - Log     - Registering OpenGL hooks
    RDOC 010593: [07:52:10]        glx_hooks.cpp( 676) - Log     - Registering GLX hooks
    RDOC 010593: [07:52:10]        egl_hooks.cpp( 778) - Log     - Registering EGL hooks
    RDOC 010593: [07:52:10]         vk_layer.cpp(  53) - Log     - Registering Vulkan hooks
    RDOC 010593: [07:52:10]        egl_hooks.cpp( 719) - Debug   - EGL library hooked
    RDOC 010593: [07:52:10]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libEGL.so
    RDOC 010593: [07:52:10]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGLESv1_CM.so
    RDOC 010593: [07:52:10]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGLESv2.so
    RDOC 010593: [07:52:10]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGLESv2.so
    RDOC 010593: [07:52:10]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGL.so
    RDOC 010593: [07:52:10]        glx_hooks.cpp( 628) - Debug   - GLX library hooked

Another idea that came in my mine was the fact that actual problem could be related with the display protocol used, since the OS uses Wayland with xwayland support, instead of Xorg. So I have read some issues and found this disscusion. From what I can understand, the Wayland support has not been yet implemented. I have tried to run the contributor's branch with preliminary commits on this matter, but the result was the same. I cannot assert yet the fact that this may cause the problem since my experience on this subject is very limited, so maybe I can get some help from here.

If there is any other kind of additional information, let me know.

Looking forward for any reply, thank you in advance!

Repro steps

• Run this script:

  #!/bin/bash
  
  source /opt/fsl-imx-internal-xwayland/4.19-thud/environment-setup-aarch64-poky-linux
  cd build
  
  cmake \
      -DCMAKE_BUILD_TYPE=Debug \
      -DENABLE_PYRENDERDOC=OFF \
      -DENABLE_QRENDERDOC=OFF \
      -DENABLE_RENDERDOCCMD=ON \
      -DENABLE_XLIB=ON \
      -DENABLE_XCB=ON \
      -DENABLE_GL=ON \
      -DENABLE_VULKAN=ON \
      -DUSE_INTERCEPTOR_LIB=OFF \
      -Bbuild -H.	\
      -DCMAKE_TOOLCHAIN_FILE=/opt/fsl-imx-internal-xwayland/4.19-thud/sysroots/x86_64-pokysdk-linux/usr/share/cmake/OEToolchainConfig.cmake \
  ..
  
  set -e
  make
  

Assuming the fact that you have the YoctoSDK (At this point this can be only tested by me, I'm only providing as much additional info as possible).

• Upload the resulted build directory to the board.

• On the board from the build/bin/ directory, run ./renderdoccmd capture <path_to_opengles_sample_exec>. Th consule outputs that renderdoc has launched the application (example):

    Launching '/opt/imx-gpu-sdk/GLES3/Bloom/Bloom_Wayland'
    Launched as ID 38921
  

Environment

• RenderDoc build: v1.5, last updated on 07-15-2019
• Operating System: Linux
• Release Name: NXP i.MX Release Distro, version 4.19-thud
• API: OpenGL ES, Vulkan

[baldurk]

I'm unclear, is this an android device you're using or is it linux? The log seems to indicate that it's linux but you're running on an ARM CPU and specifying USE_INTERCEPTOR_LIB at build time - which I would very strongly recommend you enable if this is android.

You'd need to give me more information about what exactly is crashing. Knowing that the application hits a SIGSEGV is not useful in itself because it doesn't tell us anything about what is going wrong.

If I can't reproduce the problem myself I'd need to know at least the callstack where it fails so I can make educated guesses. If this is android then this should be available in the adb logcat as the system dumps out the crash information - if everything is working correctly RenderDoc should pull the logcat into its own log which you can view in Help -> View Diagnostic Log.

[andrew673]

So this is just Linux I'm running on the board with a proprietary distribution (release name can be seen above). I have builded RenderDoc almost all the time with USE_INTERCEPTOR_LIB=ON, but the result was the same (at that point I was trying to change some flags to maybe get another result). I included this flag in my script after seeing some discussion on which the problem seemed to be the same. Usually, I change the flags with ccmake if there is the case.

Below there is a valgrind log for command valgrind --trace-children=yes ./renderdoccmd capture /usr/bin/glmark2-es-wayland. Hope this helps a bit. I will try to further look into the callstacks in a better degree than just seeing how an application is launched.

	Launching '/usr/bin/glmark2-es2-wayland'
	==10871== Conditional jump or move depends on uninitialised value(s)
	==10871==    at 0x484B808: strlen (vg_replace_strmem.c:460)
	==10871==    by 0x5268707: rdcstr (rdcstr.h:242)
	==10871==    by 0x5268707: EnvironmentModification (control_types.h:570)
	==10871==    by 0x5268707: Process::LaunchAndInjectIntoProcess(char const*, char const*, char const*, rdcarray<EnvironmentModification> const&, char const*, CaptureOptions const&, bool) (posix_process.cpp:761)
	==10871==    by 0x415C3F: CaptureCommand::Execute(cmdline::parser&, CaptureOptions const&) (renderdoccmd.cpp:369)
	==10871==    by 0x40EA67: renderdoccmd(GlobalEnvironment const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (renderdoccmd.cpp:1325)
	==10871==    by 0x40FC6B: renderdoccmd(GlobalEnvironment const&, int, char**) (renderdoccmd.cpp:1344)
	==10871==    by 0x404C33: main (renderdoccmd_linux.cpp:560)
	==10871== 
	==10871== Conditional jump or move depends on uninitialised value(s)
	==10871==    at 0x484B808: strlen (vg_replace_strmem.c:460)
	==10871==    by 0x5268F3B: length (char_traits.h:320)
	==10871==    by 0x5268F3B: assign (basic_string.h:1430)
	==10871==    by 0x5268F3B: operator= (basic_string.h:704)
	==10871==    by 0x5268F3B: Process::LaunchAndInjectIntoProcess(char const*, char const*, char const*, rdcarray<EnvironmentModification> const&, char const*, CaptureOptions const&, bool) (posix_process.cpp:773)
	==10871==    by 0x415C3F: CaptureCommand::Execute(cmdline::parser&, CaptureOptions const&) (renderdoccmd.cpp:369)
	==10871==    by 0x40EA67: renderdoccmd(GlobalEnvironment const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (renderdoccmd.cpp:1325)
	==10871==    by 0x40FC6B: renderdoccmd(GlobalEnvironment const&, int, char**) (renderdoccmd.cpp:1344)
	==10871==    by 0x404C33: main (renderdoccmd_linux.cpp:560)
	==10871== 
	==10872== Syscall param execve(envp[i]) points to uninitialised byte(s)
	==10872==    at 0x5A9F758: execve (syscall-template.S:78)
	==10872==    by 0x5266A5B: RunProcess(char const*, char const*, char const*, char**, int*, int*) (posix_process.cpp:593)
	==10872==    by 0x5268FB7: Process::LaunchAndInjectIntoProcess(char const*, char const*, char const*, rdcarray<EnvironmentModification> const&, char const*, CaptureOptions const&, bool) (posix_process.cpp:817)
	==10872==    by 0x415C3F: CaptureCommand::Execute(cmdline::parser&, CaptureOptions const&) (renderdoccmd.cpp:369)
	==10872==    by 0x40EA67: renderdoccmd(GlobalEnvironment const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (renderdoccmd.cpp:1325)
	==10872==    by 0x40FC6B: renderdoccmd(GlobalEnvironment const&, int, char**) (renderdoccmd.cpp:1344)
	==10872==    by 0x404C33: main (renderdoccmd_linux.cpp:560)
	==10872==  Address 0x73db95c is 28 bytes inside a block of size 59 alloc'd
	==10872==    at 0x4848F54: operator new[](unsigned long) (vg_replace_malloc.c:423)
	==10872==    by 0x5268AB7: Process::LaunchAndInjectIntoProcess(char const*, char const*, char const*, rdcarray<EnvironmentModification> const&, char const*, CaptureOptions const&, bool) (posix_process.cpp:811)
	==10872==    by 0x415C3F: CaptureCommand::Execute(cmdline::parser&, CaptureOptions const&) (renderdoccmd.cpp:369)
	==10872==    by 0x40EA67: renderdoccmd(GlobalEnvironment const&, std::vector<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::allocator<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > >&) (renderdoccmd.cpp:1325)
	==10872==    by 0x40FC6B: renderdoccmd(GlobalEnvironment const&, int, char**) (renderdoccmd.cpp:1344)
	==10872==    by 0x404C33: main (renderdoccmd_linux.cpp:560)
	==10872== 
	Launched as ID 38921
	==10872== Memcheck, a memory error detector
	==10872== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
	==10872== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
	==10872== Command: /usr/bin/glmark2-es2-wayland
	==10872== 
	==10871== 
	==10871== HEAP SUMMARY:
	==10871==     in use at exit: 17,829 bytes in 182 blocks
	==10871==   total heap usage: 2,122 allocs, 1,940 frees, 38,407,058 bytes allocated
	==10871== 
	==10871== LEAK SUMMARY:
	==10871==    definitely lost: 0 bytes in 0 blocks
	==10871==    indirectly lost: 0 bytes in 0 blocks
	==10871==      possibly lost: 0 bytes in 0 blocks
	==10871==    still reachable: 17,829 bytes in 182 blocks
	==10871==         suppressed: 0 bytes in 0 blocks
	==10871== Rerun with --leak-check=full to see details of leaked memory
	==10871== 
	==10871== For counts of detected and suppressed errors, rerun with: -v
	==10871== Use --track-origins=yes to see where uninitialised values come from
	==10871== ERROR SUMMARY: 12 errors from 2 contexts (suppressed: 0 from 0)
	root@imx8qxpmek:~#
	==10872== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
	==10872== 
	==10872== Process terminating with default action of signal 11 (SIGSEGV)
	==10872==  Access not within mapped region at address 0x1FFE801FF0
	==10872== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
	==10872==    at 0x4BCBDE0: glXGetProcAddress_renderdoc_hooked (glx_hooks.cpp:419)
	==10872==  If you believe this happened as a result of a stack
	==10872==  overflow in your program's main thread (unlikely but
	==10872==  possible), you can try to increase the size of the
	==10872==  main thread stack using the --main-stacksize= flag.
	==10872==  The main thread stack size used in this run was 8388608.
	==10872== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
	==10872== 
	==10872== Process terminating with default action of signal 11 (SIGSEGV)
	==10872==  Access not within mapped region at address 0x1FFE801F90
	==10872== Stack overflow in thread #1: can't grow stack to 0x1ffe801000
	==10872==    at 0x483262C: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-arm64-linux.so)
	==10872==  If you believe this happened as a result of a stack
	==10872==  overflow in your program's main thread (unlikely but
	==10872==  possible), you can try to increase the size of the
	==10872==  main thread stack using the --main-stacksize= flag.
	==10872==  The main thread stack size used in this run was 8388608.
	==10872== 
	==10872== HEAP SUMMARY:
	==10872==     in use at exit: 36,279,753 bytes in 2,469 blocks
	==10872==   total heap usage: 9,604 allocs, 7,135 frees, 36,831,327 bytes allocated
	==10872== 
	==10872== LEAK SUMMARY:
	==10872==    definitely lost: 0 bytes in 0 blocks
	==10872==    indirectly lost: 0 bytes in 0 blocks
	==10872==      possibly lost: 2,480 bytes in 3 blocks
	==10872==    still reachable: 36,277,273 bytes in 2,466 blocks
	==10872==         suppressed: 0 bytes in 0 blocks
	==10872== Rerun with --leak-check=full to see details of leaked memory
	==10872== 
	==10872== For counts of detected and suppressed errors, rerun with: -v
	==10872== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
	root@imx8qxpmek:~# [95630.453597] audit: type=1701 audit(1564657962.207:146): auid=4294967295 uid=0 gid=0 ses=4294967295 pid=10872 comm="memcheck-arm64-" exe="/usr/lib/valgrind/memcheck-arm64-linux" sig=11 res=1

I also tried to run renderdoccmd with other sorts of commands such as /bin/ls or /bin/cat, and the processes seem to launch just fine. At this point I'm really short on ideas as to what causes this behaviour, but I will continue debugging the app hoping that I will find something specific.

[baldurk]

If this is linux then you shouldn't be touching USE_INTERCEPTOR_LIB at all. It's an android only option and does absolutely nothing on linux.

The valgrind log provides a partial picture of what's wrong. It says directly in what you pasted that there's a stack overflow in glXGetProcAddress. It's most likely calling itself recursively infinitely, rather than being just the leaf function call on an unrelated overflow, so that's where I'd investigate.

This suggests that something went wrong when processing the GLX hooks. Normally the onward function pointer is fetched via calling dlsym for the GL library when loaded. I'd suggest debugging into the hooking code in linux_hook.cpp to see what exactly that's getting and then step through the code in a debugger when glXGetProcAddress is first called to see trace where execution gets stuck in a loop.

The possibilities I can see are either that renderdoc's code is getting its own function pointer instead of the real function pointer, which seems unlikely but is still possible. Or that somehow libGL.so is misbehaving and calling back into RenderDoc's hook - so the infinite recursion happens with a ping-pong or some small cycle of calls and not just a direct recursive call. Since this seems specific to your setup my guess would be on the latter.

Unfortunately I do not support ARM linux builds so unless you can repro this on a supported platform I can't help fix this. If you have questions you can ask them here or email me and I can explain what should be happening to help you debug it yourself, but I can't help with bugs on unsupported platforms and I definitely can't help with bugs that only appear on a proprietary linux distribution and hardware.

[andrew673]

Just to clarify some things: glmark2-es2-wayland is a GLES application and it should not register glX hooks in the first place (I suppose), but as you can see below in the following log:

RDOC 005533: [07:16:29]             core.cpp( 352) - Log     - RenderDoc v1.5 Linux 64-bit Development (bb3b94b0924a828df810f206277fcc2258cd7ce4) loaded in replay application
RDOC 005534: [07:16:30]             core.cpp( 352) - Log     - RenderDoc v1.5 Linux 64-bit Development (bb3b94b0924a828df810f206277fcc2258cd7ce4) capturing application
RDOC 005534: [07:16:30]   posix_libentry.cpp(  56) - Log     - Using delay for debugger 0
RDOC 005534: [07:16:30]   posix_libentry.cpp(  69) - Log     - Loading into /usr/bin/glmark2-es2-wayland
RDOC 005534: [07:16:30]         gl_hooks.cpp( 245) - Log     - Registering OpenGL hooks
RDOC 005534: [07:16:30]        glx_hooks.cpp( 676) - Log     - Registering GLX hooks
RDOC 005534: [07:16:30]        egl_hooks.cpp( 778) - Log     - Registering EGL hooks
RDOC 005534: [07:16:30]         vk_layer.cpp(  53) - Log     - Registering Vulkan hooks
RDOC 005534: [07:16:30]        egl_hooks.cpp( 719) - Debug   - EGL library hooked
RDOC 005534: [07:16:30]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libEGL.so
RDOC 005534: [07:16:30]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGLESv1_CM.so
RDOC 005534: [07:16:30]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGLESv2.so
RDOC 005534: [07:16:30]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGLESv2.so
RDOC 005534: [07:16:30]       linux_hook.cpp( 154) - Debug   - Redirecting dlopen to ourselves for libGL.so
RDOC 005534: [07:16:30]        glx_hooks.cpp( 628) - Debug   - GLX library hooked

This app registers not only EGL (as it should), but also GLX and Vulkan. Do you have any idea why is this happening? And also, can you provide me some information about the hook selection process in the code? (Like where does renderdoc decide to register EGL hooks for a GLES app)

[baldurk]

You have a mistaken assumption about what the log messages mean. It is impossible to know in advance what API or APIs an application will use, so RenderDoc registers hooks for all supported APIs at startup.

This only means that APIs which are registered can be hooked, it doesn't mean that there's an expectation that an application will use all of them. Similarly having them registered doesn't preclude the selection of API by the application.

[andrew673]

OK, I understand what you mean. Now correct me if I'm wrong: a GLES only app should not go through code from glx_hooks.cpp such as the function glXGetProcAddress_renderdoc_hooked since it's meant for apps that use OpenGL GLX (I'm asking this so I can understand the selection process of the API used for an application).

[baldurk]

Generally speaking I wouldn't particularly expect it, but there's nothing to stop an application from doing so. There's no rule that the application can't call both EGL and GLX entry points as long as they are valid respectively. E.g. on GL function loaders are common so the application may be populating function pointers via glXGetProcAddress even if it doesn't intend to use them.

This is about your application not RenderDoc, you should check your source code to see which functions you're calling.

[andrew673]

I kind of fixed this bug by disabling the GL support which at run time will try to register GLX hooks, although later I found out that if our EGL driver will try to call on something like GetProcAddress when creating EGLContext for the GLES app, it will actually "ask" renderdoc's wrapper on dlopen (created to register hooks), instead of the system's version for the function addresses which will be invalid. At this point I'm trying to patch the driver regarding this problem.
Now, for Vulkan applications, I runned into this problem:

ERROR: Init failed with exception: The extension is not supported: VK_KHR_wayland_surface
ERROR: demo setup failed with: The extension is not suported: VK_KHR_wayland_surface

While browsing through some other issues I found this comment from you. Does this affirmation still remain valid at this moment?

[baldurk]

Yes due to the LD_PRELOAD hooking on linux if your driver calls back out to a public interface that will cause an infinite loop.

Please see #853 . I'm looking at adding wayland support since others had indicated that it's shipping already on some distros like Fedora. With that said it still seems to be in a really poor/unstable state as I've had a lot of trouble even getting a system working with it, so I may defer the work until wayland is more ready.

[andrew673]

I'm already building this version as we speak, trying my luck here 😄

[andrew673]

You do have in fact an experimental support on Wayland (capture only) on the release version, which made my GLES apps finally launch. But now the problem is that the capture menu doesn't show up. I also tried to remote capture using Qrenderdoc from my local machine, and the behavior is pretty much the same: the application launches, but no capture option is available. Do you have any suggestions for this? If you need any more details, fill me in.

[baldurk]

The wayland support is as you say experimental, not supported, and was only just added recently with barely any testing since I could hardly get wayland to work.

I don't know what you mean by a capture menu, that's not a term I can mentally map to anything within RenderDoc, and I'm unclear what 'no capture option is available' means either.

This issue was closed quite a while ago because your platform is not supported and I can't help with problems on unsupported platforms, nor even with supported platforms unless I have that platform to reproduce on. I said that I would answer specific questions about how the code is intended to behave on supported platforms in case you wanted to implement and/or contribute support for your platform, but what you are asking for is essentially support for your unsupported platform so I'm going to lock this issue.

If you have specific questions about how the code works that I can answer within the context of supported platforms, please feel free to contact me via email or open an issue if you wish. Or if you can reproduce a problem on a supported platform such as 64-bit x86 linux then open an issue with a repro case and I will investigate. But I can't keep answering support questions and helping you debug problems that appear on a specific unsupported platform.