[参考译文] TDA4VH-Q1：运行推理时存储器损坏

您好！  

感谢您的提问。 我们将其分配给我们的专家。

此致、
Sarabesh S.

您好！

您能帮助我了解一下图形的流程以及这里涉及的节点吗？

您是否转储了各个节点的输出并检查了哪个输出是错误的？

1. mmalib_10_00_00_09

2. pdk_j784s4_09_02_00_30

为什么 SDK 9.2的 mmalib 版本不匹配？  是否已经与 TIDL 团队讨论过这个问题？

此致、

Nikhil

您好、Nikhil：

感谢您的快速响应。

管道中有几个节点：  

1. tivxVpacVissNode -用于脱马赛克(原始到 NV12 )。

 TIvxVpacLdcNode -用于不失真(NV12)。

在另一个图上、我们使用自定义内核从 NV12转换为 BGR。

我们主要在未失真的图像输出上看到损坏。

关于 mmalib 版本、是的、这是 TI 团队提供的、以便通过9.2 SDK 使用版本10的 TIDL 新功能。

仅供参考、我刚刚向  John Smrstik 发送了一封电子邮件、其中包含可用于重现内存损坏的独立应用程序。

巴拉克

我无法访问该链接、您能帮助我吗？

此外、为了确认、您已经拥有 SDK 10.0的 tidl repo 和 mmalib repo、对吗？ 还是只是 mmalib repo？

此致、

Nikhil

大家好、Nikhil、我已经参与其中。

关于 repos:  

我们使用 c7x-mma-tidl_j784s4_10_00_05_00和 mmalib_obj_C7120_10_00_00_09。

我们 在构建 SDK 之前被指示对 SDK 进行以下更改：

·ln -s pdk_j784s4_09_02_00_30/ pdk

·ln -s mmalib_10_00_00_09/ mmalib_09_02_00_08

我们还在 jacinto7/esd/tidl-tools/10_00_05_00/OSRT_tools/arm_linux/arago/onnx_1.14.0_aragoj7.tar.gz 中使用 onnx_runtime

尊敬的 Barak：

我已获得访问权限。 谢谢你

但我看到这两个应用程序都有二进制文件。

从应用角度来看、它在 ImagePreProcesses_tests 上仅为一个 LDC 节点、在 DNN_Profiling 上为单个 TIDL 节点？  

它们将在不同的图形中运行(因为它们是不同的进程)、但是2个进程之间是否有数据交换或它们是独立的？

此致、

Nikhil

是的、这是 ImagePreProc 二进制文件上的单个节点和 DNN_Profiling 的 TIDL 会话(不确定引擎盖下是否涉及图形)。

它们完全独立、它们之间没有数据交换。

您好！

我按照提供的文档和 SDK 运行了应用程序。  

我使用了脚本 ./ runTest.sh &./ runProf.sh && FG  并行运行这两个应用

我无法重现此问题(即我得到 所有测试均通过 始终)

重现此示例是否需要平均迭代次数？

此外、我在两个应用程序结束时看到 SEG 故障、我知道为什么会出现这种情况吗？ 我们能顺利地解决这个问题吗？

此致、

Nikhil

您好、Nikhil、尝试不使用 FG 运行。 在./RunTest.sh 之前运行 runProf.sh ./RunTest.sh 非常重要。

不确定 segFault、可能会发生这种情况、因为您没有使用我们正在使用的固件、但它应该会重现任何使用方法。

如果您愿意、我们可以安排实际操作会议。

尊敬的 Barak：

OpenVX 应用程序的分配发生在 vxVerifyGraph ()  

1.可以 在中启用 APP_MEM_DEBUG 吗  app_utils/utils/mem/app_mem_linux_dma_heap.c src  要启用更多与内存相关的日志并共享两个应用程序的日志？ (这应该会为您提供执行两个图形期间调用的所有 DDR_SHARED_MEM 分配)

2.如果您确保第二个应用程序只在第一个应用程序的 vxVerifyGraph()之后启动、您是否会看到缓冲区损坏问题？

此致、

Nikhil

您好、Nikhil：

关于1 -当然,我已经将应用程序的输出保存到文件,并将上传到 共享驱动器目录( tar.gz 所在的位置)。 我将在 PROF 应用程序输出通过和失败时上传测试应用程序输出。

