Bug 192583 - multimedia/vdr crashes when not compiled with GCC
Summary: multimedia/vdr crashes when not compiled with GCC
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Many People
Assignee: Juergen Lock
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-11 15:29 UTC by martin.dieringer
Modified: 2014-08-12 19:18 UTC (History)
1 user (show)

See Also:


Attachments
clang/i386 stack alignment patch for testing (1.71 KB, patch)
2014-08-12 18:05 UTC, Juergen Lock
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description martin.dieringer 2014-08-11 15:29:14 UTC
I have to say USE_GCC=yes for vdr, otherwise it crashes right on startup
Comment 1 John Marino freebsd_committer freebsd_triage 2014-08-11 15:50:08 UTC
over to maintainer
Comment 2 Juergen Lock freebsd_committer freebsd_triage 2014-08-11 17:55:34 UTC
Do you actually need USE_GCC=yes, or is USE_GCC=any sufficient?

(vdr doesn't crash here, neither on 9.2 nor on 10.0 and the backtrace in private email didn't tell me the actual cause - so I guess we'll just have to add an USE_GCC that works for you for now.)
Comment 3 martin.dieringer 2014-08-12 14:26:43 UTC
USE_GCC=any compiles with g++47, too, so for me it is sufficient
Comment 4 commit-hook freebsd_committer freebsd_triage 2014-08-12 16:07:41 UTC
A commit references this bug:

Author: nox
Date: Tue Aug 12 16:07:27 UTC 2014
New revision: 364716
URL: http://svnweb.freebsd.org/changeset/ports/364716

Log:
  - Add USE_GCC=any to fix crashes on 10.0 . (which I cannot reproduce tho)
  - Bump PORTREVISION.

  PR:		192583
  Submitted by:	martin.dieringer@gmx.de

Changes:
  head/multimedia/vdr/Makefile
Comment 5 Juergen Lock freebsd_committer freebsd_triage 2014-08-12 16:11:05 UTC
Committed.  Thanks!
Comment 6 Tijl Coosemans freebsd_committer freebsd_triage 2014-08-12 16:13:30 UTC
What architecture is this (output of "uname -m")?
Comment 7 martin.dieringer 2014-08-12 16:16:34 UTC
FreeBSD 10.0-RELEASE-p3 #0: Tue May 13 18:26:10 UTC 2014     root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
Comment 8 Juergen Lock freebsd_committer freebsd_triage 2014-08-12 16:19:04 UTC
You may be onto something...  It didn't crash with clang on 10.0-R/amd64 .
Comment 9 martin.dieringer 2014-08-12 16:23:53 UTC
Doesn't crash on my amd64 machine either AFAIR.
Probably the USE_GCC could be conditional ...
Comment 10 commit-hook freebsd_committer freebsd_triage 2014-08-12 16:48:44 UTC
A commit references this bug:

Author: nox
Date: Tue Aug 12 16:47:48 UTC 2014
New revision: 364721
URL: http://svnweb.freebsd.org/changeset/ports/364721

Log:
  - Turns out the 10.0-R clang crashes I couldn't reproduce (on amd64) were
    in fact on i386 - since this was the first report I got of this kind
    (and I don't have an i386 box anymore myself) let's assume it's an
    i386 issue.  So change the USE_GCC=any to be i386-only.
  - Bump PORTREVISION.

  PR:		192583

Changes:
  head/multimedia/vdr/Makefile
Comment 11 Tijl Coosemans freebsd_committer freebsd_triage 2014-08-12 17:02:44 UTC
You should take a look at multimedia/gstreamer1-libav/Makefile.  It adds "-mstack-alignment=16 -mstackrealign" to CFLAGS for clang && i386.  This realigns the stack on a 16 byte boundary when calling a function.  Some asm code that uses SSE instructions relies on that.
Comment 12 Juergen Lock freebsd_committer freebsd_triage 2014-08-12 18:05:58 UTC
Created attachment 145727 [details]
clang/i386 stack alignment patch for testing

Can you test this patch if it also fixes the crashes?  And if it does rebuild all your plugins since they (may) inherit these changed C{,XX}FLAGS and then see if everything still runs?

Thanx!
Juergen
Comment 13 martin.dieringer 2014-08-12 18:58:16 UTC
Unfortunately not. PORTREVISION 6 is ok, 7 crashes.

I recompiled all plugins too (with clang...)
Comment 14 Juergen Lock freebsd_committer freebsd_triage 2014-08-12 19:18:43 UTC
Ok then I fear the USE_GCC will have to stay for i386.

Thanx for testing!
Juergen