ftrace does not work because mobj_get_cattr function fails

[zhanlej]

I found that the performance is very poor when using the RSA interface of OPTEE CORE, so I want to locate where the performance bottleneck is. I tried to open the ftrace function of OPTEE by referring to the ftrace documentation, but I encountered some problems, which are described as follows:

I am using a chip from TI, and TI provides ti-optee-os modified based on optee_os. Although there are some differences between the two code bases, the core logic of OPTEE should not be modified, because the bl32 compiled by me using github's optee_os can also run normally.

Hardware version: TI TDA4
OPTEE OS version: ti-optee-os tag ti2020.00 (similar to version 3.8.0)
OPTEE CLIENT version: ti-optee-client tag ti2020.00
OPTEE OS compilation parameters:

O=out/arm 
CFG_ARM64_core=y 
CROSS_COMPILE="/usr/bin/ccache /opt/gw-gcc/gcc/bin/aarch64-none-linux-gnu-" 
CROSS_COMPILE_core="/usr/bin/ccache /opt/gw-gcc/gcc/bin/aarch64-none-linux-gnu-" 
CROSS_COMPILE_ta_arm64="/usr/bin/ccache /opt/gw-gcc/gcc/bin/aarch64-none-linux-gnu-" 
CROSS_COMPILE_ta_arm32="/usr/bin/ccache /home/zlj/WorkSpace/icode/baidu/adu/tee_security/build/../toolchains/aarch32/bin/arm-linux-gnueabihf-" 
CFG_TEE_CORE_LOG_LEVEL=3 
CFG_TEE_TA_LOG_LEVEL=1 
DEBUG=1 
ta-targets=ta_arm64 
CFG_TEE_BENCHMARK=n 
CFG_TEE_TA_MALLOC_DEBUG=y 
CFG_FTRACE_SUPPORT=y 
CFG_ULIBS_MCOUNT=y 
CFG_TA_MCOUNT=y 
CFG_FTRACE_BUF_SIZE=100000  
PLATFORM=k3-j721e 
CFG_ARM64_core=y 

After compiling and burning to the device using the above compilation parameters, I did not find any ftrace related files in the /tmp/ directory of REE.

At first I thought it was the problem of ti-optee-client, but by looking at the code I found that CFG_FTRACE_SUPPORT ?= y in config.mk is enabled by default.

So I try to add some printing in ti-optee-os to find the problem, the modification record can be viewed: zhanlej/ti-optee-os@6a455cb

The final location to the log is as follows:

