If mplayer is built with OTCHAIN option enabled, mplayer binary build with the port is broken and dies with SIGILL upon any invocation. My guess is that that's mplayer is allowed to set it's own compiler flags, and systemwide flags from make.conf are ignored, which is unsafe and wrong. My cpu is: CPU: Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz (3411.21-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x206a7 Family = 6 Model = 2a Stepping = 7 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE> Features2=0x179ae3bf<SSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,AESNI,XSAVE,AVX> AMD Features=0x28100800<SYSCALL,NX,RDTSCP,LM> AMD Features2=0x1<LAHF> TSC: P-state invariant, performance statistics
Responsible Changed From-To: freebsd-ports-bugs->amdmi3 Submitter has GNATS access (via the GNATS Auto Assign Tool)
Maintainer of multimedia/mplayer, Please note that PR ports/164943 has just been submitted. If it contains a patch for an upgrade, an enhancement or a bug fix you agree on, reply to this email stating that you approve the patch and a committer will take care of it. The full text of the PR can be found at: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/164943 -- Edwin Groothuis via the GNATS Auto Assign Tool edwin@FreeBSD.org
State Changed From-To: open->feedback Awaiting maintainers feedback (via the GNATS Auto Assign Tool)
Can you elaborate a little on your particular setup? I build my own mplayer WITH_OTCHAIN and if it died on me on any invocation, I believe I would have noticed :-)
* Thomas Zander (thomas.e.zander@googlemail.com) wrote: > Can you elaborate a little on your particular setup? > I build my own mplayer WITH_OTCHAIN and if it died on me on any > invocation, I believe I would have noticed :-) Nothing special except for custom options and CPU to which this may be related (gcc misdetects cpu or there's bug in optimization specific to this cpu?). Options are: --- # This file is auto-generated by 'make config'. # No user-servicable parts inside! # Options for mplayer-1.0.r20111218_3 _OPTIONS_READ=mplayer-1.0.r20111218_3 WITHOUT_DEBUG=true WITHOUT_RTCPU=true WITH_OCFLAGS=true WITH_OTCHAIN=true WITHOUT_IPV6=true WITH_X11=true WITH_X11XV=true WITH_X11DGA=true WITH_X11GL=true WITH_X11XIN=true WITH_X11VM=true WITH_X11XVMC=true WITH_VDPAU=true WITHOUT_GUI=true WITH_SDL=true WITHOUT_SKINS=true WITHOUT_RTC=true WITHOUT_ARTS=true WITHOUT_ESOUND=true WITHOUT_JACK=true WITHOUT_NAS=true WITHOUT_OPENAL=true WITHOUT_PULSE=true WITH_LIBUNGIF=true WITHOUT_OPENJPEG=true WITHOUT_MNG=true WITH_AALIB=true WITH_LIBCACA=true WITH_SVGALIB=true WITH_LIBDV=true WITH_MAD=true WITHOUT_AMR_NB=true WITHOUT_AMR_WB=true WITHOUT_GSM=true WITHOUT_LADSPA=true WITH_SPEEX=true WITH_THEORA=true WITH_VPX=true WITHOUT_SCHROEDINGER=true WITHOUT_WIN32=true WITHOUT_REALPLAYER=true WITHOUT_LIVEMEDIA=true WITHOUT_SMB=true WITHOUT_BLURAY=true WITHOUT_FRIBIDI=true WITHOUT_LIRC=true WITH_LIBCDIO=true WITHOUT_CDPARANOIA=true WITHOUT_LIBLZO=true WITHOUT_JOYSTICK=true WITH_V4L=true WITHOUT_LIBRTMP=true WITHOUT_ENCA=true --- That gave me an idea and I've tried mplayer build after `make rmconfig' and that didn't crash. The option which affects the problem seem to be RTCPU which should be disabled in order to reproduce the crash. backtrace: --- #0 0x00000000004d6af4 in m_config_set_profile () #1 0x00000000004d6d42 in m_config_set_profile () #2 0x00000000004d4d4f in samplefmt2affmt () #3 0x00000000004dc084 in m_config_parse_config_file () #4 0x0000000807678d40 in __stack_chk_guard () from /lib/libc.so.7 #5 0x000000080bcd03c0 in ?? () #6 0x000000080bc1f340 in ?? () #7 0x0000000000000000 in ?? () #8 0x0000000200000001 in ?? () #9 0x00007fffffffc441 in ?? () #10 0x000000080bc00035 in ?? () #11 0x00000008ffffffff in ?? () #12 0x000000080bc01978 in ?? () #13 0x00000000ffffffff in ?? () #14 0x000000080bc013a8 in ?? () #15 0x0000000801072577 in dlclose () from /libexec/ld-elf.so.1 --- disassembly: --- 0x00000000004d6acd <m_config_set_profile+4221>: mov %rcx,%r13 0x00000000004d6ad0 <m_config_set_profile+4224>: mov %r14,-0x8(%rsp) 0x00000000004d6ad5 <m_config_set_profile+4229>: sub $0x68,%rsp 0x00000000004d6ad9 <m_config_set_profile+4233>: test %rdx,%rdx 0x00000000004d6adc <m_config_set_profile+4236>: je 0x4d6cc0 <m_config_set_profile+4720> 0x00000000004d6ae2 <m_config_set_profile+4242>: lea 0x38(%rsp),%rsi 0x00000000004d6ae7 <m_config_set_profile+4247>: mov %rdx,%rdi 0x00000000004d6aea <m_config_set_profile+4250>: callq 0x44f760 <strtod@plt> 0x00000000004d6aef <m_config_set_profile+4255>: mov 0x38(%rsp),%r14 0x00000000004d6af4 <m_config_set_profile+4260>: lds (bad),%edi 0x00000000004d6af5 <m_config_set_profile+4261>: stc 0x00000000004d6af6 <m_config_set_profile+4262>: sub %dl,%al 0x00000000004d6af8 <m_config_set_profile+4264>: movzbl (%r14),%eax 0x00000000004d6afc <m_config_set_profile+4268>: cmp $0x2e,%al 0x00000000004d6afe <m_config_set_profile+4270>: je 0x4d6ba1 <m_config_set_profile+4433> 0x00000000004d6b04 <m_config_set_profile+4276>: jg 0x4d6b70 <m_config_set_profile+4384> 0x00000000004d6b06 <m_config_set_profile+4278>: cmp $0x2c,%al 0x00000000004d6b08 <m_config_set_profile+4280>: je 0x4d6ba1 <m_config_set_profile+4433> 0x00000000004d6b0e <m_config_set_profile+4286>: test %al,%al --- The problem also doesn't reproduce when mplayer is built WITH_DEBUG. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
* Dmitry Marakasov (amdmi3@amdmi3.ru) wrote: > > Can you elaborate a little on your particular setup? > > I build my own mplayer WITH_OTCHAIN and if it died on me on any > > invocation, I believe I would have noticed :-) > > Nothing special except for custom options and CPU to which this may > be related (gcc misdetects cpu or there's bug in optimization specific > to this cpu?). I've digged into it a bit, and seems like, that's problem of both FreeBSD, gcc and mplayer. - gcc detects my processor as corei7-avx, which it actually is - FreeBSD-9.0 doesn't have support for AVX yet (it was committed to HEAD just 2 weeks ago), so avx-enabled code won't work on it - mplayer uses march=native and triggers this While it can and should be fixed in both system and gcc, it's a good example of why ports should not override user-set compiler flags. Another problem is that mplayer will not work on CPUs different to what it was compiled on. Even worse, likely mplayer packages won't run because of it, as they are built with -march=native. I suggest to make mplayer always use system C*FLAGs, never override -march and -mtune, and append -O* -f* options via port only for WITH_OCFLAGS case. -- Dmitry Marakasov . 55B5 0596 FF1E 8D84 5F56 9510 D35A 80DD F9D2 F77D amdmi3@amdmi3.ru ..: jabber: amdmi3@jabber.ru http://www.amdmi3.ru
If you have some time, would you review my last patch and commit in case you agree? Thank you in advance Riggs
State Changed From-To: feedback->closed Superceeded by ports/166946. Closed by maintainers request.