关于2 -我不确定你的意思,但目前为了重现这个我手动运行 prof 然后测试应用程序,所以我不能真正同步 vxVerifyGraph ()调用。 此外、无法在我们的应用程序中完成此操作、因为图形和推理调用是从不同线程执行的。

感谢您共享日志、您是否在 runProf.sh 端也看到相同的内存日志？ 您能分享相同的好和坏情况和1一样吗.

此致、

Nikhil

Nkihil、您好、runProf.sh 仅在循环中运行推理。 图像处理测试(RunTest.sh)是在后台运行推理时失败的测试。 您是否成功重现了测试故障？

尊敬的 Barak：

我尝试了分析 RunTest 应用程序中的内存分配模式、其中失败和通过测试的分配顺序都相同、我看到在执行应用程序期间会释放大量内存、导致先前间隙之间的内存分配。

我想知道应用程序是如何编写的吗？ 您能否共享应用程序  RunTest.sh 的源文件。

Unknown 说：

runProf.sh 仅在循环中运行推理

runProf.sh 中也应该会看到相同的存储器日志、因为 DDR_SHARED_MEM 中也应该分配了存储器。

Unknown 说：

您是否已成功重现测试故障？

我仍然不能再现这种情况。 我尝试将以太网连接到 CPSW2G 端口、以便为 UART 打开两个终端、但 CPSW2G 网络在 SDK 包中似乎无法正常工作(即无法 ping 到检测到的 IP)  

现在开始运行  ./ runProf.sh &./ runTest.sh &  正如您提到的、它仍然会与 runProf 首先运行并行运行。

我还能获得 runProf.sh 的 mem 日志吗？  

我知道、只发生了9个存储器分配、其中一个将是 LDC 的输出缓冲区、您可以检查每次迭代、谁将 CCS 连接到 R5内核而损坏了此存储器？

此致、

Nikhil

行动项目
====

Leddartech
====

-正如调用中所讨论的,运行测试应用程序中存在4个中间输出。  

1. vx_image 使用 tivx_utils_create_vximage_from_bmpfile ()从 bmp 读取的文件输出、即输入 RGB 图像到颜色转换节点
2. 颜色转换节点的输出
3. LDC 节点的输出(提供了网格参数)
4. 转换后的 RGB 输出(即 png)

-我们可以尝试在 runTesh 中一次只保留1并检查问题何时重现  

 例如、用例1： runTest.sh 只有上面的输出1

       用例2： runTest.sh 有输出1和输出2  

       用例3： runTest.sh 有输出1、2和3

       用例4： runTest.sh 有输出1、2、3和4 (这是当前用例)

       用例5： runTesh.sh、具有不带任何网格参数的 LDC 节点、如下所示  

                节点= TIvxVpacLdcNode (图形、
                                     param_obj、
                                     null、
                                     null、
                                     null、
                                     null、
                                     null、
                                      INPUT_IMAGE、
                                      OUTPUT_IMAGE、
                                      null)；

        此用例将检查网格参数创建是否存在问题。 这将输出一个未校正的图像、该图像应与  INPUT_IMAGE 相同

- Leddartech 检查是否可以为 TI 提供 RunTest 的源代码、并对生成进行处理、并在提供的文件系统上运行此代码

TI

-检查 Leddartech 提供的以太网设置尝试 ssh 到电路板

-尝试使用这个 ssh 重现问题

此致、

Nikhil Dasan

您好 Nikhil：

我已根据您的请求在每次操作后添加了图像导出(在图像加载之后、转换为 nv12之后、在 LDC 节点之后以及转换为 RGB 之后)。 结果可以在我们的共享驱动器中看到(查找名为 Image_Outputs_Breakdown .tar.gz 的 tarball)。

正如预期的那样、当 runProf.sh 在后台运行时、LDC 图形之后的图像会损坏。

后来、我在没有您要求的网格参数的情况下运行了 LDC 测试、但无法重现这种现象。

关于发送源代码、我将针对这一点给您回复。

BR、

巴拉克

尊敬的 Barak：

Unknown 说：

稍后、我运行了 LDC 测试、但没有您要求的网格参数、无法重现此现象。

以确认当前场景。

带 LDC 节点的 RunTest 应用程序包含网格参数-->问题

带 LDC 节点但没有网格参数的 RunTest 应用程序   -->不存在问题。

