Bug 199488 - audio/openal-soft: Broken with clang
Summary: audio/openal-soft: Broken with clang
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Marcus von Appen
URL:
Keywords: easy, needs-qa, patch
Depends on:
Blocks: 203818
  Show dependency treegraph
 
Reported: 2015-04-16 21:48 UTC by Dmitry Marakasov
Modified: 2015-11-23 20:30 UTC (History)
5 users (show)

See Also:
bugzilla: maintainer-feedback? (mva)


Attachments
Patch (523 bytes, patch)
2015-04-16 21:48 UTC, Dmitry Marakasov
mva: maintainer-approval-
Details | Diff
openal-soft patch (923 bytes, patch)
2015-09-24 14:02 UTC, Danilo Egea Gondolfo
no flags Details | Diff
openal-soft workaround (1.21 KB, patch)
2015-10-16 16:42 UTC, Danilo Egea Gondolfo
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dmitry Marakasov freebsd_committer 2015-04-16 21:48:55 UTC
Created attachment 155652 [details]
Patch

Switch audio/openal-soft to GCC as it's miscompiled by clang: all applications using openal experience corrupted sound.

FreeBSD 11.0-CURRENT #0 r280307 amd64
Comment 1 Marcus von Appen freebsd_committer freebsd_triage 2015-04-21 06:11:31 UTC
Comment on attachment 155652 [details]
Patch

Switching to GCC just because the current HEAD clang miscompiles is nothing, I'd favour. I'd like to have that properly fixed instead. Can you provide me more information about how the sound is corrupted?
Comment 2 Dmitry Marakasov freebsd_committer 2015-04-24 19:36:58 UTC
> Switching to GCC just because the current HEAD clang miscompiles is nothing, I'd favour.

I've panicked since I thought this affects release freebsd versions, but it seems to actually only apply to clang36 or current.

> I'd like to have that properly fixed instead.

Well this is tricky. I've spend 2 nights already with no real result. I've tried openal git master and it doesn't have the problem. I've tried to bisect and then minimize changes, and found the following:

there're two functions, DecomposeUserFormat and DecomposeFormat in OpenAL32/alBuffer.c. Each of these contains static array of simple structs. The problem is fixed if both these arrays are appended 2 entries. You can just duplicate last existing entries, which should not affect any logic, which suggests that the problem is probably accessing some uninitialized value in data section, offset to which is affected by these arrays size. I plan to try valgrind.

> Can you provide me more information about how the sound is corrupted?

