From: Frank I. <ill...@ma...> - 2005-11-28 07:21:16
|
I could dig a little deeper and found the following stack trace is repsonsible for a "Stack level too deep" exception: #0 0x928f6428 in +[NSException exceptionWithName:reason:userInfo:] () #1 0x00071c64 in override_mixin_class_method_list () #2 0x00071d50 in override_mixin_class_method_list () #3 0x000720d0 in override_mixin_class_method_list () #4 0x00070ba4 in ocstr_to_rbstr () #5 0x928cf574 in -[NSObject(NSForwardInvocation) forward::] () #6 0x909c40d0 in _objc_msgForward () #7 0x00070c4c in ocstr_to_rbstr () #8 0x92938708 in _NSGetUsingKeyValueGetter () #9 0x928eb360 in -[NSObject(NSKeyValueCoding) valueForKeyPath:] () #10 0x1001badc in -[WBLPart pullValues:] (self=0x673c20, _cmd=0x100584bc, key=0x6733f0) #11 0x1001bc64 in -[WBLPart pullValues] (self=0x673c20, _cmd=0x100584a4) #12 0x1001bd78 in -[WBLPart pullValues] (self=0x672390, _cmd=0x100584a4) #13 0x1001bd78 in -[WBLPart pullValues] (self=0x670a90, _cmd=0x100584a4) #14 0x1001bcb8 in -[WBLPart pullValues] (self=0x670990, _cmd=0x100584a4) #15 0x1001bd78 in -[WBLPart pullValues] (self=0x664250, _cmd=0x100584a4) #16 0x1002e14c in -[WBLPhase processRequest:] (self=0x6713c0, _cmd=0x100571fc, request=0x66cfa0) #17 0x10017e1c in -[WBLProject processRequest:] (self=0x627ee0, _cmd=0x100571fc, request=0x66cfa0) #18 0x1001ef98 in -[WBLHandler handleRequest:] (self=0x62d1e0, _cmd=0x10058900, request=0x66cfa0) #19 0x1001f1d0 in -[WBLHandler request:] (self=0x62d1e0, _cmd=0x10056fb4, request=0x66cfa0) #20 0x1001602c in -[WBLApplication request:] (self=0x627ee0, _cmd=0x10057ac0, request=0x66cfa0) #21 0x1003a81c in -[WBLAdaptorThread request:] (self=0x63b980, _cmd=0x10057ac0, req=0x66cfa0) #22 0x1003ab38 in -[WBLAdaptorThread onSocket:didReadData:withTag:] (self=0x63b980, _cmd=0x1005bc0c, sock=0x6607e0, data=0x671060, tag=2) #23 0x100370a0 in -[AsyncSocket completeCurrentRead] (self=0x6607e0, _cmd=0x1005b400) #24 0x10036e18 in -[AsyncSocket doBytesAvailable] (self=0x6607e0, _cmd=0x1005b414) #25 0x10036a30 in -[AsyncSocket maybeDequeueRead] (self=0x6607e0, _cmd=0x1005b428) #26 0x928e6138 in __NSFireDelayedPerform () #27 0x90770ae0 in __CFRunLoopDoTimer () #28 0x9075d458 in __CFRunLoopRun () #29 0x9075ca0c in CFRunLoopRunSpecific () #30 0x928ea664 in -[NSRunLoop runMode:beforeDate:] () #31 0x9292f298 in -[NSRunLoop runUntilDate:] () #32 0x1003a4e0 in -[WBLAdaptorThread runWorkerThread] (self=0x63b980, _cmd=0x1005c340) #33 0x928db6d4 in forkThreadForFunction () #34 0x9002b200 in _pthread_body () I already tried to increase the stack limit with ulimit -s but this did not change anything. Anyone any ideas? Cheers Frank Am 27.11.2005 um 03:55 schrieb Frank Illenberger: > Hi, > > this week I discovered RubyCocoa and was impressed how nicely it > integrates with cocoa. I immediately tried to include it into my > server application. In the beginning it worked as I expected, but > after my program runs for a while, it quits with the following > error message: > > /Users/frank/Projekte/BuildFiles/Debug/WeblitzDemo.app/Contents/ > Resources/rb_main.rb:22:in `NSApplicationMain': stack level too > deep (SystemStackError) > from /Users/frank/Projekte/BuildFiles/Debug/WeblitzDemo.app/ > Contents/Resources/rb_main.rb:22 > > In my test I have a simple ruby class extending a custom cocoa > class and in it is a simple attribute with accessors which the rest > of my application calls via KV-coding. > > class RubyComponent < OSX::WBLComponent > > attr_reader :testWert > attr_writer :testWert > > end > > > Does anybody know where such a behavior is coming from? Does it > play a role that the KV-calls come from different threads/run loops > (but never concurrently)? > > > Cheers > > > Frank > |