我对吗？

此致、

Nikhil

您好、Nikhil：

是的、您回答正确。 但值得一提的是、我在两种情况下都在后台使用 runProf.sh 进行了推理。

我还将测试应用程序源代码上载到共享驱动器(在 Source 文件夹下)以供您查看。

BTW、您是否已成功重现问题？

如果您有更多问题、我们可以安排另外一次会议。

巴拉克

尊敬的 Barak：

是的、我们已经重现了此问题。 我们可以通过任何方法从自己的角度构建该应用、从而进行调试。

同时,您可以通过引用 app_single_cam 尝试使用 vxCopyImagePatch()使用 LUT_HEADER 文件加载 meshImg。

此致、
Gokul

您能否通过运行以下命令、在启用 APP_MEM_DEBUG 并为每条线路打印时间戳的情况下共享故障情况的应用程序日志、

./ runProf.sh | ts '%M:%.S'

./ runTest.sh | ts '%M:%.S'

此致、
Gokul

尊敬的 Gokul：

我已经生成了您要求的日志、您可以在名为"fail_logs_with_mem_and_ts_18_2_25"的目录下的共享驱动器中找到。

重新分级您提到的 MeshImg 测试,目前我们正在自己构建网格网格(我已经将缺少的 initMeshImage()函数添加到共享驱动器中的以下文件 Proc_Test_ 459.cpp ),因此我们目前不使用 DCC 工具配置网格。

关于您请求的应用程序、我很快就会更新。

巴拉克

尊敬的 Barak：

我们将查看这些文件。

Unknown 说：

关于您申请的应用程序、我很快将更新。

当然。

此致、
Gokul

尊敬的 Gokul：

我已经将 testApp 的源文件和构建文件上传至共享驱动器。

查找 testApp.tar.gz。

由于事情的紧迫性、 请安排一次集会、以便我们可以检查文件并同步此事件。

巴拉克

尊敬的 Barak：

我在 runProf.sh 中保留了断点(当 c7x 开始读取地址0xC02e0000的数据时),应用程序在某个点停止(见下面打印的日志),

root@j784s4-ecu:/opt/buffOverrunDemo# ./runProf.sh 
APP: Init ... !!!
MEM: Init ... !!!
MEM: Initialized DMA HEAP (fd=5) !!!
MEM: Init ... Done !!!
IPC: Init ... !!!
IPC: Init ... Done !!!
REMOTE_SERVICE: Init ... !!!
REMOTE_SERVICE: Init ... Done !!!
 23593.619766 s: GTC Frequency = 200 MHz
APP: Init ... Done !!!
 23593.619883 s:  VX_ZONE_INIT:Enabled
 23593.619902 s:  VX_ZONE_ERROR:Enabled
 23593.619918 s:  VX_ZONE_WARNING:Enabled
 23593.620454 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:116] Added target MPU-0 
 23593.620617 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:116] Added target MPU-1 
 23593.620748 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:116] Added target MPU-2 
 23593.620878 s:  VX_ZONE_INIT:[tivxPlatformCreateTargetId:116] Added target MPU-3 
 23593.620898 s:  VX_ZONE_INIT:[tivxInitLocal:136] Initialization Done !!!
 23593.621168 s:  VX_ZONE_INIT:[tivxHostInitLocal:101] Initialization Done for HOST !!!
