nschlia
commented
5 years ago gdb check of the core shows:
(gdb) bt
#0 0x00007fe8fdc5372a in ?? () from /lib64/libc.so.6
#1 0x000055c9c0f406dc in memcpy (__len=900653, __src=0x7fe8e41054f0, __dest=<optimized out>) at /usr/include/bits/string_fortified.h:34
#2 Buffer::write (this=0x7fe8ec001d40, data=0x7fe8e41054f0 "", length=900653) at buffer.cc:312
#3 0x000055c9c0f578d1 in FFMPEG_Transcoder::output_write (opaque=<optimized out>, data=<optimized out>, size=<optimized out>) at ffmpeg_transcoder.cc:3733
#4 0x00007fe8ff915fef in ?? () from /usr/lib64/libavformat.so.57
#5 0x00007fe8f8acda60 in ?? ()
#6 0x00007fe8e40cb9b0 in ?? ()
#7 0x00007fe8f8acda60 in ?? ()
#8 0x0000000000bd218a in ?? ()
#9 0x0000000000bd218a in ?? ()
#10 0x0000000000000000 in ?? ()
(gdb) 2
Undefined command: "2". Try "help".
(gdb) f 2
#2 Buffer::write (this=0x7fe8ec001d40, data=0x7fe8e41054f0 "", length=900653) at buffer.cc:312
312 memcpy(write_ptr, data, length);
(gdb) l
307 {
308 length = 0;
309 }
310 else
311 {
312 memcpy(write_ptr, data, length);
313 increment_pos(length);
314 }
315
316 return length;
(gdb) This is directly after write_prepare that prints "Error calling ftruncate() to resize the file: Bad file descriptor" which indicates that the FFMPEG_transcode object has become invalid. This means the decoder thread is still running, which is OK, but it is weird because the object will only be destroyed after the decode loop exited and that should have created some log entries (and of course transcoding should not continue in that case).
Probably someone trashed the memory...
It seems browsing in Explorer is now much quicker, I did run into segfaults almost immediately. Trying to open a folder containing a feature length mkv using Resolve file had the following result (with Resolve hanging for a long time before the segfault):