Opening class browser in GS64/VW 8.3 causes image to exhaust all memory and hang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Opening class browser in GS64/VW 8.3 causes image to exhaust all memory and hang

Gemstone/S mailing list
Hi,
I'm having a problem using the Community Edition of VW 8.3 when connected to Community Edition of GS64 version 3.4.3 on Linux.

After I log using an RPC session I am able to do the following: 
- commit, abort, begin
- browse the following: security policies, symbol lists, users, connectors, breakpoints, implementors of a method.  As soon as I try to open the System Browser, the image quickly runs out of memory and hangs.

I tried adjusting some settings but nothing appears to help.

If is frustrating because there are no error messages.  I suspect there is
some internal error with GBS but it does not indicate a problem as it
gobbles up 500 MB of memory.

Please let me know if there is a way to debug what GBS is doing by allocating over 500 MB of memory just to show the class names which appear in the class browser
of the base system.  No application classes have been loaded yet.

Thanks,
Gary


_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Opening class browser in GS64/VW 8.3 causes image to exhaust all memory and hang

Gemstone/S mailing list
Trying this again, but including the mailing list this time.

On Tue, Jan 29, 2019 at 5:32 PM Gary Morrison via GemStone-Smalltalk <[hidden email]> wrote:
Hi,
I'm having a problem using the Community Edition of VW 8.3 when connected to Community Edition of GS64 version 3.4.3 on Linux.

https://gemtalksystems.com/products/gbs-vw/ says the support configurations for GBS 8.3 are  Client Smalltalk: VisualWorks 8.2.1, 8.1.1, and 7.10.1.
It seems likely that you are getting bitten by something in VW 8.3 which that version of GBS doesn't support.

[Ordinarily, the system browser should open in about a second especially when working with only the classes distributed in the product.]



After I log using an RPC session I am able to do the following: 
- commit, abort, begin
- browse the following: security policies, symbol lists, users, connectors, breakpoints, implementors of a method.  As soon as I try to open the System Browser, the image quickly runs out of memory and hangs.

I tried adjusting some settings but nothing appears to help.

If is frustrating because there are no error messages.  I suspect there is
some internal error with GBS but it does not indicate a problem as it
gobbles up 500 MB of memory.

Please let me know if there is a way to debug what GBS is doing by allocating over 500 MB of memory just to show the class names which appear in the class browser
of the base system.  No application classes have been loaded yet.

Thanks,
Gary

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Opening class browser in GS64/VW 8.3 causes image to exhaust all memory and hang

Gemstone/S mailing list
What Richard said.  VW 8.3 is not yet supported by GBS.  Try with VW 8.2.1 and GBS 8.3.

On 1/29/2019 5:47 PM, Richard Sargent via GemStone-Smalltalk wrote:
Trying this again, but including the mailing list this time.

On Tue, Jan 29, 2019 at 5:32 PM Gary Morrison via GemStone-Smalltalk <[hidden email]> wrote:
Hi,
I'm having a problem using the Community Edition of VW 8.3 when connected to Community Edition of GS64 version 3.4.3 on Linux.

https://gemtalksystems.com/products/gbs-vw/ says the support configurations for GBS 8.3 are  Client Smalltalk: VisualWorks 8.2.1, 8.1.1, and 7.10.1.
It seems likely that you are getting bitten by something in VW 8.3 which that version of GBS doesn't support.

[Ordinarily, the system browser should open in about a second especially when working with only the classes distributed in the product.]



After I log using an RPC session I am able to do the following: 
- commit, abort, begin
- browse the following: security policies, symbol lists, users, connectors, breakpoints, implementors of a method.  As soon as I try to open the System Browser, the image quickly runs out of memory and hangs.

I tried adjusting some settings but nothing appears to help.

If is frustrating because there are no error messages.  I suspect there is
some internal error with GBS but it does not indicate a problem as it
gobbles up 500 MB of memory.

Please let me know if there is a way to debug what GBS is doing by allocating over 500 MB of memory just to show the class names which appear in the class browser
of the base system.  No application classes have been loaded yet.

Thanks,
Gary

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk


_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Opening class browser in GS64/VW 8.3 causes image to exhaust all memory and hang

Gemstone/S mailing list
In reply to this post by Gemstone/S mailing list
Richard,
Thank you.  I'll have go back and ask Cincom if they can provide version 8.2.1 as a Community Edition.
Thanks,
Gary

