Glslang项目中递归循环导致的栈溢出问题分析

问题概述

在Vulkan开发环境中，使用Google的shaderc库进行运行时着色器编译时，遇到了一个栈溢出问题。这个问题发生在处理着色器代码中的常量数组初始化时，具体表现为createSpvConstantFromConstUnionArray方法的递归循环导致栈空间耗尽。

问题重现

开发者提供了一个简单的顶点着色器示例代码，其中包含两个常量数组的初始化：

vec2 positions[3] = vec2[](
  vec2(0.0, -0.5),
  vec2(0.5, 0.5),
  vec2(-0.5, 0.5)
);

vec3 colors[3] = vec3[](
  vec3(1.0, 0.0, 0.0),
  vec3(0.0, 1.0, 0.0),
  vec3(0.0, 0.0, 1.0)
);

当使用Ubuntu 23.04系统通过apt安装的libshaderc库进行编译时，程序会因栈溢出而崩溃。

技术分析

调用栈分析

从调用栈可以看出，问题发生在createSpvConstantFromConstUnionArray方法的递归调用中。该方法负责将GLSL中的常量联合数组转换为SPIR-V格式的常量。在正常情况下，这个方法应该能够处理嵌套的常量结构，但在特定版本中出现了无限递归的情况。

根本原因

经过进一步调查，发现问题可能与以下因素有关：

1. 库版本问题：使用系统包管理器安装的预编译版本可能存在特定bug
2. 递归处理逻辑缺陷：在特定情况下，常量数组的转换逻辑未能正确终止递归
3. 栈空间配置：默认栈空间不足以处理深度递归

解决方案验证

开发者尝试了从源代码编译最新版本的shaderc库（commit 57d86ab7），发现该版本已经修复了这个问题。这表明：

1. 这是一个已知的、已被修复的bug
2. 问题可能存在于特定发行版的打包版本中
3. 使用最新源代码编译可以避免这个问题

最佳实践建议

对于遇到类似问题的开发者，建议采取以下措施：

1. 使用最新源代码编译：从官方仓库获取最新代码自行编译，而不是依赖系统包管理器
2. 增加栈空间：在调试时可以临时增加栈空间大小，帮助诊断问题
3. 简化着色器代码：尝试简化常量初始化表达式，可能绕过特定版本的bug
4. 监控递归深度：在处理复杂常量表达式时，添加递归深度限制

结论

这个案例展示了开源项目中版本管理的重要性。系统包管理器提供的预编译版本可能滞后于上游修复，导致开发者遇到已解决的问题。对于关键开发工具，建议直接从源代码构建最新版本，以确保获得最稳定的功能和最新的bug修复。

同时，这也提醒我们在处理递归算法时需要特别注意终止条件和栈空间消耗，特别是在编译器这类需要处理复杂语法结构的软件中。