Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#789 closed defect (wontfix)

bug printing/insepecting circular Objective-C structures

Reported by: plkrueger Owned by:
Priority: normal Milestone:
Component: IDE Version: trunk
Keywords: Cc:

Description (last modified by gb)

If you try to print circular Lisp structures in the listener you eventually get a stack overflow and move on. If you have comparable Objective-C structures, CCL will crash trying to display them in the listener. If you try to inspect such an object you get an unhandled runtime exception.

To replicate do something like the following:

Welcome to Clozure Common Lisp Version 1.7-dev-r14466M-trunk  (DarwinX8664)!
? (progn
  (setf d1 (let ((d1 (#/dictionaryWithCapacity: ns:ns-mutable-dictionary 4))
                 (d2 (#/dictionaryWithCapacity: ns:ns-mutable-dictionary 4)))
             (#/setObject:forKey: d1 d2 #@"d2ptr")
             (#/setObject:forKey: d2 d1 #@"d1ptr")
             d1))
  t)
T
? (inspect d1)

And in the AltConsole you get:

Unhandled exception 10 at 0x7fff81951f9f, context->regs at #x7fff5fbfe1e0
Exception occurred while executing foreign code
 at szone_malloc_should_clear + 116
received signal 10; faulting address: 0x7fff5f3fffe8
? for help
[12203] Clozure CL kernel debugger: b
current thread: tcr = 0x1007b0, native thread ID = 0x207, interrupts enabled


(#x000000000044B630) #x0000300000E43B2C : #<Anonymous Function #x0000300000E43A7F> + 173
(#x000000000044B650) #x0000300001324E2C : #<Function (:OBJC-DISPATCH description) #x0000300001324B9F> + 653
(#x000000000044B688) #x0000300000D9023C : #<Function NSOBJECT-DESCRIPTION #x0000300000D9016F> + 205
(#x000000000044B6F0) #x0000300000D8FB2C : #<Function (:INTERNAL (PRINT-OBJECT (OBJC-OBJECT T))) #x0000300000D8FA9F> + 141
(#x000000000044B730) #x0000300000252154 : #<Function %PRINT-UNREADABLE-OBJECT #x000030000025202F> + 293
(#x000000000044B778) #x0000300000D8FD64 : #<Method-Function PRINT-OBJECT (OBJC-OBJECT T) #x0000300000D8FC5F> + 261
(#x000000000044B7A8) #x0000300000209684 : #<Function %CALL-NEXT-METHOD #x000030000020928F> + 1013
(#x000000000044B840) #x00003000001F6B04 : #<Function %%STANDARD-COMBINED-METHOD-DCODE #x00003000001F684F> + 693
(#x000000000044B8C8) #x0000300000506644 : #<Function WRITE-A-FROB #x000030000050659F> + 165
(#x000000000044B948) #x0000300000C37724 : #<Function DO-XP-PRINTING #x0000300000C375CF> + 341
(#x000000000044B9D0) #x0000300000C37B7C : #<Function (:INTERNAL DO-IT XP-PRINT) #x0000300000C37B4F> + 45
(#x000000000044B9F8) #x0000300000508294 : #<Function MAYBE-INITIATE-XP-PRINTING #x000030000050804F> + 581
(#x000000000044BA78) #x00003000005078BC : #<Function WRITE-INTERNAL #x00003000005075AF> + 781
(#x000000000044BAD8) #x0000300000512334 : #<Function WRITE-1 #x000030000051210F> + 549
(#x000000000044BB08) #x000030000011D864 : #<Function PRIN1 #x000030000011D7DF> + 133
(#x000000000044BB48) #x000030000011D6EC : #<Function PRIN1-TO-STRING #x000030000011D64F> + 157
(#x000000000044BB98) #x000030000186738C : #<Function INSPECTOR-OBJECT-NSSTRING #x000030000186727F> + 269
(#x000000000044BC60) #x0000300001866CDC : #<Function MAKE-INSPECTOR-ITEM #x0000300001866BEF> + 237
(#x000000000044BC98) #x0000300001866674 : #<Function MAKE-INSPECTOR-WINDOW #x00003000018665FF> + 117
(#x000000000044BCB8) #x0000300001867524 : #<Function MAKE-INSPECTOR #x000030000186749F> + 133
(#x000000000044BCF0) #x0000300001347744 : #<Function HANDLE-INVOKING-LISP-FUNCTION #x00003000013475FF> + 325
(#x000000000044BD68) #x0000300001358B44 : #<Method-Function INVOKE-LISP-FUNCTION (6614255403008 T) #x00003000013589FF> + 325
(#x000000000044BDD0) #x000030000135919C : #<Function -[NSApplication invokeLispFunction:] #x0000300001358EDF> + 701
(#x000000000044BE38) #x00003000001AC04C : #<Function %PASCAL-FUNCTIONS% #x00003000001ABEDF> + 365
(#x000000000044BEF0) #x0000300000FBB55C : #<Anonymous Function #x0000300000FBB4AF> + 173
(#x000000000044BF10) #x000030000139D87C : #<Function (:OBJC-DISPATCH run) #x000030000139D5EF> + 653
(#x000000000044BF48) #x000030000139D104 : #<Function EVENT-LOOP #x000030000139CF5F> + 421
(#x000000000044BFA0) #x00003000013AE0AC : #<Function (:INTERNAL COCOA-STARTUP START-COCOA-APPLICATION) #x00003000013ADCBF> + 1005
[12203] Clozure CL kernel debugger: k

Change History (2)

comment:1 follow-up: Changed 9 years ago by gb

  • Description modified (diff)
  • Resolution set to wontfix
  • Status changed from new to closed

If foreign code overflows its stack, there isn't likely to be anything that we can do to recover from that.

If one translates your example to ObjC and runs the result, it'll die in pretty much the same way and at very nearly the same place. (Despite the presence of the string 'malloc' in the function name, it's a stack overflow.) When the crash happens in GDB, a GDB backtrace shows >20000 pending calls to [NSDictionary description:indent:]

The lisp backtrace in your example shows that (nearly) the last thing that lisp did was to call #/description. I'd guess that there are likely many thousands of calls to the same method between the point of the crash and the point where CCL last had any control over what happened.

I don't think that ObjC has anything like *PRINT-CIRCLE*; if not, the #/description method for a circular data structure may stack-overflow, and the absolute best that I think we could do in that case is try to report it as a stack-overflow (rather than as a random memory fault that's a symptom of trying to write past the end of the stack.)

I'm marking this as "wontfix", because I can't think of any way to fix this. It'd certainly be desirable to fix it, if that was possible.

comment:2 in reply to: ↑ 1 Changed 9 years ago by plkrueger

Replying to gb:

If foreign code overflows its stack, there isn't likely to be anything that we can do to recover from that.

If one translates your example to ObjC and runs the result, it'll die in pretty much the same way and at very nearly the same place. (Despite the presence of the string 'malloc' in the function name, it's a stack overflow.) When the crash happens in GDB, a GDB backtrace shows >20000 pending calls to [NSDictionary description:indent:]

The lisp backtrace in your example shows that (nearly) the last thing that lisp did was to call #/description. I'd guess that there are likely many thousands of calls to the same method between the point of the crash and the point where CCL last had any control over what happened.

I don't think that ObjC has anything like *PRINT-CIRCLE*; if not, the #/description method for a circular data structure may stack-overflow, and the absolute best that I think we could do in that case is try to report it as a stack-overflow (rather than as a random memory fault that's a symptom of trying to write past the end of the stack.)

I'm marking this as "wontfix", because I can't think of any way to fix this. It'd certainly be desirable to fix it, if that was possible.

My original intent was to archive NSDictionary objects with such circular structures given Apple's documentation that seems to say that such archives will work properly. However further investigation shows that circularities between container objects like NSDictionaries and NSArrays are NOT archived and recovered correctly. This probably explains why they never bothered to make the #/description call work under those conditions either. They do archive correctly circularities among the slots of user defined objects, so I'll have to rework my code to do something with those instead. Bottom line is that this will no longer be a problem for me because I won't use such structures. Sorry for the bother.

Note: See TracTickets for help on using tickets.