D/TC:? 0 tee_ta_init_pseudo_ta_session:284 Lookup pseudo TA 8ffff200-2450-11e4-abe2-0002a5d5c51b
E/TC:? 0 set_ta_ctx_ops:643 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_phys_get_cattr:78 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_phys_get_cattr:78 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
D/TC:? 0 load_ldelf:725 ldelf load address 0x40006000
D/LD:  ldelf:134 Loading TA 8ffff200-2450-11e4-abe2-0002a5d5c51b
D/TC:? 0 tee_ta_init_pseudo_ta_session:284 Lookup pseudo TA 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
D/TC:? 0 tee_ta_init_pseudo_ta_session:297 Open system.pta
D/TC:? 0 tee_ta_init_pseudo_ta_session:311 system.pta : 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
D/TC:? 0 system_open_ta_binary:249 Lookup user TA ELF 8ffff200-2450-11e4-abe2-0002a5d5c51b (Secure Storage TA)
D/TC:? 0 system_open_ta_binary:253 res=0xffff0008
D/TC:? 0 system_open_ta_binary:249 Lookup user TA ELF 8ffff200-2450-11e4-abe2-0002a5d5c51b (REE)
D/TC:? 0 system_open_ta_binary:253 res=0x0
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
E/LD:  ldelf:163 
E/LD:  ldelf:165 
D/LD:  ldelf:171 ELF (8ffff200-2450-11e4-abe2-0002a5d5c51b) at 0x40030000
D/TC:? 0 tee_ta_close_session:512 csess 0x9e8a7170 id 1
D/TC:? 0 tee_ta_close_session:532 Destroy session
E/TC:? 0 tee_ta_close_session:544 
E/TC:? 0 destroy_session:281 
E/TC:? 0 destroy_session:283 
E/TC:? 0 destroy_session:286 
E/TC:? 0 init_with_ldelf:258 CFG_FTRACE_SUPPORT
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_phys_get_cattr:78 
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_phys_get_cattr:78 
D/TC:? 0 tee_ta_init_session_with_context:590 Re-open TA 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
D/TC:? 0 tee_ta_init_session_with_context:590 Re-open TA 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_with_fobj_get_cattr:587 
D/TC:? 0 tee_ta_close_session:512 csess 0x9e8a63a0 id 1
D/TC:? 0 tee_ta_close_session:532 Destroy session
E/TC:? 0 tee_ta_close_session:544 
E/TC:? 0 destroy_session:281 
E/TC:? 0 destroy_session:283 
E/TC:? 0 destroy_session:286 
E/TC:? 0 entry_close_session:352 
D/TC:? 0 tee_ta_close_session:512 csess 0x9e8a7970 id 1
D/TC:? 0 tee_ta_close_session:532 Destroy session
E/TC:? 0 tee_ta_close_session:544 
E/TC:? 0 destroy_session:281 
E/TC:? 0 destroy_session:283 
E/TC:? 0 destroy_session:286 
E/TC:? 0 destroy_session:289 
E/TC:? 0 destroy_session:292 
E/TC:? 0 destroy_session:295 
E/TC:? 0 user_ta_dump_ftrace:496 
E/TC:? 0 user_ta_dump_ftrace:508 
E/TC:? 0 user_ta_dump_ftrace:515 blen:1372, 0x55c
E/TC:? 0 user_ta_dump_ftrace:521 pl_sz:4096, 0x1000
E/TC:? 0 user_ta_dump_ftrace:523 
E/TC:? 0 user_ta_dump_ftrace:530 
E/TC:? 0 user_ta_dump_ftrace:535 mobj->size:65536
E/TC:? 0 mobj_get_cattr:66 
E/TC:? 0 mobj_get_cattr:69 
E/TC:? 0 vm_map_pad:255 res:0xffff0000
E/TC:? 0 user_ta_dump_ftrace:539 res:0xffff0000

Through the log "E/TC:? 0 mobj_get_cattr:69" and code, it can be located that mobj->ops->get_cattr is not found in the mobj_get_cattr function. Since I don't know enough about the core OPTEE code, this is the problem I can find.

static inline TEE_Result mobj_get_cattr(struct mobj *mobj, uint32_t *cattr)
{
	EMSG("");    // line 66
	if (mobj && mobj->ops && mobj->ops->get_cattr)
		return mobj->ops->get_cattr(mobj, cattr);
	EMSG("");    // line 69
	return TEE_ERROR_GENERIC;
}

In addition, I use the same compilation parameters based on optee_os 3.16.0, and add some debug log: zhanlej@ed5e2e5, the compiled bl32 phenomenon is the same, the log is as follows:

