Bug 199488
| Summary: | audio/openal-soft: Broken with clang | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dmitry Marakasov <amdmi3> | ||||||||
| Component: | Individual Port(s) | Assignee: | Marcus von Appen <mva> | ||||||||
| Status: | Closed FIXED | ||||||||||
| Severity: | Affects Many People | CC: | avos, danilo, maciej, mva, ohartmann | ||||||||
| Priority: | --- | Keywords: | easy, needs-qa, patch | ||||||||
| Version: | Latest | Flags: | bugzilla:
maintainer-feedback?
(mva) |
||||||||
| Hardware: | Any | ||||||||||
| OS: | Any | ||||||||||
| Bug Depends on: | |||||||||||
| Bug Blocks: | 203818 | ||||||||||
| Attachments: |
|
||||||||||
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?
> 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. (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)? (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. Also, sound works when alBuffer.c is compiled with -O1. (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. 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. Created attachment 161340 [details]
openal-soft patch
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 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. 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 Created attachment 162128 [details]
openal-soft workaround
Can you try to build openal-soft with the "openal-soft workaround" patch and run warzone2100, please? It's fixes the problem here. The last patch obviously fixed the problem (at least for me). 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 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 Assuming fixed |
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