Error (EXC_BAD_ACCESS) in Garbage collector (IOS)

Monkey Forums/Monkey Bug Reports/Error (EXC_BAD_ACCESS) in Garbage collector (IOS)

Timotron

(Posted 2014) [#1]

We have been having some random crashing issues on IOS devices, I was able to get this crash while testing in the emulator.

*** error reported ****
Thread 1: EXC_BAD_ACCESS (code=2, address=0x8)

**** error location ****

void gc_flush_free( int size ){

	int t=gc_free_bytes-size;
	if( t<0 ) t=0;
	
	while( gc_free_bytes>t ){
		gc_object *p=gc_free_list.succ;
		if( !p || p==&gc_free_list ){
//			printf("ERROR:p=%p gc_free_bytes=%i\n",p,gc_free_bytes);
//			fflush(stdout);
			gc_free_bytes=0;
			break;
		}
		GC_REMOVE_NODE(p);  //<---- CRASHED HERE ***********************
		delete p;	//...to gc_free
	}
}

**** For reference ****

#define GC_REMOVE_NODE( NODE ){\
(NODE)->pred->succ=(NODE)->succ;\
(NODE)->succ->pred=(NODE)->pred;}

***** this is what the variable "p" reported as its memory at the time of the crash ****
succ gc_object * NULL 0x00000000
pred gc_object * 0x65b548 0x0065b548
flags int 0 0

AdamRedwoods