D/TC:? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 8ffff200-2450-11e4-abe2-0002a5d5c51b
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
D/TC:? 0 ldelf_load_ldelf:95 ldelf load address 0x40006000
D/LD:  ldelf:134 Loading TS 8ffff200-2450-11e4-abe2-0002a5d5c51b
E/TC:? 0 mobj_get_cattr:80 
D/TC:? 0 ldelf_syscall_open_bin:142 Lookup user TA ELF 8ffff200-2450-11e4-abe2-0002a5d5c51b (Secure Storage TA)
D/TC:? 0 ldelf_syscall_open_bin:146 res=0xffff0008
D/TC:? 0 ldelf_syscall_open_bin:142 Lookup user TA ELF 8ffff200-2450-11e4-abe2-0002a5d5c51b (REE)
D/TC:? 0 ldelf_syscall_open_bin:146 res=0
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
D/LD:  ldelf:168 ELF (8ffff200-2450-11e4-abe2-0002a5d5c51b) at 0x4008f000
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:80 
D/TC:? 0 tee_ta_init_pseudo_ta_session:296 Lookup pseudo TA 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
D/TC:? 0 tee_ta_init_pseudo_ta_session:309 Open system.pta
D/TC:? 0 tee_ta_init_pseudo_ta_session:326 system.pta : 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
D/TC:? 0 tee_ta_init_session_with_context:607 Re-open TA 3a2f8978-5dc0-11e8-9c2d-fa7ae01bbebc
E/TC:? 0 mobj_get_cattr:80 
D/TC:? 0 tee_ta_close_session:512 csess 0x9e8a84d0 id 1
D/TC:? 0 tee_ta_close_session:531 Destroy session
D/TC:? 0 tee_ta_close_session:512 csess 0x9e8a9910 id 1
D/TC:? 0 tee_ta_close_session:531 Destroy session
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 mobj_get_cattr:83 
E/TC:? 0 vm_map_pad:281 res:0xffff0000

Please help me explain the reason for this phenomenon.

[zhanlej]

Hi, @etienne-lms @jforissier @b49020 @jbech-linaro ,

Sorry to bother you, do you have any suggestions?

[jforissier]

Hello @zhanlej,

I tried running xtest with mostly the same configuration flags as yours, on QEMUv8 (https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8), and it worked as expected, so I could not investigate more.

$ make -j10 CFG_TEE_CORE_LOG_LEVEL=3  CFG_TEE_TA_LOG_LEVEL=1 ta-targets=ta_arm64 CFG_TEE_TA_MALLOC_DEBUG=y CFG_FTRACE_SUPPORT=y CFG_ULIBS_MCOUNT=y CFG_TA_MCOUNT=y CFG_FTRACE_BUF_SIZE=100000 run

$ xtest 4002
[...]
$ ls -l /tmp
total 140
-rw-r--r--    1 tee      tee          99369 Mar  4 10:31 ftrace-cb3e5ba0-adf1-11e0-998b-0002a5d5c51b.out
-rw-r--r--    1 root     root         28756 Mar  4 10:31 messages
-rw-r--r--    1 root     root            27 Mar  4 10:31 resolv.conf
-rw-r--r--    1 root     root           219 Mar  4 10:31 udhcpc.log
$

It looks like the issue is happening when the TA tries to send the ftrace buffer to Normal World (tee-supplicant). Maybe try reducing CFG_FTRACE_BUF_SIZE. There is probably a bug somewhere.

[b49020]

@zhanlej

Maybe try reducing CFG_FTRACE_BUF_SIZE. There is probably a bug somewhere.

It may well be due to platform specific shared memory constraints. Have you enabled dynamic shared memory or just relying on fixed reserved shared memory approach?

[zhanlej]

@jforissier @b49020 thank you for your reply.

I tried running xtest with mostly the same configuration flags as yours, on QEMUv8 (https://optee.readthedocs.io/en/latest/building/devices/qemu.html#qemu-v8), and it worked as expected, so I could not investigate more.

I use version 3.16.0 of optee_os with no problems on QEMU, but it doesn't work properly on my hardware.

It looks like the issue is happening when the TA tries to send the ftrace buffer to Normal World (tee-supplicant). Maybe try reducing CFG_FTRACE_BUF_SIZE. There is probably a bug somewhere.

I set CFG_FTRACE_BUF_SIZE=4096 the result has no change

It may well be due to platform specific shared memory constraints. Have you enabled dynamic shared memory or just relying on fixed reserved shared memory approach?

Sorry I don't know where to set the shared memory configuration you said, please tell me the location

[b49020]

@zhanlej After looking more closely at your logs, it looks like you are hitting this problem with static shared memory approach. Following is an untested patch, give it a try if it solves your problem:

diff --git a/core/mm/mobj.c b/core/mm/mobj.c
index d91ff4b8..024c10c1 100644
--- a/core/mm/mobj.c
+++ b/core/mm/mobj.c
@@ -397,6 +397,17 @@ static bool mobj_shm_matches(struct mobj *mobj __unused, enum buf_is_attr attr)
        return attr == CORE_MEM_NSEC_SHM || attr == CORE_MEM_NON_SEC;
 }
 
