SVN 11858 seems to be dying (the last SVN I tried was about a week ago). I'll start a campaign, load up on Produce, undock, fly to Serenity and I'll hit d. I will apparently dock and I see the inside of the hangar for about .5 seconds. At that point, VS segfaults. I'm including the last bits of stdout/stderr below.
Strangely, if I just launch, turn around, land at Atlantis, then pick up the cargo and head off to Serenity, there's no crash when I land.
Any chance that you could run it in gdb: at the prompt type:
gdb ./vegastrike
Then, at the (gdb) prompt type "run"
When it crashes type "backtrace full" and post the output.
ace123 wrote:Any chance that you could run it in gdb: at the prompt type:
gdb ./vegastrike
Then, at the (gdb) prompt type "run"
When it crashes type "backtrace full" and post the output.
For some reason, it's not crashing now. Unless the passage of time has something to do with it, there seems to be nothing wrong.
I found when it's crashing. In the scenario in the parent post, it's crashing when I move my mouse over the trade center area in the hangar. The requested backtrace is as follows:
(gdb) backtrace full
#0 0x0177e4b8 in OALSource::PrepBufferQueueForPlayback ()
No symbol table info available.
#1 0x0177e61b in OALSource::Play ()
No symbol table info available.
#2 0x0177ec0d in OALSource::DoPostRender ()
No symbol table info available.
#3 0x95c3528d in AudioUnitGraph::HandleRenderNotify ()
No symbol table info available.
#4 0x95c3555b in AudioUnitGraph::GraphRenderCallback_NEW ()
No symbol table info available.
#5 0x7000608d in dyld_stub_vsprintf ()
No symbol table info available.
#6 0x70011c67 in AUGenericOutputEntry ()
No symbol table info available.
#7 0x92fa2fe3 in HP_IOProc::Call ()
No symbol table info available.
#8 0x92fa2cd4 in IOA_Device::CallIOProcs ()
No symbol table info available.
#9 0x92fa2bb0 in HP_IOThread::PerformIO ()
No symbol table info available.
#10 0x92fa0f8b in HP_IOThread::WorkLoop ()
No symbol table info available.
#11 0x92fa0aaf in HP_IOThread::ThreadEntry ()
No symbol table info available.
#12 0x92f91304 in CAPThread::Entry ()
No symbol table info available.
#13 0x90034c55 in _pthread_start ()
No symbol table info available.
#14 0x90034b12 in thread_start ()
No symbol table info available.
Aha! That's right, you need the version of OpenAL with the "Warming the Buffers" loop removed. Apple had put in some busy-wait hack to make a crash unlikely but without fixing the crash altogether.
But I think you have to replace Apple's broken version with the compiled source version from OpenAL.
I'll have to talk to HellcatV to ask how he compiled it.
ace123 wrote:Aha! That's right, you need the version of OpenAL with the "Warming the Buffers" loop removed. Apple had put in some busy-wait hack to make a crash unlikely but without fixing the crash altogether.
But I think you have to replace Apple's broken version with the compiled source version from OpenAL.
I'll have to talk to HellcatV to ask how he compiled it.
I'll try to figure it out. In the interim, I'd like to file a bug report with Apple (undoubtedly a duplicate). Any ideas on how I'd describe it to them?
I don't think they care or are going to do anything about it.
Apple seems to make things hard for developers because most of their users are "normal" users.
I've seen a lot of things where a cross-platform solution doesn't work correctly because of a bug and you have to rewrite everything to use the Apple-only solution.
Still I guess it's worth a try. You can say that their OpenAL library comes with a race condition that causes it to crash infrequently.
ace123 wrote:I don't think they care or are going to do anything about it.
Apple seems to make things hard for developers because most of their users are "normal" users.
I've seen a lot of things where a cross-platform solution doesn't work correctly because of a bug and you have to rewrite everything to use the Apple-only solution.
Still I guess it's worth a try. You can say that their OpenAL library comes with a race condition that causes it to crash infrequently.
Well, they seem to be interested as they asked for my CrashReporter logs. Do you happen to know where in the code the race condition is?
// WARM THE BUFFERS
// when playing, touch all the audio data in memory once before it is needed in the render proc (RealTime thread)
{
volatile UInt32 X;
UInt32 *start = (UInt32 *)buffer->mBuffer->GetDataPtr();
UInt32 *end = (UInt32 *)(buffer->mBuffer->GetDataPtr() + (buffer->mBuffer->GetDataSize() &0xFFFFFFFC));
while (start < end)
{
X = *start;
start += 1024;
}
}
If you comment out with /* ... */ that entire block of code the crashes will happen just about every single time.
And that loop does nothing. It literally reads memory, wastes time, and throws it away again.
The solution was to somehow build the OpenAL library using the "sdl" backend so it pipes through vegastrike's SDL library, and that is supposed to fix the problem.
I'm not 100% sure on how this works... I'll try to figure it out if I get more time... if you want to ask the Apple devs, tell them about commenting out that segment of source code causing the error almost 100% of the time, versus not commenting out that segment.