11858 Crashing on OS X at docking

Find any bugs in Vega Strike? See if someone has already found it, or report them here!
Post Reply
daveesq
Explorer
Explorer
Posts: 13
Joined: Mon Feb 11, 2008 3:16 am

11858 Crashing on OS X at docking

Post by daveesq »

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 thoughts?

Code: Select all

Processing News
 +++ m/campaign_lib.py:1550: *** Get the fixers to display!!!
 +++ m/campaign_lib.py:1506: there are 1 campagins
 +++ m/campaign_lib.py:1038: *** getting current node
 +++ m/campaign_lib.py:1053: *** read stuff from savegame
 +++ m/campaign_lib.py:1059: *** :-) ***
 +++ m/campaign_lib.py:1060: []
 +++ m/campaign_lib.py:68: System: ['Crucible', 'Cephid_17']==?==['crucible', 'cephid_17']
 +++ m/campaign_lib.py:76: *** Test if docked to: atlantis
 +++ m/campaign_lib.py:93: *** insystem return false!!
 +++ m/campaign_lib.py:1068: *** no contingency!
<campaign_lib.CampaignClickNode instance at 0x1c1e7378>
[]
*** still no contingency
 +++ m/campaign_lib.py:1515: *** no active node for vega_strike_campaign
 +++ m/campaign_lib.py:1519: *** No node
 +++ m/campaign_lib.py:1532: []
2008-02-18 12:18:47.205 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x2b0f7a80 of class NSCFArray autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x96390a3b 0x963f5ae4 0x963f5a8e 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.216 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x14d3e200 of class NSCFString autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x9638b72b 0x951f15fa 0x95180c8d 0x9518100d 0x936f0f6b 0x96389455 0x963f5b69 0x963f5a8e 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.217 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x192c6d0 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x9638950a 0x963f5b69 0x963f5a8e 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.219 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x14d94120 of class NSCFDictionary autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x9526641e 0x96389532 0x963f5b69 0x963f5a8e 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.220 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x1928ab0 of class NSCFNumber autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x9638950a 0x963f5bc6 0x963f5a8e 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.221 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x14d9a7a0 of class NSCFDictionary autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x9526641e 0x96389532 0x963f5bc6 0x963f5a8e 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.222 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x1e536390 of class NSCFArray autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x963f60b6 0x963f5e1c 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.223 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x2e5cac10 of class NSCFArray autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x96390a3b 0x963f5f35 0x964658b4 0x96451c92 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.224 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x30897bf0 of class NSCFArray autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x9525ee55 0x9372f83b 0x963f8c94 0x96451d1f 0x964510d8 0x964657cd 0x964a7091 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
2008-02-18 12:18:47.234 vegastrike[382:7803] *** _NSAutoreleaseNoPool(): Object 0x14d34150 of class SDL_QuartzWindow autoreleased with no pool in place - just leaking
Stack: (0x937dc12f 0x936e8ec2 0x964a70f4 0x16b236a 0x16b2f27 0x16a9feb 0x167d935 0x167d9f2 0x167e00f 0x900705eb 0xffffffff 0x177e61b 0x177ec0d 0x95c3528d 0x95c3555b 0x7000608d 0x70011c67 0x92fa2fe3 0x92fa2cd4 0x92fa2bb0 0x92fa0f8b 0x92fa0aaf 0x92f91304 0x90034c55 0x90034b12)
zsh: segmentation fault  ./vegastrike
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

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.
daveesq
Explorer
Explorer
Posts: 13
Joined: Mon Feb 11, 2008 3:16 am

Post by daveesq »

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.

Dunno...
daveesq
Explorer
Explorer
Posts: 13
Joined: Mon Feb 11, 2008 3:16 am

Post by daveesq »

Never mind.

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:

Code: Select all

(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.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

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.
daveesq
Explorer
Explorer
Posts: 13
Joined: Mon Feb 11, 2008 3:16 am

Post by daveesq »

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?
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Post by loki1950 »

@daveesq have a look at HellcatV blog entry where he describes his troubles getting a Mac build. the dev blog link on the front page.

Enjoy thee Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

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.
daveesq
Explorer
Explorer
Posts: 13
Joined: Mon Feb 11, 2008 3:16 am

Post by daveesq »

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?
daveesq
Explorer
Explorer
Posts: 13
Joined: Mon Feb 11, 2008 3:16 am

Post by daveesq »

Could anyone post a bit of code that would cause OpenAL to freak out and die 100% of the time?
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Post by ace123 »

http://www.openal.org/repos/openal/trun ... Source.cpp

See this section (search for "warm the buffers"):

Code: Select all

	// 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.
Post Reply