Description
When uploading many small files, Chrome will deadlock and then soon crash with a SIGILL, just before it finishes uploading the 1000'th file (usually file 985 or around there). The particular number of files necessary to encounter the issue is specific to client OS configuration (max num FDs).

This bug is probably specific to Chromium and Chrome-based browsers (including Google Chrome), and only when running on Linux. It does not occur when using similar fileserver software instead of FileBrowser.

The bug happens regardless if I click upload and use the folder selector, or if I drag-and-drop a folder into the browser.

According to lsof, I can see chrome rapidly creating and deleting temporary files of the form /dev/shm/.org.chromium.Chromium.BrzUiI, but there is also a large collection of /dev/shm/.org.chromium.Chromium.zlbTsY (deleted) in the list, indicating that chrome is deleting these temporary files but not closing them. So the issue appears to be file descriptor leaks caused by FileBrowser's upload javascript. The underlying issue is possibly a chrome bug.

On my machine (archlinux), I see chrome is running with softlimit 1024, hardlimit 524288 for numOpenFiles. If I run chrome from a terminal after first running ulimit -n 4096, then I am able to upload a folder of 2000 files successfully. But chrome will crash if I then upload that same folder one more time, due to the leaked file descriptors adding up.

Chrome does not close the FDs until the tab is refreshed; maybe some state in the js keeping them alive?

This issue has been reproduced with:

• chromium 130.0.6723.91 on debian 12
• chromium 130.0.6723.116 on archlinux
• Google-Chrome 130.0.6723.116 on debian 12 (note: may require more files to hit the bug; one run didn't crash until 2886)

Windows has a larger FD limit, so this bug will probably not occur on windows.

Also, I have not managed to reproduce this bug with Firefox; it appears to be chrome-specific.

Also, when I use another fileserver software, which (I believe) uses a very similar approach to uploading files, then chrome does not leak any files, and does not crash. So the issue is also specific to FileBrowser.

Expected behaviour
the upload should complete

What is happening instead?
The javascript is causing google chrome to leak file descriptors and crash; either due to a bug in the javascript, or because the javascript provokes an existing bug in chrome

Additional context
n/a

How to reproduce?

• create a folder with many small files, for example mkdir smol; cd smol; for n in {1..4321}; do echo $n > $n.txt; done
• upload the folder to FileBrowser, either by dragging the folder into the browser, or clicking upload -> folder
• if necessary, monitor chrome's open FDs with something like netdata or lsof | grep -i chrom
• if necessary, verify that the softlimit of numOpenFiles is sufficiently low to manifest the bug; see ps aux | grep chrom to find one of its PIDs, and then cat /proc/$PID/limits which should say Max open files: 1024 (Soft Limit) or something thereabout

Files
n/a