VayaUtils : INFO1 : /opt/vayadrive/Utils/VisionAppsHandler.cpp(61)::checkFirmwareCompatibility() Checking firmware version compatibility.
/opt/vayadrive/build/TDA4VH/VAYA_CONSOLE_TDA4_AARCH64/Release/_deps/vayadrive-tda4-fw-src/services/remote_ctrl/client/RemoteCtrlClient.cpp(79): appRemoteServiceRun() failed with -1
VayaUtils : ERROR : /opt/vayadrive/Utils/VisionAppsHandler.cpp(70)::checkFirmwareCompatibility() Unable to fetch firmware version for core C7X_1
/opt/vayadrive/build/TDA4VH/VAYA_CONSOLE_TDA4_AARCH64/Release/_deps/vayadrive-tda4-fw-src/services/remote_ctrl/client/RemoteCtrlClient.cpp(79): appRemoteServiceRun() failed with -1
VayaUtils : ERROR : /opt/vayadrive/Utils/VisionAppsHandler.cpp(70)::checkFirmwareCompatibility() Unable to fetch firmware version for core C7X_2
/opt/vayadrive/build/TDA4VH/VAYA_CONSOLE_TDA4_AARCH64/Release/_deps/vayadrive-tda4-fw-src/services/remote_ctrl/client/RemoteCtrlClient.cpp(79): appRemoteServiceRun() failed with -1
VayaUtils : ERROR : /opt/vayadrive/Utils/VisionAppsHandler.cpp(70)::checkFirmwareCompatibility() Unable to fetch firmware version for core R5F_1
/opt/vayadrive/build/TDA4VH/VAYA_CONSOLE_TDA4_AARCH64/Release/_deps/vayadrive-tda4-fw-src/services/remote_ctrl/client/RemoteCtrlClient.cpp(79): appRemoteServiceRun() failed with -1
VayaUtils : ERROR : /opt/vayadrive/Utils/VisionAppsHandler.cpp(70)::checkFirmwareCompatibility() Unable to fetch firmware version for core R5F_2
DNNBase : INFO1 : /opt/vayadrive/StandaloneAlgos/DNN/Base/tidlbase.cpp(212)::initialize() Creating new session for /opt/buffOverrunDemo/data/TransformersModelBack/TransformersModelBack_1728808740.onnx
libtidl_onnxrt_EP loaded 0x2d99ee70 
Final number of subgraphs created are : 1, - Offloaded Nodes - 16, Total Nodes - 16 

在这里停止 runProf.sh 后、我运行了 runTest.sh、没有问题(所有测试都通过了)。

我的假设是在这一点之后(从上面的日志打印中)、 0xC02e0000 (物理地址)处的内存会被释放给 runProf 进程、在这里释放的内存会被分配给 RunTest。 但 C7x 仍在使用该内存,这与 RunTest 进程中为 meshImg 分配的内存冲突。

你能否在启用 APP_MEM_DEBUG 的情况下为 runProf 发送二进制文件、或者在可能的情况下共享在 runProf 应用程序内部进行的此存储器分配和释放的源。

当我尝试同时运行两个应用程序时,我可以看到为 meshImg 分配的内存被 c7x 覆盖。

此致、
Gokul

尊敬的 Gokul：

我已将启用 APP_MEM_DEBUG 的 runProf 应用程序放在共享驱动器 App_With_的 prof_intabs_prints 文件夹下。

巴拉克

尊敬的 Barak：

runProf 不会打印内存调试信息、您能否自行检查一次二进制文件。

此致、
Gokul

尊敬的 Gokul：

它在我这边工作。 如果我没记错、 更新就 在 tivision_apps 内部。那么、更新就在 tarball 内部。

请尝试 将 profDbg tarball 的所有内容提取到 TDA4VH 平台中的/opt/中并使用目录(/opt/profDbg/runProf.sh)中的脚本。

巴拉克

尊敬的 Barak：

如调用中所述、我们需要知道哪个 optenvx_object、testProf 应用程序正在释放内存。

下面是我使用 APP_MEM_DEBUG_ENABLED 运行 testProf 的推理。

步骤1：首先在物理地址0x900060000处分配某些存储器、然后根据分配的大小、此分配的结束地址为0x9002fa354。

0x900060000 - 0x9002fa354

步骤2:一段时间后,它得到释放。

第3步：释放后、内存区域被分配给2个不同的区域、

0x900060000 - 0x9001a0000

和

步骤4：0x9001a0000 - 0x9002e0000

在 runTest.sh 应用程序 meshImg 对象分配在0x9002e0000处、因为 Linux 视点是免费的。 这一切看起来都很好。

但当我们运行 runProf 应用程序时、仍然有一些东西写入地址0x9002e0000的存储器中。

我怀疑在步骤1时内存范围与 meshImg 内存范围冲突。

我们运行了另一个测试、在步骤1之后、在步骤2之前停止了 runProf 应用程序、因此0x900060000处的内存未被释放。

然后运行 RunTest 应用程序 meshImg 分配在地址0x902050000中,应用程序运行良好并传递测试用例。

(我们将断点放置在 mesImg 分配到0x902050000处,并从断点继续在应用程序 runProf 和 RunTest 中)。

此致、
Gokul

