核心转储文件名被截断
鉴于 /proc/sys/kernel/core_pattern 中的配置设置为 /cores/core.%e.%p，核心转储根据模式命名，但是对于进程运行具有长名称的可执行文件，例如 SampleCrashApplication，生成的核心文件将包含截断的可执行文件名称：/cores/core.SampleCrashAppl.9933
是什么原因导致的？ man core 页面仅讨论生成的核心文件名的最大大小为 128（2.6.19 之前的内核为 64）
Given the configuration in /proc/sys/kernel/core_pattern set to /cores/core.%e.%p, core dumps are named according to pattern, however for processes running executables with long names e.g. SampleCrashApplication, the generated core file will contain a truncated executable name: /cores/core.SampleCrashAppl.9933
What is causing this ? The man core page talks only about maximum size of the resulting core filename being 128 (64 for kernels before 2.6.19)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
代码可以在 exec.c 此处。
该代码将根据模式复制核心名称，直到第一个百分比（给出/cores/core）。它将按百分比递增并处理“e”。处理“e”部分的代码根据 current->comm 结构使用 snprintf 打印出模式。
这是可执行文件名称（不包括路径），截断为值 TASK_COMM_LEN。由于这被定义为 16 个字符（至少在我发现的内核中），因此 SampleCrashApplication 被截断为 15 + 1 个字符（1 表示末尾的空字节），这解释了为什么您会得到截断的核心转储名称。
至于为什么这个结构会截断名称 TASK_COMM_LEN，这是一个更深层次的问题，但它是内核内部的东西，并且有一些讨论 此处。
The code for this can be found in exec.c here.
The code is going to copy the corename based on the pattern up to the first percentage (giving /cores/core.). At the percentage it's going to increment and process the 'e'. The code for processing the 'e' part prints out the pattern using snprintf based on the current->comm structure.
This is the executable name (excluding path) TRUNCATED to the value TASK_COMM_LEN. Since this is defined as 16 characters (at least in the Kernel I found) then SampleCrashApplication is truncated to 15 + 1 characters (1 for the null byte at the end) which explains why you get your truncated core dump name.
At to why this structure truncates the name TASK_COMM_LEN, that's a deeper question, but it's something internal to the kernel and there's some discussion here.