Re: [swarm-hackers] Help on Heatbugs (Git)

On Thu, Nov 19, 2009 at 1:25 PM, Scott Christley <address@hidden> wrote:

Well two things I notice, for some reason THREADED=1 even though it seems that you have defined it to 0 in the Xcode settings, I don't know why, but I'm very positive that this spawning of threads is causing all kinds of havoc. Just get rid of that code. It seems to run much better for me then.

In HeatSpace, in this method

- (HeatCell *)findExtremeType:(HeatExtremeType)type forAgent:(Heatbug *)hbug {

You seem to be creating HeatCell's. This is what appears to be eating memory.

There is some wierd correlations with heatbug movements, maybe that is on purpose? The use of the time() function in BHWalk is odd, is that on purpose or do you really want random numbers? The comment says one thing but the code seems different.

Yes - the BHWalk is my second behavior - which has a highly stupid 2-second algorithm behind it. Basically I was merely testing that I can plug behaviors in and out, and watch the agents reactions.

The superclass of all the behaviors, BHBehaviors, defines a -step method, which the category abovementioned calls... for example what ever behavior an agent is currently engaged in, will be sent the -step mesage....

- (void)step {
    BHBehaviors *engaged = [self engaged];
    if(!engaged) {
        engaged = [self nextAction];
        [self setEngaged:YES inAction:engaged];
    }

    [self setEuphoria:0.1 * (1.0 - [self unhappiness]) + 0.9 * [self euphoria]];

    if(![engaged step])
        [self setEngaged:NO inAction:engaged];
}

Only the superclass of the behaviors defines a -step method however, and all subclasses define a -_step method, and that is so that the superclass can wrap up the subclass's -_step inside other homekeeping calls...

- (BOOL)step {
    [self setExpiryTTL:[self expiryTTL] - 1];
    if(![self expired]) [self _step];
    return ![self expired];
}

So the reason that I'm using _step - has nothing to do with wanting to keep it private, but it was a... oddity I added to remind me to later figure out if there's a better way of doing this, if there is - then I'd love to know, if there isn't, I'll go ahead and just rename -_step, to something like -internalStep, or something - but it has nothing to do with being private.

Nima

Also, why are you using methods with an underscore? If you truly think that keeps methods "private", then that's not true, there is no true private methods in ObjC, you can can call pretty much any method that a class implements.

Okay, the underscore - I better explain this now in case Swarm offers a better solution already.

What happens is that the BHSwarmObjectAdditions category, adds "behavioral" methods to the standard SwarmObject, be it a Heatbug, or else.

Next

cheers

Scott

On Nov 18, 2009, at 4:50 PM, Nima Talebi wrote:

Issue Part I

Hmmm, no I haven't removed any such code, mainly because it doesn't exist in the Heatbugs app (and I haven't modified the framework)...

Original Heatbugs...
*|1119:11:45:01|address@hidden:Heatbugs]% pwd
/Users/xerxes/devel/FWSwarm/apps/openstep/Heatbugs
*|1119:11:45:02|address@hidden:Heatbugs]% grep -sre NSAutoreleasePool *
mainBatch.m:    NSAutoreleasePool *pool = [NSAutoreleasePool new];
*|1119:11:45:12|address@hidden:Heatbugs]%