尊敬的 Gokul：

我将为 profApplication 准备源代码和构建脚本。

我还完全删除了我们的内存同步红外线(cpu-openvx)、我仍然看到问题。

准备好后我会进行更新。

巴拉克

profApp 源代码和构建脚本位于我们的共享驱动器中、名为 profApp.tar.gz。

您可以用与前一个相同的方法构建它。

如果您有任何问题、请告诉我。

巴拉克

尊敬的 Barak：

我获取了文件并成功构建了它。

我正在对其进行调试、并会告诉您我是否获得了任何结果。

此致、
Gokul

尊敬的 Rahul：

您能具体说明一下吗？ 您指的是哪些文件？

更改后、我应该重新编译 SDK 吗？ 我应该再次刻录 SDcard 吗?

我提醒您、我们 对9.2 SDK 使用 c7x-mma-tidl_j784s4_10_00_05_00和 mmalib_obj_C7120_10_00_00_09。

巴拉克

尊敬的 Rahul：  

我已经更新了/opt/ti-processor-sdk-rtos-j784s4-evm-09_02_00_05/c7x-mma-tidl/arm-tidl/rt src tidl_rt_ovx.c、并按照您的说明进行操作。  

但它无法 解决问题、我看到了相同的问题。

巴拉克

尊敬的 Gokul：

在我们今天的对话之后,您可以在共享驱动器中找到一个名为"SDK9.2_Leddartech"的新目录,其内容如下:

1.  ti-processor-sdk-rtos-j784s4-evm-09_02_00_05.tar.gz -构建应用程序时使用的更新 SDK 的存档。

2. libtivision_apps_debug -在此文件夹中,您将找到按照您的要求编译以进行调试的 vision_apps 库。

如果您还有其他需要、请告诉我。

巴拉克

尊敬的 Rahul：

我不确定这是一个简单的测试、为了更改输出张量大小、我还需要更改 DNN 文件。

我也不确定我是否理解预期的输出。 顺便说一下、您有完整的代码和编译功能、所以我不确定我能为您提供什么帮助。

巴拉克

Rahul、Gokul、明天我们再开会讨论一下这个问题。

尊敬的 Barak：

Gokul 已经测试了我上面的建议,这似乎解决了问题。
我们正在与 TIDL 专家在内部探讨输出溢出的根本原因、原因

此致
Rahul T R

感谢您发送编修。

鉴于此事的紧迫性、我们将尽快对解决方案进行测试。

您认为您能在星期五之前向我们发送指示吗？

谢谢！

巴拉克

D.

尊敬的 Barak：

在我们调查 TIDL 问题时、您可以尝试以下权变措施
这是简单的应用更改

变化  DIM[0]= 2  而不是  DIM[0]= 1  中的噪声频谱密度
创建输出张量时的 cpp 应用程序代码(在 vxCreateTensor 之前)。


此致
Rahul T R

团队、

这是因为我们想澄清 TIDL 行为不存在问题。 应用不尊重 TIDL 所请求的输入和输出存储器。 请参阅以下文档

https://github.com/TexasInstruments/edgeai-tidl-tools/blob/master/docs/tidl_fsg_io_tensors_format.md

应用程序似乎不 符合作为 IOBufDesc 一部分请求的大小。 对于某些特定情况、TIDL 需要一些额外的空间、而 IN 可能与确切的形状不匹配。 因此、作为应用程序编写器、应通过考虑输入和输出端的 IOBufdesc 来分配存储器

谢谢！
不是很重要

Pramod

在 使用 ONNX RT 时、我们的应用团队会提出一个后续问题(如果适用)。 答案如下：

如果用户通过共享存储器直接向 TIDL-RT 馈送输入、则适用共享存储器。

真正的 ONNX RT 接口是 Linux 用户空间中的电源缓冲区、让 ONNX RT 通过将 ARM 共享存储器中的缓冲区复制到 DSP 来委派给 TIDL-RT。 在本例中、TIDL-RT 管理共享存储器空间中输入和输出的缓冲区分配、因此在用户空间中、您可以根据缓冲区的实际形状提供缓冲区大小

但正如您知道的 、上述方法涉及一个缓冲区复制、为了尽量减少缓冲区复制、我们根据应用要求直接在共享存储器中提供输入和输出。 在这种方法中、虽然您使用 ONNX RT、但仍然从 输入和输出缓冲区属性视点绕过 ONNXRT。 因此、在这种情况下 、应用需要遵守 TIDL-RT 针对其输入和输出提出的缓冲器要求