(Posted 2014) [#2]

are you using GC_MODE=2?
if not, disregard:
http://monkeycoder.co.nz/Community/posts.php?topic=7682

dawlane

(Posted 2014) [#3]

If I remember, a bad access error can occur if you have a variable that holds a reference to an object in a list/map and you try and access that object via that variable after the object has been removed.

Edit: You have not mentioned which version of Monkey or which version of iOS.

marksibly

(Posted 2014) [#4]

Is it possible for you to create a runnable sample app that exhibits the problem?

Timotron

(Posted 2014) [#5]

Notes
> Xcode 5.0
> Monkey 78a
> We are not using GC_MODE=2

Mark

I do not have a small repro app atm, we have a large engine and project base atm (main.mm in release mode is 90,000 lines long atm).

It does seem to have something to do with asynch loading images via htttp, Note: I can make it happen faster by loading, discarding and reloading asynch loaded the same images over http (in this case facebook user images)

I will attempt to get a smaller app that reproduces the issue, as I get the time to look deeper into it.

Tim

malick

(Posted 2014) [#6]

@Mark - I get a GC related error just compiling the Admob example code for iOS. Not sure if it's the exact same error these folks are seeing, but maybe it's related.

marksibly

(Posted 2014) [#7]

> @Mark - I get a GC related error just compiling the Admob example code for iOS.

I've run this example many times without problem - what version of Monkey are you using? What ios device? Anyone else having this problem?

malick

(Posted 2014) [#8]

It was on 77f. It works now that I've updated to 78c. It was on any iPhone in the simulator, or on an iPhone 4/4S. Didn't try any others.

marksibly

(Posted 2014) [#9]

> It was on 77f. It works now that I've updated to 78c

77f is working fine here too.

How many times did you have to run the code for it to crash? Did it happen everytime? Or frequently/infrequently?

malick

(Posted 2014) [#10]

It was every time. I'm on OS X 10.9.2 on a 2013 MacBook Air, if that helps.

Timotron

(Posted 2014) [#11]

Mark here is an example that will cause crashes (Note this is an extreme example, that abuses the asynch load)

Changing the number of images loaded per update and making it cause loads every update or only reload after loading changes the time till a crash occurs. But it will always crash eventually.

We presume that eventually it would always crash due to memory, but this point seems to be reached at dramatically different counts depending on the settings here.

Import mojo

'********************************************************************************************************************************************
Function Main()
	Crash_Test.Create()
End

'********************************************************************************************************************************************
Class Crash_Test Extends App
	Global instance:Crash_Test
	
	Field testImages:= New List<TestImage>
	Field loadCount:int
	
	Const IMAGES_TO_LOAD_PER_UPDATE 	= 1		
	Const RELOAD_EVERY_UPDATE:Bool 		= True
	
	'--------------------------------------------------------------------------------
	Function Create()
		instance = New Crash_Test()
	End
	
	'--------------------------------------------------------------------------------
	Method OnUpdate()
		'add new test images
		For Local i= 0 Until IMAGES_TO_LOAD_PER_UPDATE
			testImages.AddFirst(New TestImage( 200 + Rnd(200), 100 + Rnd(200)))
		Next
		
		'update test images
		For Local image:= Eachin testImages
			image.Update()
		Next
		
		'updates asynch events
		UpdateAsyncEvents()
	End

	'--------------------------------------------------------------------------------
	Method OnRender()
		'background
		SetColor(0, 0, 0)
		DrawRect(0, 0, DeviceWidth, DeviceHeight)
		SetColor(255, 255, 255)
		
		'draw images
		For Local image:= Eachin testImages
			image.Render()
		Next
		
		'image count
		DrawText("ImageCount: "+testImages.Count(), 0, 200)
		DrawText("LoadCount:  "+loadCount, 0, 220)
	End

	'--------------------------------------------------------------------------------
	Function IncrementLoadCount()
		If instance 	instance.loadCount += 1
	End

End

'********************************************************************************************************************************************
Class TestImage Implements IOnLoadImageComplete
	Global testNames:String[] = ["token_apple", "token_brain", "token_bucket", "token_crate", "token_defense", "token_energy_cell", "token_icecube", "token_iron", "token_luck", "token_melee", "token_rock", "token_rope", "token_speed", "token_star", "token_spitbal", "token_stone", "token_wood"]
	
	Field testImage:Image
	Field x:Float
	Field y:Float
	Field reload:Bool
	
	'--------------------------------------------------------------------------------
	Method New(x:Float, y:Float)
		Self.x = x
		Self.y = y
		reload = true
	End
	
	'--------------------------------------------------------------------------------
	Method Update()
		If reload
			'discard image
			If testImage
				testImage.Discard()
				testImage = Null
			End
				
			'asynch load image
			Local i:Int = Rnd(testNames.Length)
			LoadImageAsync("https://closet-hero.appspot.com/data/art/"+testNames[i]+".png", , , Self)
			
			'increment counts and set reload state
			Crash_Test.IncrementLoadCount()
			reload = Crash_Test.RELOAD_EVERY_UPDATE
		End
	End
	
	'--------------------------------------------------------------------------------
	Method Render()
		If testImage
			DrawImage(testImage, x, y)
		End
	End
	
	'--------------------------------------------------------------------------------
	Method OnLoadImageComplete:Void(image:Image, path:String, source:IAsyncEventSource)
		'just in case we have not updated yet, discard the image if we have one
		If testImage
			testImage.Discard()
			testImage = Null
		End
		
		'set our image and reload state		
	 	testImage = image
	 	reload = True
	End
End

marksibly

(Posted 2014) [#12]

> Mark here is an example that will cause crashes (Note this is an extreme example, that abuses the asynch load)

Ok, I can't reproduce the gc error, but I did discover a 'thread leak' which may be related. Fix will be out soon.

I built with monkey77f/xcode 5.1 and left it running on an iPad1 for about 20 mins. It eventually 'stalled' due to the thread leak issue but didn't crash. Anything else I should try?

One thing to note is that Monkey currently lets you create as many threads as you want - your example above creates 60 a second! I will probably write some kind of 'throttling' code to deal with this eventually, but for now apps should try and keep threads use to a 'reasonable' level - I could get 1000 going on ios, but I think 100 max is probably preferable.

And I still can't reproduce the 77f admob issue...anyone else?

Timotron

(Posted 2014) [#13]

We will retest with the next version with the thread leak fix, and the latest version of Xcode.

Thank you for your time Mark.

Tim

Timotron

(Posted 2014) [#14]

One question Mark. Why did you compile in 77f? Malicks bug is separate from mine.

We are using 78a atm. (not sure if it changes anything)

Tim

marksibly

(Posted 2014) [#15]

Please try v78d!

Nobuyuki

(Posted 2014) [#16]

I wonder if 78d will also fix the bugs in my async atlas loader. That sucker crashed 80% of the time guaranteed on a big project, but would never crash in isolated examples. If it didn't cause a hard crash, it would often leave a mess in memory that would cause ObjectEnumerators to fail, and other weird things which should never happen....

https://pbs.twimg.com/media/BiaDop7CAAAF5yN.jpg:large

Edit: let's get https links working too hnng....

Timotron

(Posted 2014) [#17]

Quick follow up report:

This seems to have fixed the issue, random crashing with any asynch loading of images no longer seems to be an issue on IOS. WOOT!

We did notice the hard cap you placed caps on the number of asynch loads at once (on IOS), and it would be nice if you just internally queued up the request when the asynch cap was reached instead of hard failing and stopping execution due to not being able to make another thread. We will implement a asynch queue into our engine to handle this, so that only X number of asynch will be active at once. But it would be friendlier overall to not require such measures...

Tim