I have updated my change to be more careful calling describeType.  This 
(somewhat) works around the error André's test case shows.  I added code to 
print out a debug message when it fails, and made it so JS Error backtraces are 
more obvious.

Henry, maybe you could try your test case with the updated change and see if 
there is more information revealed?

On 2010-12-01, at 07:52, André Bargull wrote:

> The internal flash player function avmplus::describeMetadata() [1] iterates 
> over arrays/objects with a for-each loop. So inserting an `undefined` 
> property to the Object or Array prototype will cause an exception. That means 
> we need to guard all invocations of describeType() in the code. Maybe we 
> should also report this to Adobe, but otoh fudging with 
> Object./Array.prototype is never a good idea and possibly they'll just 
> respond with the advice to make the properties not-enumerable by calling 
> Object#setPropertyIsEnumerable().
> 
> 
> Here's a simple test case if anyone is interested in it:
> ---
> function() :void {
>  Array.prototype.a = void 0;
>  try {
>    var description:XML = describeType({});
>  } finally {
>    delete Array.prototype.a;
>  }
> })()
> ---
> 
> 
> [1] http://code.google.com/p/redshell/source/browse/core/DescribeType.as
> 
> On 12/1/2010 4:09 AM, P T Withington wrote:
>> Oh blast. Is something in the debugger iterating over an Array using for-in 
>> when it should only be iterating over indices?
>> 
>> On Nov 30, 2010, at 18:28, André Bargull<[email protected]>  wrote:
>> 
>>> Does the code alter built-in prototypes like Object.prototype or 
>>> Array.prototype? For example try to evaluate the following function in the 
>>> debugger, it will also trigger the TypeError "#1010".
>>> 
>>> (function(){ Array.prototype.a=void 0; try { Debug.inspect({}); } finally { 
>>> delete Array.prototype.a; } })()
>>> 
>>> 
>>> On 11/30/2010 11:01 PM, P T Withington wrote:
>>>> Hey, I just noticed that the backtrace has a slot named 'undefined' too, 
>>>> and it has an undefined value.
>>>> 
>>>> I wonder if it is something about the app that has made the debugger 
>>>> decide that every object has a slot named 'undefined'?
>>>> 
>>>> LzError is not a dynamic class, so it will give an error if you try to 
>>>> access a slot that does not exist, whereas LzBacktrace is dynamic, so a 
>>>> reference to a non-existent slot will just return `undefined` [which we 
>>>> print `(void 0)`].
>>>> 
>>>> On 2010-11-30, at 15:52, Henry Minsky wrote:
>>>> 
>>>>> That is an improvement, the backtrace from the error is
>>>>> clickable/inspectable now.
>>>>> 
>>>>> But do you have any idea what that "undefined: Error.." means when I 
>>>>> inspect
>>>>> the LzError object ?
>>>>> 
>>>>> lzx>   Debug.inspect(«LzError(128)| @../../foundation/restricted/D…»)
>>>>> «LzError(128)#3| @../../foundation/restricted/DefinitionLoader.lzx#137:
>>>>> TypeError: Error #1010: A term is undefined and has no …» {
>>>>>  backtrace: «Backtrace(26)| loadRegistryFile<- getDefinitionNode<-
>>>>> getDefinition<- handle oninit<- sendEvent<- __LZcallInit<- __LZc…»
>>>>>  file: '../../foundation/restricted/DefinitionLoader.lzx'
>>>>>  length: 128
>>>>>  line: 137
>>>>>  message: 'TypeError: Error #1010: A term is undefined and has no
>>>>> properties.'
>>>>>  undefined: Error: ReferenceError: Error #… computing description
>>>>> }
>>>>> «LzError(128)#3| @../../foundation/restricted/DefinitionLoader.lzx#137:
>>>>> TypeError: Error #1010: A term is undefined and has no properties.»
>>>>> lzx>   Debug.inspect(«Backtrace(26)| loadRegistryFile<- getDefini…»)
>>>>> «Backtrace(26)#5| loadRegistryFile<- getDefinitionNode<- getDefinition<-
>>>>> handle oninit<- sendEvent<- __LZcallInit<- __LZc…» {
>>>>>  length: 26
>>>>>  undefined: (void 0)
>>>>>  0: sendEvent @lfc/events/LaszloEvents.lzs#627
>>>>>  1: checkQ @lfc/services/LzInstantiator.lzs#250
>>>>>  2: makeSomeViews @lfc/services/LzInstantiator.lzs#314
>>>>>  3: __LZinstantiationDone @lfc/views/LaszloCanvas.lzs#732
>>>>>  4: __LZcallInit @lfc/views/LaszloCanvas.lzs#801
>>>>>  5: sendEvent @lfc/events/LaszloEvents.lzs#627
>>>>>  6: handle oninit @ManagementCenter.lzx#256
>>>>>  7: startApp @ManagementCenter.lzx#145
>>>>>  8: $lzc$class_wcfMainWorkbench @#34
>>>>>  9: $lzc$class_basecomponent @#446
>>>>>  10: LzView @lfc/views/LaszloView.lzs#51
>>>>>  11: LzNode @lfc/core/LzNode.lzs#351
>>>>>  12: createChildren @lfc/core/LzNode.lzs#1440
>>>>>  13: createImmediate @lfc/services/LzInstantiator.lzs#336
>>>>>  14: makeSomeViews @lfc/services/LzInstantiator.lzs#314
>>>>>  15: __LZinstantiationDone @lfc/views/LaszloView.lzs#555
>>>>>  16: __LZinstantiationDone @lfc/core/LzNode.lzs#1084
>>>>>  17: __LZcallInit @lfc/core/LzNode.lzs#1135
>>>>>  18: __LZcallInit @lfc/core/LzNode.lzs#1135
>>>>>  19: __LZcallInit @lfc/core/LzNode.lzs#1135
>>>>>  20: __LZcallInit @lfc/core/LzNode.lzs#1160
>>>>>  21: sendEvent @lfc/events/LaszloEvents.lzs#627
>>>>>  22: handle oninit @ApplicationMenu.lzx#195
>>>>>  23: getDefinition @../../foundation/restricted/DefinitionLoader.lzx#266
>>>>>  24: getDefinitionNode
>>>>> @../../foundation/restricted/DefinitionLoader.lzx#234
>>>>>  25: loadRegistryFile 
>>>>> @../../foundation/restricted/DefinitionLoader.lzx#137
>>>>> 
>>>>> }
>>>>> «Backtrace(26)#5| loadRegistryFile<- getDefinitionNode<- getDefinition<-
>>>>> handle oninit<- sendEvent<- __LZcallInit<- __LZcallInit<- __LZcal…»
>>>>> lzx>
>>>>> 
>>>>> On Tue, Nov 30, 2010 at 3:18 PM, P T Withington<[email protected]>   wrote:
>>>>> 
>>>>>> Change ptw-20101130-MEn by [email protected] on 2010-11-30 14:08:04 EST
>>>>>>   in /Users/ptw/OpenLaszlo/trunk-3
>>>>>>   for http://svn.openlaszlo.org/openlaszlo/trunk
>>>>>> 
>>>>>> Summary: Be more careful in Debug.inspect
>>>>>> 
>>>>>> Bugs Fixed: LPP-9553 Inspecting a Backtrace in SWF10 gets error when
>>>>>> printing to debug console
>>>>>> 
>>>>>> Technical Reviewer: [email protected] (pending)
>>>>>> QA Reviewer: [email protected] (pending)
>>>>>> 
>>>>>> Overview:
>>>>>> 
>>>>>>   Move the slot-dereference from inspectInternal to
>>>>>>   computeSlotDescription (which is already guarded).
>>>>>> 
>>>>>> Tests:
>>>>>> 
>>>>>>   Henry will test against the gigantic test case he has that is to
>>>>>>   large to fit in the margins of this note.
>>>>>> 
>>>>>> Files:
>>>>>> M       WEB-INF/lps/lfc/debugger/LzDebug.lzs
>>>>>> 
>>>>>> Changeset:
>>>>>> http://svn.openlaszlo.org/openlaszlo/patches/ptw-20101130-MEn.tar
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Henry Minsky
>>>>> Software Architect
>>>>> [email protected]
>>>> 
>>>> 
>> 


Reply via email to