谢谢！

此致、

Pramod

尊敬的 Barak：

请确认上述解决方案是否解决了您的问题。

此致、
Gokul

您好 Gokul 和 Pramod、

此时我可以更新、将 dims[0]更改为2可以消除在将其应用于我与您共享的代码时发生的内存损坏。 下一阶段是将其集成到我们的应用程序中、并检查推理输出的数据有效性。

另外、我们刚刚与您的团队举行了一次会议(Varun 和 Chris 参加了会议)、我分享说、此修复对我来说并不清楚、因为我不了解 Pramod 在上面讨论的内存大小需求链接。 他们说、这些内存大小要求实际上包括内存对齐和填充、我们在分配缓冲区时应该考虑这些内存对齐和填充、这些详细信息可以从与 ONNX 一起使用的工件文件中提取。 我们已要求从我与您分享的工件中提取这些内存详细信息(可在 buffOverrunDemo.tar.gz 中的 data/TransformersModelBack 文件夹下看到)。

请提供用于提取数据和为输出密度计算存储器起始+结束地址的说明。  

BTW -我们是否应该以相同的方式分配输入密度？

谢谢！

巴拉克

继续后面的问题、我这边还有2个问题：

1.我们是否可以在人工编译过程中控制/覆盖实际数据的填充和对齐?

2.当我们给指针提供 张量到 ort::value::CreateTensor, 我们应该提供指向填充起始点的指针(下图中的蓝色箭头)或指向数据起始点的指针(下图中的红色箭头)。

尊敬的 Barak：

来回答您的问题

"我已经说过、此修复程序对我来说并不清楚、因为我不明白 Pramod 在上面讨论的内存大小要求的链接。 他们分享了这些内存大小要求实际上包括内存对齐和填充、我们在分配缓冲区时应考虑这些内存对齐和填充"

-是的,在共享内存中为输入和输出分配的实际内存要求可能高于模型尺寸。 此外、在某些情况下、输入和输出都可能需要一个额外的平面、而这是设计所必需的。 如果通过 ONNX (即在 ARM 上)分配内存、共享内存分配将在内部进行、并且分配适当的大小。 据我所知、您是直接分配共享存储器、因此这些大小可能与 onnx 张量大小不同。 通过读取工件中生成的*。io_1.bin、可以找到实际大小。 这 是 sTIDL_IOBufDESC (https://software-dl.ti.com/jacinto7/esd/processor-sdk-rtos-jacinto7/10_00_00_05/exports/docs/c7x-mma-tidl/ti_dl/docs/user_guide_html/structsTIDL__IOBufDesc__t.html) 的二进制文件、其中包含 TIDL 所需的实际缓冲区大小的所有信息

" 我们已要求从我与您分享的工件中提取这些内存详细信息"

-现在,如果应用程序是基于 OSRT 的,该结构不会公开。 只有基于 TIDL-RT 的应用程序可以访问该结构。 这 需要改进、我们将努力 解决这一问题、公布结构、并更新我们的示例。

"我们应该以同样的方式分配输入密度"

-是的,从技术上讲,输入张量大小也应该来自上面提到的相同结构。

目前、您可以分配额外的平面、该平面应该正确无误。

您好、Abhey、  

因此、我的一位同事设法找到了一个解析 io.bin 文件的代码。

解析显示大多数输出感应器按照您的指示请求填充1个通道、但另一个需要填充5个通道。

我目前考虑了几个假设：

1.我们正在正确解析数据(再次,需要解析二进制文件的指令)。

2.增加 OpenVX API 中的通道填充将扩展数据(平面)末尾的通道。

3.我们可以增加 openvx 内存而不改变 cv :: mat (谁使用相同的内存)到原始大小(没有填充)。

4.不支持除通道填充之外的任何填充(我不确定我们如何处理数据本身附近的填充)。

5.我们交给 tensorCreate API 的指针是分配(VX)数据的开头。

此外,我们仍然想知道我们是否可以控制伪影编译阶段的填充(这样我们就可以删除填充需求)。

我们将 在未来几天内使用此修复测试我们的应用程序。

巴拉克