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

[Dale Henrichs via Glass]

On 09/09/2015 11:47 AM, Mariano Martinez Peck wrote:
>
>
> On Wed, Sep 9, 2015 at 3:36 PM, Dale Henrichs 
> <dale.henrichs at gemtalksystems.com 
> <mailto:dale.henrichs at gemtalksystems.com>> wrote:
>
>
>
>     On 09/09/2015 06:24 AM, Mariano Martinez Peck wrote:
>
>
>
>         Hi Dale,
>
>         Just for the record, I tried with this scenario:
>
>         [marianopeck at quuveserver1 ~]$ free -m
>                       total        used        free  shared
>         buff/cache   available
>         Mem:           8014         388        6850 359  775        7205
>         Swap:         16639           0       16639
>
>         And still didn't work. Note that I have 7GB of RAM free. At
>         the end, when the system crashed, this was the resulting state:
>
>         [marianopeck at quuveserver1 ~]$ free -m
>                       total        used        free  shared
>         buff/cache   available
>         Mem:           8014         338        1316 973 6359        6639
>         Swap:         16639           0       16639
>
>
>         Anyway, no problem, I would assume this is a problem in
>         3.1.0.6 and hopefully I will never need to list instances /
>         migrate this class until I am in 3.2/3.3...
>
>         Thanks for the effort!
>
>
>     I'm not sure that I can interpret the `free -m` numbers correctly.
>     Are you confirming that this as a near out of RAM situation?
>
>
> I am saying that I cannot make it work even with 7GB of RAM 
> free/available...and I also have plenty of swap space from what I can 
> tell.
> Sounds like this should be plenty of RAM to list 66MM objects 
> (66154585 instances to be accurate). But maybe I am wrong...
>
>     We've got an engineer pursuing the "out of memory" scenario and
>     looking for a smoking gun in the code for 3.1.0.6, so that we can
>     be assured that we don't have an existing bug in 3.2/3.3...
>
>     Thank you for your help in tracking this down ...
>
>
> No problem. It usually takes me some time because I must stop 
> everything, restore from backup, modify the listMethod via topaz with 
> SystemUser, then run update code... then as soon as it fail I must 
> revert again with the "corrected" extent so that the system is not 
> that long in a bad state... But still, if this is if help to you by 
> any means, I am happy to continue trying.
>
> My offer is still valid if you want to enter via web and have an use 
> some "code workspace" I have or the seaside debugger etc. I could also 
> open log the exception in the object log if you want. Or I could 
> temporary open a port in the firewall in case you want remote-gemtools 
> (but that is very very slow). But as said, we should coordinate the 
> date for this.
>

Well we are still guessing and the problem with looking at the Smalltalk 
stack is that all of the interesting things that are going on are 
happening in a separate os process running c code ....having 7GB of free 
memory does not immediately rule out a "memory problem" - we had a list 
instances bug that used way too much memory ... a statmon run using 1 
second sampling should allow you to see whether or not the gem's memory 
consumption is rising during the list instances run (we expect it to 
return to normal after the failure) ...

We _are_ still guessing because we have not found a smoking gun yet .... 
can you tell me whether there is a time delay that causes the error to 
be raised, or does it happen "immediately" ... the guys are reading code 
here and we haven't found anything yet ...

Dale
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gemtalksystems.com/mailman/private/glass/attachments/20150909/90fdab66/attachment.html>