+static TEE_Result mobj_shm_get_cattr(struct mobj *mobj, uint32_t *cattr)
+{
+       if (!cattr)
+               return TEE_ERROR_GENERIC;
+
+       /* All shm objects are mapped as normal cached memory */
+       *cattr = TEE_MATTR_CACHE_CACHED;
+
+       return TEE_SUCCESS;
+}
+
 static void mobj_shm_free(struct mobj *mobj)
 {
        struct mobj_shm *m = to_mobj_shm(mobj);
@@ -418,6 +429,7 @@ __weak __relrodata_unpaged("mobj_shm_ops") = {
        .get_va = mobj_shm_get_va,
        .get_pa = mobj_shm_get_pa,
        .get_phys_offs = mobj_shm_get_phys_offs,
+       .get_cattr = mobj_shm_get_cattr,
        .matches = mobj_shm_matches,
        .free = mobj_shm_free,
        .get_cookie = mobj_shm_get_cookie,

[zhanlej]

@b49020 thanks for the code.

But when I modified it according to your code, OPTEE reported the following log:

D/TC:? 0 tee_ta_close_session:512 csess 0x9e8a9910 id 1
D/TC:? 0 tee_ta_close_session:531 Destroy session
I/TA: Leave optee_aes_ta!
D/TA:  TA_DestroyEntryPoint:52 has been called
E/TC:? 0 mobj_get_cattr:80 
E/TC:? 0 assertion 'IS_POWER_OF_TWO(granule)' failed at core/mm/mobj.c:389 <mobj_shm_get_phys_offs>
E/TC:1 0 Panic at core/kernel/assert.c:28 <_assert_break>
E/TC:1 0 TEE load address @ 0x9e800000
E/TC:1 0 Call stack:
E/TC:1 0  0x9e80c1a4
E/TC:1 0  0x9e8221f4
E/TC:1 0  0x9e820100
E/TC:1 0  0x9e82aefc
E/TC:1 0  0x9e826ef8
E/TC:1 0  0x9e8277b8
E/TC:1 0  0x9e82313c
E/TC:1 0  0x9e823938
E/TC:1 0  0x9e832418
E/TC:1 0  0x9e832860
E/TC:1 0  0x9e8327a4
E/TC:1 0  0x9e80921c
E/TC:1 0  0x9e80926c

From the log, it seems that the value of granule is incorrect, so I refer to the code of the mobj_reg_shm_alloc() function and added a line of code m->mobj.phys_granule = SMALL_PAGE_SIZE; to the mobj_shm_alloc() function; The detailed modifications are as follows:

diff --git a/core/mm/mobj.c b/core/mm/mobj.c
index c7c34548..57de8451 100644
--- a/core/mm/mobj.c
+++ b/core/mm/mobj.c
@@ -395,6 +395,17 @@ static bool mobj_shm_matches(struct mobj *mobj __unused, enum buf_is_attr attr)
        return attr == CORE_MEM_NSEC_SHM || attr == CORE_MEM_NON_SEC;
 }
 
+static TEE_Result mobj_shm_get_cattr(struct mobj *mobj, uint32_t *cattr)
+{
+       if (!cattr)
+                       return TEE_ERROR_GENERIC;
+
+       /* All shm objects are mapped as normal cached memory */
+       *cattr = TEE_MATTR_CACHE_CACHED;
+
+       return TEE_SUCCESS;
+}
+
 static void mobj_shm_free(struct mobj *mobj)
 {
        struct mobj_shm *m = to_mobj_shm(mobj);
@@ -415,6 +426,7 @@ const struct mobj_ops mobj_shm_ops __weak __rodata_unpaged("mobj_shm_ops") = {
        .get_va = mobj_shm_get_va,
        .get_pa = mobj_shm_get_pa,
        .get_phys_offs = mobj_shm_get_phys_offs,
+       .get_cattr = mobj_shm_get_cattr,
        .matches = mobj_shm_matches,
        .free = mobj_shm_free,
        .get_cookie = mobj_shm_get_cookie,
@@ -439,6 +451,7 @@ struct mobj *mobj_shm_alloc(paddr_t pa, size_t size, uint64_t cookie)
 
        m->mobj.size = size;
        m->mobj.ops = &mobj_shm_ops;
+       m->mobj.phys_granule = SMALL_PAGE_SIZE;
        refcount_set(&m->mobj.refc, 1);
        m->pa = pa;
        m->cookie = cookie;

Finally, the ftrace-*.out files were successfully generated in the tmp directory.

But I have several new questions.

Question 1

Why doesn't this problem exist on QEMU?

Question 2

Because the configuration I use is

	CFG_FTRACE_SUPPORT=y \
	CFG_FTRACE_BUF_SIZE=100000 \
	CFG_TA_MCOUNT=y \
	CFG_ULIBS_MCOUNT=y \

But the final generated ftrace.out only shows the last stack, it seems that a lot of content is ignored

TEE load address @ 0x9e800000
Function graph for TA: 8ffff200-2450-11e4-abe2-0002a5d5c51b @ 40094000
              |         free_helper() {
      .080 us |          malloc_lock();
              |          gen_mdbg_free() {
              |           assert_header() {
              |            mdbg_get_footer() {
      .085 us |             mdbg_get_ftr_size();
    15.360 us |            }
    30.655 us |           }
              |           mdbg_get_footer() {
      .085 us |            mdbg_get_ftr_size();
    15.285 us |           }
              |           raw_free() {
      .080 us |            raw_malloc_validate_pools();
              |            brel() {
      .085 us |             tag_asan_free();
    15.295 us |            }
    38.105 us |           }
   114.560 us |          }
      .080 us |          malloc_unlock();
   137.955 us |         }
   153.375 us |        }
   378.735 us |       }
   394.175 us |      }
  5107.020 us |     }
  5300.200 us |    }
  7984.355 us |   }
              |   ta_header_save_params() {
      .160 us |    memset();
    15.500 us |   }
  8023.085 us |  }
  8038.515 us | }

