Bug 199799 - multimedia/libx264: Core dump when compiled on i386 with clang (on 10.1)
Summary: multimedia/libx264: Core dump when compiled on i386 with clang (on 10.1)
Status: Closed Feedback Timeout
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Only Me
Assignee: Walter Schwarzenfeld
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2015-04-30 07:35 UTC by marcinkk
Modified: 2019-08-13 23:10 UTC (History)
2 users (show)

See Also:
koobs: maintainer-feedback+


Attachments
gdb output (5.99 KB, text/plain)
2015-09-25 03:50 UTC, Paul
no flags Details
gdb from run (26.56 KB, text/plain)
2015-09-29 15:47 UTC, marcinkk
no flags Details
gdb from core (26.38 KB, text/plain)
2015-09-29 15:48 UTC, marcinkk
no flags Details
gdb output from run built with clang (17.78 KB, text/plain)
2015-10-03 14:48 UTC, Paul
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description marcinkk 2015-04-30 07:35:28 UTC
After upgrading my FreeBSD i386 9.1 to 10.1 and rebuilding ports I received "Bus error (core dumped)" when trying to encode mkv with ffmpeg using libx264. The only working solution I found was recompilation of the multimedia/libx264 port with "Use current GCC" option enabled.

I don't know if it is the problem of i386 version only (the solution was inspired by this message: http://lists.freebsd.org/pipermail/freebsd-toolchain/2013-September/001032.html). Maybe the problem can by repaired in the other way.
Comment 1 Kubilay Kocak freebsd_committer freebsd_triage 2015-07-05 13:21:05 UTC
Hi Marcin, is this still an issue for you?

I've recently updated the x264 port to the latest stable upstream version, so if the issue is still reproducible, please test with that version and report back
Comment 2 marcinkk 2015-07-08 10:31:30 UTC
libx264-0.144.2533 - the same problem

default compiler, broken library:
# gcc --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.1
Thread model: posix

compiled with gcc48 works fine with ffmpeg:
# gcc48 --version
gcc48 (FreeBSD Ports Collection) 4.8.4
Copyright (C) 2013 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Comment 3 Kubilay Kocak freebsd_committer freebsd_triage 2015-07-09 08:03:15 UTC
Thanks Marcin,

Does the segfault still occur if the DEBUG option is enabled? If not, can you please include (as an attachment) a backtrace of the core file after rebuilding libx264 with the DEBUG option enabled please
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2015-07-09 08:12:59 UTC
Also Marcin, if you could provide us with the smallest test case possible, it will help us with reproduction and isolation of the issue.

I'm interested in:

* The exact command you ran that results in a segfault
* Possibly a sample of the video source you're attempting to encode (unless it happens with many/all formats)
* Q: Do other commands or combinations of encoder arguments segfault too? See if  you can narrow down the set of variables
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2015-07-09 08:13:39 UTC
Please add any large logs or output as attachments, rather than inline as comments
Comment 6 marcinkk 2015-07-10 16:12:41 UTC
In the bug report I wrote "I don't know if it is the problem of i386 version only", and I made some more tests on i386 and on amd64. On amd64 machine everything is ok, when libx264 is compiled on i386 with clang ffmpeg dumps core.

Pack for test: http://misiak.mini.net.pl/~marcinkk/bugzilla/bug-pack.tar.xz (about 40MB).

In the pack: exapmle recording (the problem exist on any TS file I tried), core file and logs (from x86 and amd64 with libx264 compiled with clang and with gcc) from the command (included in the pack as a shell script):
ffmpeg -report -i recording.ts -map 0:0 -map 0:1 recording.mkv

In most cases the problem can be repeated with simple command:
ffmpeg -i recording.ts recording.mkv
Comment 7 Paul 2015-09-25 03:50:42 UTC
Created attachment 161367 [details]
gdb output
Comment 8 Paul 2015-09-25 03:52:46 UTC
I am experiencing SIGBUS on 10.2-p3 on i386 called through ffmpeg 2.8. Reproducible with every mp4 file I tried with ffmpeg -i sample2.mp4 sample2.mp4. See attachment for more information.
Comment 9 Kubilay Kocak freebsd_committer freebsd_triage 2015-09-28 13:51:12 UTC
Paul, I've spoken with x264/ffmpeg upstream people and that have requested gdb information including the output from the 'disassamble' and 'info all-registers' commands.

Can you please include that information in this issue as an attachment please.
Comment 10 Kubilay Kocak freebsd_committer freebsd_triage 2015-09-28 13:52:05 UTC
Marcin, can you please provide the same information as per my comment 9, incluting 'bt'
Comment 11 Kubilay Kocak freebsd_committer freebsd_triage 2015-09-28 13:55:56 UTC
Can you both (paul, marcin) please also include the output of the following:

 * uname -a
 * clang --version

Paul, can you please confirm whether or not your issue is *only* reproducible with a clang build of x264 on FreeBSD 10.1 i386, and if not, the details of your system/build.

If your issue is unrelated, we should track it separately.
Comment 12 marcinkk 2015-09-29 15:47:44 UTC
Created attachment 161530 [details]
gdb from run
Comment 13 marcinkk 2015-09-29 15:48:08 UTC
Created attachment 161531 [details]
gdb from core
Comment 14 marcinkk 2015-09-29 15:52:01 UTC
Attached two files generated in gdb. I hope you requested something like that...

% uname -a
FreeBSD misio-szary 10.1-RELEASE-p5 FreeBSD 10.1-RELEASE-p5 #5 r278310: Sat Feb  7 06:45:00 CET 2015     marcinkk@misio-szary:/usr/obj/usr/src/sys/MISIO  i386

% clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.1
Thread model: posix
Comment 15 marcinkk 2015-09-29 16:10:37 UTC
PS. In gdb output can be read:

Reading symbols from /usr/local/lib/libfftw3f.so.3...Error while reading shared library symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module /usr/local/lib/libfftw3f.so.3]

I've checked the port and this lib was gompiled with gcc48. And it can't be changed. Probably unimportant, but maybe...
Comment 16 Paul 2015-10-03 14:46:58 UTC
I am running 10.2-RELEASE-p5 i386. I have compiled libx264 with clange 3.4.1 and gcc 4.8.5 and have gotten a SIGBUS compiled both ways. I am building from current ports with ffmpeg 2.8 and libx264 0.144.2533. I can open a different bug if that is preferred. I have also attached the requested gdb output.

> freebsd-version
10.2-RELEASE-p5
>uname -a 
FreeBSD web 10.2-RELEASE FreeBSD 10.2-RELEASE #0 r286666: Wed Aug 12 19:31:38 UTC 2015     root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC  i386
> clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: i386-unknown-freebsd10.2
Thread model: posix
Comment 17 Paul 2015-10-03 14:48:36 UTC
Created attachment 161679 [details]
gdb output from run built with clang
Comment 18 Walter Schwarzenfeld freebsd_triage 2018-01-12 23:48:54 UTC
I think this is overcome by events.