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

Dale Henrichs via Glass glass at lists.gemtalksystems.com
Fri Aug 28 13:20:42 PDT 2015


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 <mailto: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/cfb0a891/attachment-0001.html>


More information about the Glass mailing list