Well, it resembles original sound a bit, with scratches added.
Comment 3 Marcus von Appen freebsd_committer freebsd_triage 2015-05-18 13:37:33 UTC
(In reply to Dmitry Marakasov from comment #2)

[...]
> > I'd like to have that properly fixed instead.
> 
> Well this is tricky. I've spend 2 nights already with no real result. I've
> tried openal git master and it doesn't have the problem. I've tried to
> bisect and then minimize changes, and found the following:
> 
> there're two functions, DecomposeUserFormat and DecomposeFormat in
> OpenAL32/alBuffer.c. Each of these contains static array of simple structs.
> The problem is fixed if both these arrays are appended 2 entries. You can
> just duplicate last existing entries, which should not affect any logic,
> which suggests that the problem is probably accessing some uninitialized
> value in data section, offset to which is affected by these arrays size. I
> plan to try valgrind.

This sounds to me like a too aggressive optimization or an issue with clang 3.6 and getting array boundaries right. What I'd love to see is the difference between the code generated from clang 3.4 and clang 3.6.

alBuffer.c does not seem to have changed heavily regarding the struct definitions themselves, but only the amount of entries within them, so I would not assume it to be the culprit.

Is the sound corrupted, if you compile openal-soft with clang 3.4 on HEAD (just, if you are able to do so)?
Comment 4 Andriy Voskoboinyk freebsd_committer 2015-07-03 20:00:47 UTC
(In reply to Marcus von Appen from comment #3)
On r284163 (amd64):
clang 3.4, 3.5 - sound is ok.
clang 3.6, clang-devel - sound is corrupted.
Comment 5 Andriy Voskoboinyk freebsd_committer 2015-07-03 20:09:58 UTC
Also, sound works when alBuffer.c is compiled with -O1.
Comment 6 Dmitry Marakasov freebsd_committer 2015-07-10 14:15:19 UTC
(In reply to Marcus von Appen from comment #3)

> This sounds to me like a too aggressive optimization or an issue with clang
> 3.6 and getting array boundaries right. What I'd love to see is the
> difference between the code generated from clang 3.4 and clang 3.6.

There's no such thing as `too aggressive optimization'. It's code problem in either openal or compiler which should be fixed.

> alBuffer.c does not seem to have changed heavily regarding the struct
> definitions themselves, but only the amount of entries within them, so I
> would not assume it to be the culprit.
> 
> Is the sound corrupted, if you compile openal-soft with clang 3.4 on HEAD
> (just, if you are able to do so)?

Just wanted to note that now (since the last time I thing I've updated HEAD couple of times) it doesn't corrupt sound but segfault instead, so maybe it'll be easier to debug. Will try to give it some investigation after the weekend, will also try other clang versions.
Comment 7 Danilo Egea Gondolfo freebsd_committer 2015-09-24 14:01:39 UTC
Hmmmm, I've had the same problem. I'm updating games/solarus and it's crashing due this problem. I've "fixed" this with the attached patch.
Comment 8 Danilo Egea Gondolfo freebsd_committer 2015-09-24 14:02:12 UTC
Created attachment 161340 [details]
openal-soft patch
Comment 9 Danilo Egea Gondolfo freebsd_committer 2015-09-24 14:04:04 UTC
I've reported this to the openal-soft maintainer [1]. I don't know why, but the development version just works fine.


[1] - https://github.com/kcat/openal-soft/issues/18
Comment 10 Danilo Egea Gondolfo freebsd_committer 2015-10-13 23:50:49 UTC
Are you still having problems with openal-soft + clang? I'd like to add the attached patch to openal-soft. Do you have any comment? I'm depending on it to update games/solarus, which is crashing too.
Comment 11 O. Hartmann 2015-10-16 15:35:12 UTC
I see the problem with corrupted sound using openal-soft also with port games/warzone2100.

In my case, I'm on CURRENT (FreeBSD 11.0-CURRENT #5 r289369: Thu Oct 15 18:43:55 CEST 2015) and it is CLANG 3.7.0 with the AVX patch. The problem is persistent since a couple of months for now.
See Bug 203818
Comment 12 Danilo Egea Gondolfo freebsd_committer 2015-10-16 16:42:41 UTC
Created attachment 162128 [details]
openal-soft workaround
Comment 13 Danilo Egea Gondolfo freebsd_committer 2015-10-16 16:44:23 UTC
Can you try to build openal-soft with the "openal-soft workaround" patch and run warzone2100, please? It's fixes the problem here.
Comment 14 O. Hartmann 2015-10-16 18:52:12 UTC
The last patch obviously fixed the problem (at least for me).
Comment 15 commit-hook freebsd_committer 2015-10-17 16:33:22 UTC
A commit references this bug:

Author: danilo
Date: Sat Oct 17 16:32:53 UTC 2015
New revision: 399540
URL: https://svnweb.freebsd.org/changeset/ports/399540

Log:
  - Add a workaround for a problem caused by clang

  For some reason clang is breaking the code when openal-soft is built with
  optimizations. If the file alBuffer.c is built with -O1 the problem don't
  happens. See https://github.com/kcat/openal-soft/issues/18
  The problem seems to happen just on CURRENT due the clang version.

  PR:		199488, 203818
  Tested by:	ohartman@zedat.fu-berlin.de
  Approved by:	mva
  MFH:		2015Q4

Changes:
  head/audio/openal-soft/Makefile
  head/audio/openal-soft/files/patch-OpenAL32_alBuffer.c
Comment 16 commit-hook freebsd_committer 2015-10-19 14:23:17 UTC
A commit references this bug:

Author: danilo
Date: Mon Oct 19 14:22:46 UTC 2015
New revision: 399683
URL: https://svnweb.freebsd.org/changeset/ports/399683

Log:
  MFH: r399540

  - Add a workaround for a problem caused by clang

  For some reason clang is breaking the code when openal-soft is built with
  optimizations. If the file alBuffer.c is built with -O1 the problem don't
  happens. See https://github.com/kcat/openal-soft/issues/18
  The problem seems to happen just on CURRENT due the clang version.

  PR:		199488, 203818
  Tested by:	ohartman@zedat.fu-berlin.de
  Approved by:	mva
  Approved by:	ports-secteam (feld)

Changes:
_U  branches/2015Q4/
  branches/2015Q4/audio/openal-soft/Makefile
  branches/2015Q4/audio/openal-soft/files/patch-OpenAL32_alBuffer.c
Comment 17 Dmitry Marakasov freebsd_committer 2015-11-23 20:30:16 UTC
Assuming fixed