Is there something wrong with my configuration?

Question 3

When I set CFG_SYSCALL_FTRACE=y to recompile and run on optee_os v3.16.0, although ftrace.out still shows very little data, it does not crash.

But compiling and running with CFG_SYSCALL_FTRACE=y on ti-optee-os tag: ti2020.00 version will cause OPTEE to crash. The log is as follows:

D/LD:  ldelf:171 ELF (8ffff200-2450-11e4-abe2-0002a5d5c51b) at 0x4008a000                                               
D/TC:? 0 tee_ta_close_session:512 csess 0x9e8ae170 id 1                                                                 
D/TC:? 0 tee_ta_close_session:532 Destroy session                                                                       
E/TC:? 0 tee_ta_close_session:544                                                                                       
E/TC:? 0 destroy_session:281                                                                                            
E/TC:? 0 destroy_session:283                                                                                            
E/TC:? 0 destroy_session:286                                                                                            
E/TC:? 0 init_with_ldelf:258 CFG_FTRACE_SUPPORT                                                                         
E/TC:0 0 Dead canary at start of 'stack_tmp[0]'                                                                         
E/TC:0 0 Panic at core/arch/arm/kernel/thread.c:185 <thread_check_canaries>                                             
E/TC:0 0 TEE load address @ 0x9e800000                                                                                  
E/TC:0 0 Call stack:                                                                                                    
E/TC:0 0  0x000000009e80fd88

