FileBrowser项目中Chrome浏览器上传多文件时的崩溃问题分析

问题现象

在使用FileBrowser文件管理系统时，当用户尝试通过Chrome或基于Chromium的浏览器上传大量小文件时，浏览器会出现死锁并最终以SIGILL信号崩溃。这一现象通常在上传接近第1000个文件时发生，具体触发点取决于客户端操作系统的文件描述符限制配置。

技术背景

现代浏览器在处理文件上传时，会创建临时文件来管理上传过程。在Linux系统上，Chrome浏览器会将这些临时文件存储在/dev/shm目录下，文件命名格式为.org.chromium.Chromium.随机字符串。正常情况下，这些临时文件在上传完成后应该被正确关闭和删除。

问题根源

通过系统监控工具lsof观察发现，Chrome浏览器在上传过程中存在文件描述符泄漏问题。具体表现为：

1. 浏览器创建了大量临时文件
2. 虽然文件被标记为已删除(deleted)，但对应的文件描述符未被正确释放
3. 当泄漏的文件描述符数量达到系统限制(通常默认软限制为1024)时，浏览器无法创建新的文件描述符
4. 最终导致浏览器进程崩溃

环境验证

该问题已在多个环境中复现：

• Chromium 130.0.6723.91/116
• Google Chrome 130.0.6723.116
• 不同Linux发行版(Debian 12, Archlinux)

值得注意的是：

1. Windows系统由于文件描述符限制较高，通常不会触发此问题
2. Firefox浏览器未出现类似问题
3. 其他文件服务器软件(如copyparty)使用类似上传机制时也不会导致此问题

解决方案

目前有两种可行的解决方案：

1. 临时解决方案：

   • 提高Chrome进程的文件描述符限制
   • 例如在启动Chrome前执行ulimit -n 4096
   • 但此方法治标不治本，多次上传后仍可能因累积泄漏而崩溃

2. 永久解决方案：

   • 使用修复了此问题的FileBrowser分支版本
   • FileBrowser Quantum分支已解决此问题
   • 建议需要上传大量文件的用户迁移至此分支

技术建议

对于开发者而言，建议从以下方面进行深入分析：

1. 检查FileBrowser前端JavaScript中文件上传处理逻辑
2. 对比分析FileBrowser与其他文件服务器在上传机制上的差异
3. 关注Chrome浏览器中与文件上传相关的内存管理机制

对于普通用户，建议：

1. 分批上传大量小文件
2. 考虑使用不受此问题影响的浏览器
3. 关注FileBrowser官方对此问题的修复进展

此问题揭示了浏览器与文件管理系统交互时可能存在的资源管理缺陷，值得Web开发者和浏览器开发者共同关注。