After more experiments, it turned out that Firefox is the only one browser, which works. It doesn't say anything when files are dropped on the "ADD PHOTOS" page, but it eventually uploads all 2000 images.

Are you uploading photos from the main hard drive, an external drive, or a network share?

It looks like we've got an issue with FD management:

LOG_FATAL: scoped_file.cc:42: : Bad file descriptor (9)

Thread 32 (id: 49264) CRASHED [EXC_BREAKPOINT / EXC_I386_BPT @ 0x000000010cb6cba1 ] 

0x000000010cb6cba1	(Google Chrome Framework -debugger_posix.cc:267 )	base::debug::BreakDebugger()
0x000000010cb85430	(Google Chrome Framework -logging.cc:791 )	logging::LogMessage::~LogMessage()
0x000000010cb8575b	(Google Chrome Framework -logging.cc:554 )	logging::ErrnoLogMessage::~ErrnoLogMessage()
0x000000010cb8015d	(Google Chrome Framework -scoped_file.cc:42 )	base::internal::ScopedFDCloseTraits::Free(int)
0x000000010cb78fd3	(Google Chrome Framework -scoped_generic.h:153 )	base::File::Close()
0x000000010cf42188	(Google Chrome Framework -file_stream_context.cc:193 )	net::FileStream::Context::CloseFileImpl()
0x000000010cb6e27b	(Google Chrome Framework -callback.h:64 )	base::debug::TaskAnnotator::RunTask(char const*, base::PendingTask*)
0x000000010cbd7f9b	(Google Chrome Framework -task_tracker.cc:411 )	base::internal::TaskTracker::RunOrSkipTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*, bool)
0x000000010cbd8b0b	(Google Chrome Framework -task_tracker_posix.cc:23 )	base::internal::TaskTrackerPosix::RunOrSkipTask(std::__1::unique_ptr<base::internal::Task, std::__1::default_delete<base::internal::Task> >, base::internal::Sequence*, bool)
0x000000010cbd78f6	(Google Chrome Framework -task_tracker.cc:311 )	base::internal::TaskTracker::RunNextTask(scoped_refptr<base::internal::Sequence>, base::internal::CanScheduleSequenceObserver*)
0x000000010cbd279f	(Google Chrome Framework -scheduler_worker.cc:72 )	base::internal::SchedulerWorker::Thread::ThreadMain()
0x000000010cbe3a66	(Google Chrome Framework -platform_thread_posix.cc:75 )	base::(anonymous namespace)::ThreadFunc(void*)
0x00007fff5bb9d6c0	(libsystem_pthread.dylib + 0x000036c0 )	_pthread_body
0x00007fff5bb9d56c	(libsystem_pthread.dylib + 0x0000356c )	_pthread_start
0x00007fff5bb9cc5c	(libsystem_pthread.dylib + 0x00002c5c )	thread_start
0x000000010cbe3a0f	(Google Chrome Framework + 0x01cb0a0f )	

It is a network share.

Don't know if it makes any difference, but I am using Synology NAS.

The fact that it's from a network share is likely the problem – we've seen a variant of this bug before. What protocol are you using (AFP, SMB, NFS)?

I use AFP. I can enable transfer logs on Synology, if it helps.

Thank you for providing more feedback. Adding requester "spqchan@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Interesting. +davidben since this looks a lot like  issue 603354 , though this time we do have errno (EBADF) already handy.

Also +erikchen since we also have issue 786316 open, which we don't have any leads on, but it could be related to uploading from network shares.

Do either of you have ideas for how to help track what we're doing wrong with FDs here? It sounds like there's at least a consistent repro.

I am happy to run any instrumentation for you to capture more data, since I can easily reproduce it.

That it's EBADF is a little concerning. Either some code somewhere is doing bad things to fds (i.e. this is the fd analog of a UAF), which would suggest it's not related to the network share, or AFP causes benign closes to return EBADF. The latter would be incredibly bad manners. :-/ macOS does return other errno values on close sometimes, which is already kinda bad manners, but we should ignore those now.

(Renaming bug since AFS is a different network filesystem and it sounds like this bug is about AFP. :-) )

As this issue related to network file system & AFP,Seems it is out of scope from TE end, adding TE-NeedsTraige-help label to move this out of our triaging bucket.

Could someone from dev team please take a look into this issue.
Thanks..!

I would like to look into this at some point. Alternatively, someone else is free to do this.. 

Probably the next steps would be to:

1. Determine whether this is EBADF because some other piece of code is double-closing our file descriptors and hitting this one or if macOS actually sends EBADF on these networked filesystems. The latter would be rather bad manners. In the past, I think folks have had some success messing with macOS's fd guard feature, which pinpointed a bug in Security.framework. (But this report is on an up-to-date macOS, so it's not that bug.)

2. We've also had success looking at the kernel source code in https://opensource.apple.com/, which previously confirmed that networked filesystems sometimes emit non-EBADF errnos on valid fds. That could be worth another look to check this.

+mark had some experience with this sort of mess previously.

erikchen@ is working on this in issue 786316.