On Tue, Jan 29, 2019 at 8:47 PM Richard Sargent <[hidden email]> wrote:
Trying this again, but including the mailing list this time.

On Tue, Jan 29, 2019 at 5:32 PM Gary Morrison via GemStone-Smalltalk <[hidden email]> wrote:
Hi,
I'm having a problem using the Community Edition of VW 8.3 when connected to Community Edition of GS64 version 3.4.3 on Linux.

https://gemtalksystems.com/products/gbs-vw/ says the support configurations for GBS 8.3 are  Client Smalltalk: VisualWorks 8.2.1, 8.1.1, and 7.10.1.
It seems likely that you are getting bitten by something in VW 8.3 which that version of GBS doesn't support.

[Ordinarily, the system browser should open in about a second especially when working with only the classes distributed in the product.]



After I log using an RPC session I am able to do the following: 
- commit, abort, begin
- browse the following: security policies, symbol lists, users, connectors, breakpoints, implementors of a method.  As soon as I try to open the System Browser, the image quickly runs out of memory and hangs.

I tried adjusting some settings but nothing appears to help.

If is frustrating because there are no error messages.  I suspect there is
some internal error with GBS but it does not indicate a problem as it
gobbles up 500 MB of memory.

Please let me know if there is a way to debug what GBS is doing by allocating over 500 MB of memory just to show the class names which appear in the class browser
of the base system.  No application classes have been loaded yet.

Thanks,
Gary

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
Reply | Threaded
Open this post in threaded view
|

Re: Opening class browser in GS64/VW 8.3 causes image to exhaust all memory and hang

Gemstone/S mailing list
I found the issue.   The method, installCtrlFHooks, throws exceptions at,  "specWrapper component component controller" in VW 8.3,
at least in the Community Edition that I have, which is new.

When I added the checks to see of the visual part respondsTo: #component, then that stopped the infinite loop
and I was able to browse the GS classes fine.


GbxBrowser >> installCtrlFHooks

| possibleControllers actualControllers listControllers |
possibleControllers := #(#dictionaryList #classList #IconButton)
asOrderedCollection collect: [:id | self controllerAt: id].
possibleControllers add: self metaTabControlWidget controller.
possibleControllers addAll: ((self widgetAt: #toolBar) components
collect: [:specWrapper | 
(specWrapper respondsTo: #component) ifFalse: [nil] ifTrue: [ 
(specWrapper component respondsTo: #component) ifFalse: [ nil ]
ifTrue: [specWrapper component component controller]]]).


On Tue, Jan 29, 2019 at 9:36 PM Gary Morrison <[hidden email]> wrote:
Richard,
Thank you.  I'll have go back and ask Cincom if they can provide version 8.2.1 as a Community Edition.
Thanks,
Gary

On Tue, Jan 29, 2019 at 8:47 PM Richard Sargent <[hidden email]> wrote:
Trying this again, but including the mailing list this time.

On Tue, Jan 29, 2019 at 5:32 PM Gary Morrison via GemStone-Smalltalk <[hidden email]> wrote:
Hi,
I'm having a problem using the Community Edition of VW 8.3 when connected to Community Edition of GS64 version 3.4.3 on Linux.

https://gemtalksystems.com/products/gbs-vw/ says the support configurations for GBS 8.3 are  Client Smalltalk: VisualWorks 8.2.1, 8.1.1, and 7.10.1.
It seems likely that you are getting bitten by something in VW 8.3 which that version of GBS doesn't support.

[Ordinarily, the system browser should open in about a second especially when working with only the classes distributed in the product.]



After I log using an RPC session I am able to do the following: 
- commit, abort, begin
- browse the following: security policies, symbol lists, users, connectors, breakpoints, implementors of a method.  As soon as I try to open the System Browser, the image quickly runs out of memory and hangs.

I tried adjusting some settings but nothing appears to help.

If is frustrating because there are no error messages.  I suspect there is
some internal error with GBS but it does not indicate a problem as it
gobbles up 500 MB of memory.

Please let me know if there is a way to debug what GBS is doing by allocating over 500 MB of memory just to show the class names which appear in the class browser
of the base system.  No application classes have been loaded yet.

Thanks,
Gary

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
http://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk