【PFCC】使用python调用api时对c++后端debug的问题

[gsq7474741]

1. 使用python调用api时如何对c++后端进行debug？

   • _C_ops调用后端时具体调用的是哪个文件？
   • phi库的反向算子是如何调用的？

2. c++代码中的VLOG()问题？

   • 运行时是否会输出log信息？
   • 会把日志记录到哪里？

[paddle-bot-old]

您好，我们已经收到了您的问题，会安排技术人员尽快解答您的问题，请耐心等待。请您再次检查是否提供了清晰的问题描述、复现代码、环境&版本、报错信息等。同时，您也可以通过查看官网API文档、常见问题、历史Issue、AI社区来寻求解答。祝您生活愉快～

Hi! We've received your issue and please be patient to get responded. We will arrange technicians to answer your questions as soon as possible. Please make sure that you have posted enough message to demo your request. You may also check out the API，FAQ，Github Issue and AI community to get the answer.Have a nice day!

[gsq7474741]

使用的IDE是clion（它的调试器后端是lldb），在c++层面的调试ide会自动把可执行文件传给lldb，但是在python层调用的时候就不行，应该给调试器传哪个文件呢？

[gsq7474741]

@TCChenlong @jeff41404

[gsq7474741]

使用lldb直接附加到python进程上的话好像不行，请问内部是怎么调试的呀

[FrostML]

使用 python 调用 api 时如何对 c++ 后端进行debug？

_C_ops.xxx 的代码是自动生成出来的，这里有一个简要的说明
_C_ops.xxx 调用的 xxx op 即可直接去找 xxx_op.h 或是 xxx_op.cc 的文件。

比如：layer_norm op

_C_ops.layer_norm()

即可直接找到 layer_norm_op.cc 文件。最下面能找到当前 op 在框架内注册的代码。

具体的 op 所调用的实现 kernel 的位置，GPU 实现可以在 paddle/phi/kernels/gpu/layer_norm_kernel.cu 找到，CPU 实现同理在对应的 CPU 路径下。

反向的实现，即可找 paddle/phi/kernels/gpu/layer_norm_grad_kernel.cu
通过最后的宏，将具体的 op 名称和对应的 kernel 实现对应上，即可找到对应实现的位置。

c++代码中的VLOG()问题？

可以设置环境变量 export GLOG_v=10 即可以看到 VLOG 的内容。执行时日志会直接打印出来，日志比较多，可以先重定向到文件。

[gsq7474741]

@FrostML 感谢解答，还一些问题：

1. python层core.eager.xxx调用的是什么？和_C_ops.xxx的关系是怎样的？
2. 我观察到phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，导致_C_ops无法调用到同一个cc文件中后面注册的kernel，不知道是我的理解有问题还是这个设计有特殊的意义

[gsq7474741]

@FrostML 还有一个问题，phi中新增注册的kernel也是通过_C_ops调用吗？

[chenwhql]

@FrostML 感谢解答，还一些问题：

1. python层core.eager.xxx调用的是什么？和_C_ops.xxx的关系是怎样的？
2. 我观察到phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，导致_C_ops无法调用到同一个cc文件中后面注册的kernel，不知道是我的理解有问题还是这个设计有特殊的意义

先说这个，phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，是为了导出这个文件的符号，导出的时候只需要有一个符号声明，整个文件的符号就会被导出，所以只需要导出第一个，不需要导出其他的哈，这个不会导致未DECLARE的kernel无法被_C_ops调用到的，决定_C_ops是否能调用到的是另外的机制

[chenwhql]

_C_ops是否能调用到主要取决与是否生成的了相应的API，目前框架正在重构，暂时存在两套生成_C_ops接口，一套是基于paddle/fluid/operators目录下的op定义注册后生成的，编译后生成的代码在paddle/fluid/pybind/op_function_impl.h中，有兴趣您可以编译一下，这一套生成和phi下面的代码无直接关联

另外一套，是正在重构的新动态图体系，会生成_C_ops.final_state_xxx相关接口，这套是根据python/paddle/utils/code_gen/api.yaml中的配置生成的，其实和phi中的kernel也没关系，api.yaml中有配置才会生成，目前并不是全量运算都会生成，还在开发，生成的代码在paddle/fluid/pybind/eager_final_state_op_function_impl.h，有兴趣您也可以在编译后看下

[chenwhql]

@FrostML 还有一个问题，phi中新增注册的kernel也是通过_C_ops调用吗？

这个问题就回答了，phi中新增注册的kernel其实都是通过_C_ops调用的，有如上两条路径，一个原来的op体系，一个是正在开发的新动态图体系，但kernel和_C_ops的生成没有直接关联，_C_ops api的生成是基于op定义的

[gsq7474741]

@FrostML 感谢解答，还一些问题：

1. python层core.eager.xxx调用的是什么？和_C_ops.xxx的关系是怎样的？
2. 我观察到phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，导致_C_ops无法调用到同一个cc文件中后面注册的kernel，不知道是我的理解有问题还是这个设计有特殊的意义

