[FFmpeg-trac] #8073(undetermined:new): Segfault on macOS 10.15 "Catalina": stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT); libdyld.dylib`stack_not_16_byte_aligned_error
FFmpeg
trac at avcodec.org
Sun Sep 1 21:34:57 EEST 2019
#8073: Segfault on macOS 10.15 "Catalina": stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT); libdyld.dylib`stack_not_16_byte_aligned_error
-------------------------------------+-------------------------------------
Reporter: skyzyx | Owner:
Type: defect | Status: new
Priority: normal | Component:
| undetermined
Version: unspecified | Resolution:
Keywords: osx | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
Comment (by skyzyx):
I've continued to poke at this over the last few weeks, and discovered
that I had unintentionally disabled core dumps on my system. I also
realized that I was running an older version of the binary that wasn't
tied to my current compile. I'm a dumbass.
So…
1. Today I pulled down the latest master (commit
`cc78783ce5e8837d4f4ca43eedf2d299651e65ff`).
2. I'm running the latest developer beta of macOS "Catalina" 10.15
(19A546d)
3. I updated the compile command (trying to find the simplest compile that
results in the issue), as follows:
{{{
$ MACOSX_DEPLOYMENT_TARGET=10.15 \
LIBFFI_CFLAGS=-I/usr/include/ffi \
LIBFFI_LIBS=-lffi \
GLIB_CFLAGS="-I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include" \
GLIB_LIBS="-lglib-2.0 -lgio-2.0" \
CFLAGS=`freetype-config --cflags` \
LDFLAGS=`freetype-config --libs`
PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/usr/local/lib/pkgconfig:/usr/lib/pkgconfig:/opt/X11/lib/pkgconfig
\
./configure \
--arch=x86_64 \
--cpu=native \
--cc=/usr/bin/clang \
--disable-htmlpages \
--disable-podpages \
--disable-txtpages \
--disable-stripping \
--enable-debug=3 \
--enable-small \
&& \
make -j$(nproc)
}}}
This resulted in `ffmpeg_g` in the local directory. After re-enabling core
dumps (with `ulimit -c unlimited`), I ran it with `lldb`:
{{{
$ lldb ./ffmpeg_g
(lldb) target create "./ffmpeg_g"
Current executable set to './ffmpeg_g' (x86_64).
(lldb) r --help
Process 41569 launched: '/Library/WebServer/Documents/ffmpeg/ffmpeg_g'
(x86_64)
Process 41569 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
frame #0: 0x00007fff67bfb316
libdyld.dylib`stack_not_16_byte_aligned_error
libdyld.dylib`stack_not_16_byte_aligned_error:
-> 0x7fff67bfb316 <+0>: movdqa %xmm0, (%rsp)
0x7fff67bfb31b <+5>: int3
0x7fff67bfb31c <+6>: nop
0x7fff67bfb31d <+7>: nop
Target 0: (ffmpeg_g) stopped.
}}}
…which is pretty much the same as last time. I ran the binary again to
generate a core dump.
{{{
$ ./ffmpeg_g
Segmentation fault: 11 (core dumped)
}}}
I then loaded the core dump into `lldb`:
{{{
$ lldb -c /cores/core.41724
(lldb) target create --core "/cores/core.41724"
Core file '/cores/core.41724' (x86_64) was loaded.
}}}
http://ffmpeg.org/bugreports.html appears to be outdated, and should
probably be updated for `llvm` by someone who understands this stuff. But
here was what I was able to figure out:
{{{
(lldb) bt
* thread #1, stop reason = signal SIGSTOP
* frame #0: 0x00007fff67bfb316
libdyld.dylib`stack_not_16_byte_aligned_error
}}}
The `disass $pc-32,$pc+32` command listed doesn't work as expected in
`lldb`. I was able to find https://lldb.llvm.org/use/map.html where I was
hoping to be able to convert the command into something functional, and
this is where I ended up. Please let me know if you need me to run a
different command instead.
{{{
(lldb) disassemble --pc --count 32
libdyld.dylib`stack_not_16_byte_aligned_error:
-> 0x7fff67bfb316 <+0>: movdqa %xmm0, (%rsp)
0x7fff67bfb31b <+5>: int3
0x7fff67bfb31c <+6>: nop
0x7fff67bfb31d <+7>: nop
libdyld.dylib`_dyld_fast_stub_entry:
0x7fff67bfb31e <+0>: pushq %rbp
0x7fff67bfb31f <+1>: movq %rsp, %rbp
0x7fff67bfb322 <+4>: pushq %r14
0x7fff67bfb324 <+6>: pushq %rbx
0x7fff67bfb325 <+7>: movq %rsi, %r14
0x7fff67bfb328 <+10>: movq %rdi, %rbx
0x7fff67bfb32b <+13>: movq 0x2d062756(%rip), %rax ;
_dyld_fast_stub_entry(void*, long)::p
0x7fff67bfb332 <+20>: testq %rax, %rax
0x7fff67bfb335 <+23>: jne 0x7fff67bfb351 ; <+51>
0x7fff67bfb337 <+25>: leaq 0x2cfa2(%rip), %rdi ;
"__dyld_fast_stub_entry"
0x7fff67bfb33e <+32>: leaq 0x2d062743(%rip), %rsi ;
_dyld_fast_stub_entry(void*, long)::p
0x7fff67bfb345 <+39>: callq 0x7fff67bfa604 ;
_dyld_func_lookup
0x7fff67bfb34a <+44>: movq 0x2d062737(%rip), %rax ;
_dyld_fast_stub_entry(void*, long)::p
0x7fff67bfb351 <+51>: movq %rbx, %rdi
0x7fff67bfb354 <+54>: movq %r14, %rsi
0x7fff67bfb357 <+57>: popq %rbx
0x7fff67bfb358 <+58>: popq %r14
0x7fff67bfb35a <+60>: popq %rbp
0x7fff67bfb35b <+61>: jmpq *%rax
0x7fff67bfb35d <+63>: nop
0x7fff67bfb35e <+64>: nop
0x7fff67bfb35f <+65>: nop
libdyld.dylib`_dyld_get_shared_cache_uuid:
0x7fff67bfb360 <+0>: pushq %rbp
0x7fff67bfb361 <+1>: movq %rsp, %rbp
0x7fff67bfb364 <+4>: pushq %rbx
0x7fff67bfb365 <+5>: pushq %rax
0x7fff67bfb366 <+6>: movq %rdi, %rbx
0x7fff67bfb369 <+9>: leaq 0x2d0624d0(%rip), %rax ; gUseDyld3
}}}
Likewise, `info all-registers` needed to be re-mapped. So I ran the
following:
{{{
(lldb) register read --all
General Purpose Registers:
rax = 0x0000000000001428
rbx = 0x0000000104b5ea67 " "
rcx = 0x00007ffeebc27920
rdx = 0x0000000104b5ea6a "%s version N-94712-gcc78783ce5"
rdi = 0x0000000000000000
rsi = 0x0000000000000020
rbp = 0x0000000000000009
rsp = 0x00007ffeebc27818
r8 = 0x0000000000257db2
r9 = 0xffffffff00000000
r10 = 0x0000000104dceda0 avpriv_register_devices_mutex + 24
r11 = 0x0000000104dc3180 _dyld_private
r12 = 0x0000000000000000
r13 = 0x0000000000000000
r14 = 0x00007ffeebc279e0
r15 = 0x0000000000000000
rip = 0x00007fff67bfb316
libdyld.dylib`stack_not_16_byte_aligned_error
rflags = 0x0000000000010202
cs = 0x000000000000002b
fs = 0x0000000000000000
gs = 0x0000000000000000
Floating Point Registers:
fcw = 0x0005
fsw = 0x0000
ftw = 0x83
fop = 0x0000
ip = 0x3054566b
cs = 0x5749
dp = 0x0000037f
ds = 0x0000
mxcsr = 0x00000000
mxcsrmask = 0x00000000
stmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x80 0x1f}
stmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
stmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}
stmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xff 0xff}
stmm7 = {0x97 0x7d 0x3e 0x02 0x00 0x00 0x00 0x00 0xff 0xff}
xmm0 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm1 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm2 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm3 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm4 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm5 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm6 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm7 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm8 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm9 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm10 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm11 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm12 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm13 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm14 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
xmm15 = {0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00}
Exception State Registers:
trapno = 0x00000000
err = 0x00000000
faultvaddr = 0x0000000000000000
}}}
I am downloading the latest developer beta of Xcode right now. I'll try
again once I get it installed to see if I learn anything new.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/8073#comment:2>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list