My fork of heatbugs...
*|1119:11:45:12|address@hidden:Heatbugs]% cd ../../../../heatbugs/
*|1119:11:46:28|address@hidden:heatbugs]% grep -sre NSAutoreleasePool *
HeatbugsGUI.m:    NSAutoreleasePool *pool = [NSAutoreleasePool new]; {
HeatbugsGUI.m:    NSAutoreleasePool *pool = [NSAutoreleasePool new]; {
Binary file build/Debug/Heatbugs.app/Contents/MacOS/Heatbugs matches
Binary file build/DebugSingleAgent/Heatbugs.app/Contents/MacOS/Heatbugs matches
Binary file build/Heatbugs.build/Debug/Heatbugs.build/Objects-normal/i386/HeatbugsGUI.o matches
Binary file build/Heatbugs.build/DebugSingleAgent/Heatbugs.build/Objects-normal/i386/HeatbugsGUI.o matches
Binary file build/Heatbugs.build/Heatbugs.pbxindex/strings.pbxstrings/strings matches
Binary file build/Heatbugs.build/Release/Heatbugs.build/Objects-normal/i386/HeatbugsGUI.o matches
Binary file build/Release/Heatbugs.app/Contents/MacOS/Heatbugs matches
Binary file build/Release/Heatbugs.app.dSYM/Contents/Resources/DWARF/Heatbugs matches
mainBatch.m:    NSAutoreleasePool *pool = [NSAutoreleasePool new];
*|1119:11:46:30|address@hidden:heatbugs]%

Issue Part II

Regarding threads - What I found is that drawing the heatspace is quite time consuming, so I wanted to processing to just continue on one processor, while the other one, in the background (and on another core), updates the slow-to-compute heatspace display.

But as you said a few days ago, if it's not dangerous to call [self swarmHasUpdatedNotification] unless exactly one run of a `[heatSpaceDisplay updateDisplay]' AND one run of a following `[heatbugDisplay updateDisplay]' is already executed, then I can't really thread.

On Thu, Nov 19, 2009 at 9:33 AM, Scott Christley <address@hidden> wrote:

No need to detach threads to update the displays, actually that is probably a bad idea because you are not waiting for the threads to finish before you have the GUI redraw. Anyways, we don't want to force end-users to have to use threads for standard Swarm stuff, that's why all that complication is hidden, the stock code should be fine.

Well the problem seems apparent just from looking at the stack trace...

_NSOutOfMemoryErrorHandler

Did you eliminate an NSAutoreleasePool from somewhere?

Scott

On Nov 18, 2009, at 2:24 PM, Nima Talebi wrote:

Sure can - I'll do that in a minute - just an update too on this...

I found the freeze, eventually crashes if I bothered to wait a little longer.

The thread with the crash has the following traceback...

#0 0x92ea2756 in _cache_malloc
#1 0x92ea257e in _cache_fill

#2 0x92eaa6ff in lookUpMethod
#3 0x92ea1da7 in _class_lookupMethodAndLoadCache
#4 0x92ea1953 in objc_msgSend
#5 0x96cf95f2 in +[_NSCallStackArray arrayWithFrames:count:symbols:]

#6 0x96cf96d1 in +[NSThread callStackSymbols]
#7 0x9129c58a in __raiseError
#8 0x92ea5f49 in objc_exception_throw
#9 0x96d95fda in _NSOutOfMemoryErrorHandler
#10 0x911cd632 in _CFRuntimeCreateInstance
#11 0x911cd2ab in CFBasicHashCreate
#12 0x911cf358 in __CFDictionaryCreateGeneric

#13 0x911cf131 in CFDictionaryCreateMutable
#14 0x911f379f in -[__NSPlaceholderDictionary initWithCapacity:]

#15 0x911f3712 in -[__NSPlaceholderDictionary init]
#16 0x9129c51b in __raiseError

#17 0x92ea5f49 in objc_exception_throw
#18 0x96d95fda in _NSOutOfMemoryErrorHandler

#19 0x912ca88b in __CFStringHandleOutOfMemory
#20 0x911d6045 in __CFStringChangeSizeMultiple

#21 0x911f3085 in __CFStringAppendBytes
#22 0x911f6112 in _CFStringAppendFormatAndArgumentsAux

#23 0x911f5429 in _CFStringCreateWithFormatAndArgumentsAux
#24 0x911fdbfe in CFStringCreateWithFormatAndArguments

#25 0x911fdbc9 in CFStringCreateWithFormat
#26 0x911cd60e in _CFRuntimeCreateInstance

#27 0x98c5139d in CGTypeCreateInstanceWithAllocator
#28 0x98c51fae in CGTypeCreateInstance

#29 0x98c5ddb9 in CGColorCreate
#30 0x9426040d in -[NSDeviceRGBColor _createCGColorWithAlpha:]

#31 0x9424c3c2 in -[NSCalibratedRGBColor set]
#32 0x00086f00 in -[Value2dDisplay updateDisplay]

#33 0x000033b4 in -[HeatbugsGUI updateGraphicalDisplays] at HeatbugsGUI.m:156
#34 0x00084f0b in __builtin_avcall

#35 0x0007cb25 in -[Activity_c _run_]
#36 0x0007c94b in -[Activity_c _run_]
#37 0x0007c94b in -[Activity_c _run_]
#38 0x0007c94b in -[Activity_c _run_]
#39 0x0007c65f in -[Activity_c run]

#40 0x000776ee in -[ScheduleActivity_c stepUntil:]
#41 0x00086405 in -[OpenStepSwarmController processStateFlag]

#42 0x000865cf in -[OpenStepSwarmController simulationControl:]
#43 0x00086113 in -[OpenStepSwarmController newSimulation:]

#44 0x96c7b964 in -[NSThread main]
#45 0x96c7b914 in __NSThread__main__
#46 0x97aaef39 in _pthread_start

#47 0x97aaedbe in thread_start

Note that I've disabled threading to simplify things a little.

The segment from my code that is involved in this is as follows...

- (void)updateGraphicalDisplays {
// Update any displays with current model state.

#if THREADED > 0
if([lock tryLock]) {
[NSThread detachNewThreadSelector:@selector(updateHeatSpaceDisplay)
   toTarget:self
   withObject:nil];
[lock unlock];
}

if([lock tryLock]) {
[NSThread detachNewThreadSelector:@selector(updateHeatbugDisplay)
   toTarget:self
   withObject:nil];
[lock unlock];

}
#else
[heatSpaceDisplay updateDisplay];

[heatbugDisplay updateDisplay];

//. Inform ourselves that updates are complete and graphical views

//. should be re-displayed.
[self swarmHasUpdatedNotification];
#endif

//. [self viewNeedsDisplay: [_delegate heatbugSpaceView]];
}

Tarball coming up next.

Nima

On Thu, Nov 19, 2009 at 3:38 AM, Scott Christley <address@hidden> wrote:

Hey Nima,

I don't have git, can you email me a tar ball of the source directly (off-list) and I will give it a try.

Scott

On Nov 18, 2009, at 1:00 AM, Nima Talebi wrote:

Hi All,

I've almost got it all working, one last problem that's truly difficult to debug (for me).

Could someone please clone this...

http://git.autonomy.net.au/?p=heatbugs;a=summary

...and run it on Mac OS X.

You can enable/disable threading in the build preprocessor macros - doesn't seem to be related to that at all however.

The app runs as expected for some random number of minutes, and then freezes; There is no crash, no traceback, no messages on the console.

In Debug mode, when all the extra assertions and strict checks are enabled, no violations are made.

While you can see that the psudo RNG is active (the evolution of the swarm is identical each time), the app freezing point is quite random.

I'm out of ideas.

Nima

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

--
Nima Talebi
web: http://ai.autonomy.net.au/People/Nima
gpg: B51D 1F18 D8E2 B702 B027 23A4 E06B DAC1 BE70 ADC0
_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

_______________________________________________
swarm-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/swarm-hackers

From:	Nima Talebi
Subject:	Re: [swarm-hackers] Help on Heatbugs (Git)
Date:	Thu, 19 Nov 2009 16:38:11 +1100