先说这个，phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，是为了导出这个文件的符号，导出的时候只需要有一个符号声明，整个文件的符号就会被导出，所以只需要导出第一个，不需要导出其他的哈，这个不会导致未DECLARE的kernel无法被_C_ops调用到的，决定_C_ops是否能调用到的是另外的机制

py前端：
def add(x, y, name=None):
    assert in_dynamic_mode(), "Currently, Sparse API only support dynamic mode"
    assert x.is_sparse_csr(
    ), "Currently, sparse.add only support the input of SparseCsrTensor"

    return _C_ops.final_state_sparse_elementwise_add(x, y)

测试：
sparse_out = paddle.sparse.add(sparse_x, sparse_y)

喔喔，我现在在新增kernel，在sparse_api.yaml中只添加正向的就没问题，可以正常执行，但是加上了反向的就会在测试这行代码中出现

进程已结束,退出代码139 (interrupted by signal 11: SIGSEGV)

查了一下可能是内存溢出，我试图修改反向kernel的内容，但是即使反向kernel什么都不做，也会出现这个问题，不知道可能是什么原因导致的

[chenwhql]

还有个问题，_C_ops是core.eager到Python端的别名封装，两者是一样的

[chenwhql]

@FrostML 感谢解答，还一些问题：

1. python层core.eager.xxx调用的是什么？和_C_ops.xxx的关系是怎样的？
2. 我观察到phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，导致_C_ops无法调用到同一个cc文件中后面注册的kernel，不知道是我的理解有问题还是这个设计有特殊的意义

先说这个，phi.cmake中只会对每个xxx_kernel.cc文件中的第一个PD_REGISTER_KERNEL宏进行字符串匹配并在自动生成的build/paddle/phi/kernels/declarations.h声明，是为了导出这个文件的符号，导出的时候只需要有一个符号声明，整个文件的符号就会被导出，所以只需要导出第一个，不需要导出其他的哈，这个不会导致未DECLARE的kernel无法被_C_ops调用到的，决定_C_ops是否能调用到的是另外的机制

py前端：
def add(x, y, name=None):
    assert in_dynamic_mode(), "Currently, Sparse API only support dynamic mode"
    assert x.is_sparse_csr(
    ), "Currently, sparse.add only support the input of SparseCsrTensor"

    return _C_ops.final_state_sparse_elementwise_add(x, y)

测试：
sparse_out = paddle.sparse.add(sparse_x, sparse_y)

喔喔，我现在在新增kernel，在sparse_api.yaml中只添加正向的就没问题，可以正常执行，但是加上了反向的就会在测试这行代码中出现

进程已结束,退出代码139 (interrupted by signal 11: SIGSEGV)

查了一下可能是内存溢出，我试图修改反向kernel的内容，但是即使反向kernel什么都不做，也会出现这个问题，不知道可能是什么原因导致的

这个我找sparse的同学帮你看下有没有遇到类似问题哈

[gsq7474741]

py前端：
def add(x, y, name=None):
    assert in_dynamic_mode(), "Currently, Sparse API only support dynamic mode"
    assert x.is_sparse_csr(
    ), "Currently, sparse.add only support the input of SparseCsrTensor"

    return _C_ops.final_state_sparse_elementwise_add(x, y)

测试：
sparse_out = paddle.sparse.add(sparse_x, sparse_y)

喔喔，我现在在新增kernel，在sparse_api.yaml中只添加正向的就没问题，可以正常执行，但是加上了反向的就会在测试这行代码中出现

进程已结束,退出代码139 (interrupted by signal 11: SIGSEGV)

查了一下可能是内存溢出，我试图修改反向kernel的内容，但是即使反向kernel什么都不做，也会出现这个问题，不知道可能是什么原因导致的

这个我找sparse的同学帮你看下有没有遇到类似问题哈

好的，十分感谢解答

[zkh2016]

@gsq7474741 可以加GLOG_v=6 make test ARGS="-R test_sparse_activation_op -V"看下执行到哪里了。 或者你提个PR，可以看下代码。

[gsq7474741]

@zkh2016 测反向开了glog但是没有任何输出，直接139，只测正向的时候是有log的，我提个pr吧

• sparse_api.yaml中只添加正向

• sparse_api.yaml中添加正向和反向

[gsq7474741]

@zkh2016 已提pr #41857

[zkh2016]

@zkh2016 已提pr #41857

ok

[zkh2016]

@gsq7474741 我大概知道问题了，因为目前还没有csr的API需要求反向，所以有些地方还没添加支持，你可以先调前向逻辑，我这边会提一个PR支持SparseCsrTensor的反向。

[gsq7474741]

@gsq7474741 我大概知道问题了，因为目前还没有csr的API需要求反向，所以有些地方还没添加支持，你可以先调前向逻辑，我这边会提一个PR支持SparseCsrTensor的反向。

喔喔 我是之前改rfc的时候加的反向，那我先把正向完善一下然后开始review吧，感谢解答