[Glass] Again, Corrup Error preventing debugging real seaside exception

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Thu Feb 2 06:34:29 PST 2017


Yes, there is a bug in selfValue --- the source of the corruptObj error 
---we haven't  characterized the bug, until we understand the cause, a 
corruptObj error could occur anytime an attempt to create a continuation 
is made or a even debugger opened , so yes you should leave the 
#selfValue patch in until we get to the bottom of the VCContext bug...

Dale

On 2/2/17 5:16 AM, Mariano Martinez Peck wrote:
> Uhhh I forgot to ask.... is the change on #selfValue still needed? I 
> mean....sure I can remove it and test, but I am wonder on other 
> scenarios than mine. Please let me know.
>
> Thanks
>
> On Thu, Feb 2, 2017 at 10:15 AM, Mariano Martinez Peck 
> <marianopeck at gmail.com <mailto:marianopeck at gmail.com>> wrote:
>
>     OK, Opened issue: https://github.com/SeasideSt/Grease/issues/22
>     <https://github.com/SeasideSt/Grease/issues/22>
>
>     Cheers,
>
>     On Wed, Feb 1, 2017 at 7:49 PM, Dale Henrichs
>     <dale.henrichs at gemtalksystems.com
>     <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>         On 2/1/17 12:57 PM, Mariano Martinez Peck wrote:
>>
>>
>>         On Wed, Feb 1, 2017 at 5:50 PM, Dale Henrichs
>>         <dale.henrichs at gemtalksystems.com
>>         <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>>
>>             Mariano,
>>
>>             This second error is not related to the earlier error we
>>             were tracking ... I don't see an actual error message in
>>             your email, so I'm not exactly sure what is breaking here
>>             ...
>>
>>
>>         The error message is the one of the screenshot rendered in
>>         the browser (attachment named "Screen Shot 2017-02-01 at
>>         5.13.31 PM.png").
>         That error message was "CorruptObj" and the error message I
>         was looking for was the error message from the #changeClassTo:
>         ... The stack that you supplied us with was different from the
>         #changeClassTo: stack, as I didn't see selfValue on the stack
>         ... doesn't matter though
>>
>>             Nonetheless, #changeClassTo: was a nasty little
>>             performance hack that is no longer needed.
>>
>>             In GRUtf8CodecStream>>nextPutAll: the following should be
>>             done:
>>
>>               binary
>>                 ifTrue: [ stream nextPutAll: aString asString ]
>>                 ifFalse: [ stream nextPutAll: aString
>>             _encodeAsUTF8intoString ]
>>
>>             and in Utf8>>asString the following should be done:
>>
>>                 ^ self decodeToUnicode
>>
>>             It is odd that this "trick" is failing now (especially
>>             without an error message), but I think the right answer
>>             is to eliminate the use of #changeClassTo:
>>
>>
>>         Thanks!! Those changes DID fix it!!!  Wow...it was hard one
>>         this one... I am glad we find it. Do you need anything more
>>         from me to open issue or whatever? I will live with overrides
>>         for the moment.
>         Please open an issue against Grease ... up on SeasideST so
>         that we can get the fix in ... the #changeTo: hack looks like
>         it went in around 3.2.2, so I'm not exactly sure when
>         _encodeAsUTF8intoString was added to the system (it was added
>         to replace the #changeTo: hack)...
>>
>>         BTW, are you sure about performance? Because I remember that
>>         changeClass: hack did improve performance significantly. I
>>         wouldn't want to loos that performance boost!
>         Well, the issue that changeClassTo: was trying to solve was
>         the conversion of the Utf8 instance (ByteArray) into a String
>         (required by Seaside). #'_encodeAsUTF8intoString' encodes utf8
>         directly into a String instance .... so the performance should
>         be no worse than #changeClassTo:
>
>         Dale
>
>
>
>
>     -- 
>     Mariano
>     http://marianopeck.wordpress.com <http://marianopeck.wordpress.com>
>
>
>
>
> -- 
> Mariano
> http://marianopeck.wordpress.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20170202/f4f0f07a/attachment-0001.html>


More information about the Glass mailing list