Sorry, what stops working in optimized mode? I still see the app being launched and the information about the test file printed.

Comment by Lincoln Law (JIRA)

Except none optimization mode, it'll play the music, you can hear.
-O / -OSize will cause cpu to 100% because decode function is stall or not make any sound.
You can switch optimization mode to test it

Comment by Lincoln Law (JIRA)

-O will output no sound.
-OSize will cause CPU 100%
none just work fine

picture for -OSize

Ah, I didn't realize the only difference was the sound, and I didn't realize you'd set the default mode to -Onone in both Debug and Release in the APlay framework target. I can reproduce the difference now.

@swift-ci create

I investigated this a bit and found that there is no optimizer problem here. The only difference between a good and bad version is a minor difference in stack layout which should not have any impact.

I also did run the attached sample program with the address sanitizer. It reports a heap buffer overflow when dealing with C-strings (in StreamProvider.URLInfo.localFileHit).
I suggest to fix that first. And then if there is still a problem with -Onone vs -O, please let us know.

Comment by Lincoln Law (JIRA)

TestDemo-Fixed-localfileHint.zip

Hi Erik, I fixed (StreamProvider.URLInfo.localFileHit) with address sanitizer in -OSize, but still got error

The new ASAN crash is still a bug in your code. You are taking an unsafe pointer from a swift UInt8 array without keeping the array alive.

Comment by Lincoln Law (JIRA)

Hi Erik, that is the point why I file the radar. No crash at -Onone but -OSize

The problem here is that by not keeping the array alive, you are running into undefined behavior. That means it can work in one optimization level but not in another optimization level.
In this concrete example, the optimizer shrinks the lifetime of the object, which is a valid optimization.
If you are working with unsafe pointers you have to explicitly make sure that the referenced data is kept alive.

Comment by Lincoln Law (JIRA)

Ok, thanks Erik, I'll check my code later. Thanks for all.

Comment by Lincoln Law (JIRA)

Hi Erik, fixed array life time issue, but still got cpu 100% using in -OSize mode, not in -Onone mode

TestDemo-V3.zip

Comment by Lincoln Law (JIRA)

@eeckstein,@belkadan Any Help?

There are other problems in the source code, which I found just by inspection. For example, there is no explicit lifetime handling for bufferConverter in decodeloopHandler(). It is passed as unsafe pointer to the callback (Why this is not reported by ASAN is a different question).

Also, even with -Onone, but with ASAN enabled I get the wrong behavior. I don't see a compiler problem here.

lincolnlaw (JIRA User), Did you figure out what the problem was? Should we mark this issue as resolved?

Comment by Lincoln Law (JIRA)

The function `AudioConverterFillComplexBuffer(converter, AudioBufferConverter.callback(), userinfo, &ioOutputDataPackets, &outputBufferList, nil)`
inside callback `AudioConverterComplexInputDataProc` will trigger twice or more in release mode but once in debug mode
what I mean trigger is when I return once, it'll not exit this callack, but still using this callback to retrieve more data.