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

[Dale Henrichs via Glass]

Mariano,

Does the following return nil consistently when run in your image:

System abortTransaction.
SystemRepository
     listInstances: {FaSecurityAdjustedClosingPriceRecord}
     limit: 0
     toDirectory: nil
     withMaxThreads: 1
     maxCpuUsage: 95
     memoryOnly: false

I think this is the equivalent call that is causing a nil return value. 
I've looked at the code and there is no obvious code path for returning 
nill instead of an Array .... I've submitted an internal bug.

Dale

On 8/28/15 1:20 PM, Dale Henrichs wrote:
> Nonetheless, this looks like a bug in GemStone and now I need to 
> understand why so I can provide a test case to the server guys ... I 
> don't think that 2 metaclasses and 2 classes is a good reason for nil, 
> since GemStone is supposed to survive this kind of situation ... 
> likely it is something else ... this is a multi-thread operation and 
> it is possible that something related to that is the root cause could 
> you check in the stone log and the gem log to see if any error 
> information is written there ...
>
> Thanks for pushing on this like you did ... I was an email behind and 
> you were way ahead of me ... but ... I have an "expectation" that 
> certain class loading scenarios could result in an error, but this 
> kind of error is not part of my expectation and the monticello loading 
> scheme does hide these kinds of problems ....
>
> Need to make the error more visible at the very least ... and fix the 
> GemStone bug ... it's possible that the bug is already fixed and it is 
> not likely that we will ship a 3.1.0.7 with a bugfix -
>
> Let's get a simplified test case and move forward from there ...
>
> Is it possible that you're in a limited memory situation in your 
> development environment?
>
> Dale
>
> On 8/28/15 1:04 PM, Mariano Martinez Peck wrote:
>>
>>
>> On Fri, Aug 28, 2015 at 5:00 PM, Mariano Martinez Peck 
>> <marianopeck at gmail.com> wrote:
>>
>>
>>
>>     On Fri, Aug 28, 2015 at 4:56 PM, Dale Henrichs via Glass
>>     <glass at lists.gemtalksystems.com
>>     <mailto:glass at lists.gemtalksystems.com>> wrote:
>>
>>         Definitely a GemStone bug, since
>>         Repository>>_scanPomWithMaxThreads:waitForLock:pageBufSize:percentCpuActiveLimit:identSet:limit:scanKind:toDirectory:
>>         is a primitive call and is not documented to return nil ...
>>         unless I misread the stack and calls?
>>
>>
>>     No, I got exactly until that point too. I read the comment of the
>>     method, it said anywhere why it would answer nil, so I kind of
>>     give up.
>>
>>
>> BTW..I will try to see if I can get there again. But I suspect this 
>> is related to the fact that I end up having 2 metaclasses and 2 
>> classes (as I show some emails up) for the same "class" after loading.
>>
>>
>>         Dale
>>
>>
>>         On 8/28/15 12:50 PM, Dale Henrichs wrote:
>>
>>             This looks like a GemStone bug (at first blush), since
>>             the error is originating in
>>
>>             [13] Repository >>
>>             _doListInstancesFrom:with:includeMemory: (envId 0)
>>
>>             so if you could extract some detail from that frame about
>>             where the source of the nil, we might be able to work our
>>             way back to the root cause ...
>>
>>             Dale
>>
>>             On 8/28/15 7:58 AM, Mariano Martinez Peck via Glass wrote:
>>
>>                 [13] Repository >>
>>                 _doListInstancesFrom:with:includeMemory: (envId 0)
>>
>>
>>
>>         _______________________________________________
>>         Glass mailing list
>>         Glass at lists.gemtalksystems.com
>>         <mailto:Glass at lists.gemtalksystems.com>
>>         http://lists.gemtalksystems.com/mailman/listinfo/glass
>>
>>
>>
>>
>>     -- 
>>     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/20150828/6240e9e2/attachment.html>