[Glass] Grrrr cannot migrate (class rename with subclasses and with a name of a deleted class)

Tue Sep 8 14:00:59 PDT 2015

OK Dale, I found out which was the problem, the code of printing should
have been placed inside the scanBlock. Anyway..I did that, and then it did
not work either because gem was crashing and so I couldn't see the log from
GemTools. So I then replaced Transcript show: with "GsFile gciLogServer: "
and now I got it the log:

--LIST-FAILURE--_scanPomWithMaxThreads failure: 1 95 anIdentitySet(
FaSecurityAdjustedClosingPriceRecord) 0 0 nil

Doesn't look like wrong, does it?

Cheers,

On Tue, Sep 8, 2015 at 5:03 PM, Dale Henrichs <
dale.henrichs at gemtalksystems.com> wrote:

> Just rename the temps to ones that compile:)
>
> This time around we are not suspecting that blockClosures and block temps
> are the problem, we are just trying to get the args to the primitive call
> when it fails, so we can trace things further in the C code and try
> determine the code path that leads to a nil return value ...
>
> Dale
>
>
> On 09/08/2015 12:49 PM, Mariano Martinez Peck wrote:
>
>
>
> On Tue, Sep 8, 2015 at 4:26 PM, Dale Henrichs <
> dale.henrichs at gemtalksystems.com> wrote:
>
>> Mariano,
>>
>> Sorry for the delay, but I'm back in the office today and what we would
>> like to do is capture the args that are being used for the primitive so
>> replaicing the `memOnlyBool` block logic in the listInstances:.... method
>> with the following will help us get them:
>>
>>
> Hi Dale, no worries, thanks for pushing!
>
>
>>   memOnlyBool
>>     ifFalse: [
>>       scanBlk := [ :scanSetThisTime | | ret sKind |
>>       sKind := (directoryString ifNotNil:[ 2 ] ifNil:[ 0 ]).
>>       ret := self
>>         _scanPomWithMaxThreads: maxThreads
>>         waitForLock: 60
>>         pageBufSize: 8
>>         percentCpuActiveLimit: aPercentage
>>         identSet: scanSetThisTime
>>         limit: aSmallInt
>>         scanKind: sKind
>>         toDirectory: directoryString ].
>>     ret ifNil: [
>>        Transcript cr; show: '_scanPomWithMaxThreads failure: ',
>>                 maxThreads printString, ' ',
>>                 aPercentage printString, ' ',
>>                 scanSetThisTime printString, ' ',
>>                 aSmallInt printString, ' ',
>>                 sKind printString, ' ',
>>                 directoryString printString ].
>>     ret ].
>>
>>
> This doesn't compile because 'sKind' was defined inside the 'scanBlk' and
> 'scanSetThisTime' is the argument to the closure. Since this problem was
> related to temp vars, I am not sure which is the correct solution.
>
> Let me know,
>
>
>
>> We thought the problem might have been related to the method temp
>> reference for `(directoryString ifNotNil:[ 2 ] ifNil:[ 0 ])`, but since the
>> prim is still failing with that expression inlined there must be a
>> different (less obvious) failure mechanism.
>>
>> Dale
>>
>>
>> On 09/01/2015 11:45 AM, Mariano Martinez Peck wrote:
>>
>> OK then. Perfect. Let me know.
>> Thanks!
>>
>> On Tue, Sep 1, 2015 at 3:28 PM, Dale Henrichs <
>> dale.henrichs at gemtalksystems.com> wrote:
>>
>>>
>>>
>>> On 9/1/15 10:59 AM, Mariano Martinez Peck wrote:
>>>
>>>
>>> On Tue, Sep 1, 2015 at 2:14 PM, Dale Henrichs <
>>> dale.henrichs at gemtalksystems.com> wrote:
>>>
>>>> Could you arrange to get a stack trace from your most recent error and
>>>> a listing of the method that you used ... I want to make sure that we
>>>> understand the failure mechanism ... if it is related to block temps then
>>>> it is fixed in 3.2.x, but if it is not related to block temps then it could
>>>> be present in later versions of GemStone and we'll want to characterize the
>>>> problem .... Obviously, this particular call doesn't reproduce very
>>>> frequently (I wasn't able to make it break with trivial examples) so there
>>>> is likely to be something a little more complex going on ...
>>>>
>>>>
>>> Dale, the exception I get is the one I original shared with you and you
>>> got to the same conclusion as I did.
>>>
>>> What I can offer you is this that I log the error (continuation) in the
>>> object log and the provide you a user for the web user for our app and from
>>> there I can allow you open a kind of Seaside debugger/inspector which will
>>> be much richer than a plain string stack and at least you can also
>>> print/inspect from there. I cannot send you the extent because its quite
>>> big.
>>>
>>> If you think this is OK, then I please need you to ask you to only share
>>> the login info with GemTalks engineer. Since the site is a bit on use (but
>>> with a working extent) I must recover from backup and so the system will be
>>> running with a "broken" extent for a while. No problem with this but if
>>> this will be only a couple of hours or 1-2 day max. So if we will do this,
>>> I would appreciate that you let me know when (you or the engineer) would be
>>> available to take a look.
>>>
>>> Let me know if you want this.
>>>
>>> Thanks for the offer ... we might want to instrument up the method a bit
>>> more instead of looking at a continuation ... so I will get back to you ...
>>> I won't be in the office until Thursday, and that's when I will talk things
>>> over with the engineer ...
>>>
>>> Dale
>>>
>>
>>
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>>
>>
>
>
> --
> Mariano
> 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/20150908/c3aa1696/attachment.html>