Referring to the answer of #2256 (comment), I set STACK_THREAD_SIZE=16384 and set CFG_FTRACE_BUF_SIZE=2048 , the problem still exists

Can you provide some help?

[jenswi-linaro]

You could try increasing STACK_TMP_SIZE.

[b49020]

@zhanlej

The detailed modifications are as follows:

Glad that it worked for you with these modifications. Feel free to create an OP-TEE PR with following:

Suggested-by: Sumit Garg <sumit.garg@linaro.org>

Why doesn't this problem exist on QEMU?

Qemu is running with dynamic shared memory enabled, you would see below kernel message on Qemu but not on your platform:

[ 2.614007] optee: dynamic shared memory is enabled

So if you need to enable dynamic shared memory on your platform as well, you need to enable it as described here along with registering non-sec DRAM spaces with OP-TEE as an example here.

But the final generated ftrace.out only shows the last stack, it seems that a lot of content is ignored

It looks like there is gap in understanding ftrace config options. For more details refer here but summary is:

OP-TEE OS ftrace options:

CFG_FTRACE_SUPPORT=y
CFG_ULIBS_MCOUNT=y
CFG_SYSCALL_FTRACE=y

TA ftrace options:

CFG_TA_MCOUNT=y
CFG_FTRACE_BUF_SIZE=100000

[jforissier]

Why doesn't this problem exist on QEMU?

Qemu is running with dynamic shared memory enabled,

Indeed, I can confirm the same issue is observed if we set CFG_CORE_DYN_SHM=n on QEMU so this case definitely needs fixing.

[zhanlej]

You could try increasing STACK_TMP_SIZE.

@jenswi-linaro Thank you for your reply, but OPTEE still crashes after modifying STACK_TMP_SIZE=16384. Do you have any other suggestions?

@b49020

Feel free to create an OP-TEE PR with following: Suggested-by: Sumit Garg <sumit.garg@linaro.org>

ok i will create a PR

So if you need to enable dynamic shared memory on your platform as well, you need to enable it as described here along with registering non-sec DRAM spaces with OP-TEE as an example here.

I'm lacking knowledge about dynamic shared memory, so I don't really understand the meaning of these configurations right now, it may be improved in the future.

It looks like there is gap in understanding ftrace config options. For more details refer here but summary is:

I understand what these config options mean. My real problem is when I set CFG_ULIBS_MCOUNT=y there is too little information in ftrace-*.out . I would like to see more complete optee os call stack information. Initially I suspected it was because the value of CFG_FTRACE_BUF_SIZE was too small, causing insufficient memory to log the information. After I increased the value of CFG_FTRACE_BUF_SIZE the contents of the ftrace-*.out records did not increase.

Is there a way to increase the info of the optee os call stack in ftrace-*.out

[jforissier]

My real problem is when I set CFG_ULIBS_MCOUNT=y there is too little information in ftrace-.out .

If some function calls seem to be missing, reducing the optimization level may help. Try setting CFG_CC_OPT_LEVEL=0 when building OP-TEE (this will apply to the TA libraries) and CFLAGS_ta_arm32=-O0 -pg (will be used when compiling TA code).

After I increased the value of CFG_FTRACE_BUF_SIZE the contents of the ftrace-.out records did not increase.

Try cleaning the TA, in particular remove the file out/ta.lds which might not be generated again when CFG_FTRACE_BUF_SIZE is changed (if it contains 2048 : 0; near the end then it has kept the default value).

[github-actions]

This issue has been marked as a stale issue because it has been open (more than) 30 days with no activity. Remove the stale label or add a comment, otherwise this issue will automatically be closed in 5 days. Note, that you can always re-open a closed issue at any time.