All,
I am running Squeak 4.1 with Squeak4.0.2.exe VM on Windows. I downloaded it from squeak.org 2 days ago. I have loaded Cryptography, SSL, and SqueakElib. I am running SqueakElib as a server. My first indication of a problem is that the CPU goes to 100% and stays there. Squeak is uninterruptable with <alt>-. Windows Task Manager shows tat the problem is with Squeak. I opened the ProcessBrowser and turned on the CPUWatcher and ran the system. When the problem occurs, after awhile the VM exits having run out of memory. The crash.log says that the CPUWatcher was trying to catchThePig and it was instantiating an Exception but failed due to no memory. (There were 10 or so iterations of instantiating an exception). So I then went through all the SqueakElib code and made sure all Processes were being created with userBackgroundPriority, so I could interrupt them if they were the problem. I reran and reproduced the problem of the CPU going to 100%. It remained uninterruptable. However, after hitting <alt>-. about 20-30 times, the CPU usage went to 0%. Squeak remained uninterruptable. After trying to manipulate windows, I started getting the debug window at the bottom of the Squeak window and it said over and over: WARNING: event buffer overflow This occurs with mouseMove. Anyone seen this behavior? Anyone have any ideas on what is wrong, or what I can do to debug further? Given the last situation, I am thinking this is NOT a SqueakElib problem. Thanks, Rob ---- |
On Tue, 13 Jul 2010, Rob Withers wrote:
> All, > > I am running Squeak 4.1 with Squeak4.0.2.exe VM on Windows. I downloaded it > from squeak.org 2 days ago. I have loaded Cryptography, SSL, and > SqueakElib. I am running SqueakElib as a server. > > My first indication of a problem is that the CPU goes to 100% and stays > there. Squeak is uninterruptable with <alt>-. Windows Task Manager shows > tat the problem is with Squeak. > > I opened the ProcessBrowser and turned on the CPUWatcher and ran the system. > When the problem occurs, after awhile the VM exits having run out of memory. > The crash.log says that the CPUWatcher was trying to catchThePig and it was > instantiating an Exception but failed due to no memory. (There were 10 or so > iterations of instantiating an exception). > > So I then went through all the SqueakElib code and made sure all Processes > were being created with userBackgroundPriority, so I could interrupt them if > they were the problem. I reran and reproduced the problem of the CPU going > to 100%. It remained uninterruptable. However, after hitting <alt>-. about > 20-30 times, the CPU usage went to 0%. Squeak remained uninterruptable. > After trying to manipulate windows, I started getting the debug window at the > bottom of the Squeak window and it said over and over: > > WARNING: event buffer overflow > > This occurs with mouseMove. > > Anyone seen this behavior? Anyone have any ideas on what is wrong, or what I > can do to debug further? Given the last situation, I am thinking this is NOT > a SqueakElib problem. Is the low space watcher process running? Are you running out of memory? How much memory does squeak use when the lockup occurs? Levente > > Thanks, > Rob > > ---- > > > > |
--------------------------------------------------
From: "Levente Uzonyi" <[hidden email]> Sent: Tuesday, July 13, 2010 9:19 AM To: "The general-purpose Squeak developers list" <[hidden email]> Subject: Re: [squeak-dev] UI lockup in Squeak 4.1 > On Tue, 13 Jul 2010, Rob Withers wrote: > >> All, >> >> I am running Squeak 4.1 with Squeak4.0.2.exe VM on Windows. I downloaded >> it from squeak.org 2 days ago. I have loaded Cryptography, SSL, and >> SqueakElib. I am running SqueakElib as a server. >> >> My first indication of a problem is that the CPU goes to 100% and stays >> there. Squeak is uninterruptable with <alt>-. Windows Task Manager >> shows tat the problem is with Squeak. >> >> I opened the ProcessBrowser and turned on the CPUWatcher and ran the >> system. When the problem occurs, after awhile the VM exits having run out >> of memory. The crash.log says that the CPUWatcher was trying to >> catchThePig and it was instantiating an Exception but failed due to no >> memory. (There were 10 or so iterations of instantiating an exception). >> >> So I then went through all the SqueakElib code and made sure all >> Processes were being created with userBackgroundPriority, so I could >> interrupt them if they were the problem. I reran and reproduced the >> problem of the CPU going to 100%. It remained uninterruptable. However, >> after hitting <alt>-. about 20-30 times, the CPU usage went to 0%. >> Squeak remained uninterruptable. After trying to manipulate windows, I >> started getting the debug window at the bottom of the Squeak window and >> it said over and over: >> >> WARNING: event buffer overflow >> >> This occurs with mouseMove. >> >> Anyone seen this behavior? Anyone have any ideas on what is wrong, or >> what I can do to debug further? Given the last situation, I am thinking >> this is NOT a SqueakElib problem. > > Is the low space watcher process running? Are you running out of memory? > How much memory does squeak use when the lockup occurs? > eventually run out of memory, but the uninterruptable state happens before this. I max out at 544,020 K memory allocated (according to Task Manager). I can watch it grow. I start at 62,068 K. This is new: Squeak stopped growing for awhile, at 534,000 K, although it was still at 100% cpu. I was able to select processes in the Process Browser, although very slowly. I attached the crash.dmp file. Rob > > Levente > >> >> Thanks, >> Rob >> >> ---- >> >> >> >> > crash.dmp (10K) Download Attachment |
On Tue, 13 Jul 2010, Rob Withers wrote:
> -------------------------------------------------- > From: "Levente Uzonyi" <[hidden email]> > Sent: Tuesday, July 13, 2010 9:19 AM > To: "The general-purpose Squeak developers list" > <[hidden email]> > Subject: Re: [squeak-dev] UI lockup in Squeak 4.1 > >> On Tue, 13 Jul 2010, Rob Withers wrote: >> >>> All, >>> >>> I am running Squeak 4.1 with Squeak4.0.2.exe VM on Windows. I downloaded >>> it from squeak.org 2 days ago. I have loaded Cryptography, SSL, and >>> SqueakElib. I am running SqueakElib as a server. >>> >>> My first indication of a problem is that the CPU goes to 100% and stays >>> there. Squeak is uninterruptable with <alt>-. Windows Task Manager >>> shows tat the problem is with Squeak. >>> >>> I opened the ProcessBrowser and turned on the CPUWatcher and ran the >>> system. When the problem occurs, after awhile the VM exits having run out >>> of memory. The crash.log says that the CPUWatcher was trying to >>> catchThePig and it was instantiating an Exception but failed due to no >>> memory. (There were 10 or so iterations of instantiating an exception). >>> >>> So I then went through all the SqueakElib code and made sure all Processes >>> were being created with userBackgroundPriority, so I could interrupt them >>> if they were the problem. I reran and reproduced the problem of the CPU >>> going to 100%. It remained uninterruptable. However, after hitting >>> <alt>-. about 20-30 times, the CPU usage went to 0%. Squeak remained >>> uninterruptable. After trying to manipulate windows, I started getting the >>> debug window at the bottom of the Squeak window and it said over and over: >>> >>> WARNING: event buffer overflow >>> >>> This occurs with mouseMove. >>> >>> Anyone seen this behavior? Anyone have any ideas on what is wrong, or >>> what I can do to debug further? Given the last situation, I am thinking >>> this is NOT a SqueakElib problem. >> >> Is the low space watcher process running? Are you running out of memory? >> How much memory does squeak use when the lockup occurs? >> > > The low-space watcher is running, at least before the problem starts. I do > eventually run out of memory, but the uninterruptable state happens before > this. I max out at 544,020 K memory allocated (according to Task Manager). > I can watch it grow. I start at 62,068 K. > > This is new: Squeak stopped growing for awhile, at 534,000 K, although it was > still at 100% cpu. I was able to select processes in the Process Browser, > although very slowly. The only problem I see here is that the low space watcher is not telling you that you're running out of memory, but this can happen if multiple processes try to allocate memory, since the low space watcher can only interrupt one process. If there's is no free memory available, the vm will try to free memory by collecting the garbage which causes the high cpu usage. If using more than 512MB is normal for your app then add more memory to squeak. If it's not, then it's a memory leak (probably in Smalltalk). Levente > > Rob > >> >> Levente >> >>> >>> Thanks, >>> Rob >>> >>> ---- >>> >>> >>> >>> >> |
In reply to this post by Rob Withers
On 7/13/2010 6:39 AM, Rob Withers wrote:
> The low-space watcher is running, at least before the problem starts. I > do eventually run out of memory, but the uninterruptable state happens > before this. In which case you want to do the following: * Launch your app and wait until it's in the "growing state" * Hit F2 and from the VM's preference menu choose "Debug" and then "Print all processes" This will dump a list of all the call stacks of all processes. One of them is the culprit consuming memory and you'll probably be able to tell quickly from just looking at it (if not, you can email the output here but it typically takes a domain expert to understand what's going wrong). Cheers, - Andreas |
-------------------------------------------------- From: "Andreas Raab" <[hidden email]> Sent: Tuesday, July 13, 2010 11:29 AM To: "The general-purpose Squeak developers list" <[hidden email]> Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 > On 7/13/2010 6:39 AM, Rob Withers wrote: >> The low-space watcher is running, at least before the problem starts. I >> do eventually run out of memory, but the uninterruptable state happens >> before this. > > In which case you want to do the following: > * Launch your app and wait until it's in the "growing state" > * Hit F2 and from the VM's preference menu choose "Debug" and then "Print > all processes" > > This will dump a list of all the call stacks of all processes. One of them > is the culprit consuming memory and you'll probably be able to tell > quickly from just looking at it (if not, you can email the output here but > it typically takes a domain expert to understand what's going wrong). > Thanks for this pointer, Andreas. This time it was a Cog VM which spasmed, which I use for my client (Squeak 4.1 for server for use with linux vm - I have no ability to compile a linux Cog vm: would love if someone posted one that could be launched headless for my webhost). It started running at 100% and I did your F2 -> Debug Options -> Print all processes. It started dumping a LOT to the Debug Console, then it froze, still at 100%, but no increase in memory now and it went (Not Responding) and greyed out the window. Luckily, I was able to see enough of the stack that was causing problems. It is infinitely looping in this method: LanguageEnvironment class>>#localeID: localeID ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID isoLanguage: 'en')] This has nothing to do with my code, except I must be calling something that enters this loop. It happens in both Cog (Windows) and Squeak4.1 (Linux <headless> and Windows). Not sure how to fix this. Rob > Cheers, > - Andreas > |
On 7/13/2010 8:57 AM, Rob Withers wrote:
> This time it was a Cog VM which spasmed, which I use for my client > (Squeak 4.1 for server for use with linux vm - I have no ability to > compile a linux Cog vm: would love if someone posted one that could be > launched headless for my webhost). > > It started running at 100% and I did your F2 -> Debug Options -> Print > all processes. It started dumping a LOT to the Debug Console, then it > froze, still at 100%, but no increase in memory now and it went (Not > Responding) and greyed out the window. > > Luckily, I was able to see enough of the stack that was causing > problems. It is infinitely looping in this method: > > LanguageEnvironment class>>#localeID: localeID > ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID > isoLanguage: 'en')] > > This has nothing to do with my code, except I must be calling something > that enters this loop. It happens in both Cog (Windows) and Squeak4.1 > (Linux <headless> and Windows). > > Not sure how to fix this. Debugging 101: Add a "self halt' in LanguageEnvironment and take it from there :-) Cheers, - Andreas |
--------------------------------------------------
From: "Andreas Raab" <[hidden email]> Sent: Tuesday, July 13, 2010 12:03 PM To: "The general-purpose Squeak developers list" <[hidden email]> Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 > On 7/13/2010 8:57 AM, Rob Withers wrote: > >> This time it was a Cog VM which spasmed, which I use for my client >> (Squeak 4.1 for server for use with linux vm - I have no ability to >> compile a linux Cog vm: would love if someone posted one that could be >> launched headless for my webhost). >> >> It started running at 100% and I did your F2 -> Debug Options -> Print >> all processes. It started dumping a LOT to the Debug Console, then it >> froze, still at 100%, but no increase in memory now and it went (Not >> Responding) and greyed out the window. >> >> Luckily, I was able to see enough of the stack that was causing >> problems. It is infinitely looping in this method: >> >> LanguageEnvironment class>>#localeID: localeID >> ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID >> isoLanguage: 'en')] >> >> This has nothing to do with my code, except I must be calling something >> that enters this loop. It happens in both Cog (Windows) and Squeak4.1 >> (Linux <headless> and Windows). >> >> Not sure how to fix this. > > Debugging 101: Add a "self halt' in LanguageEnvironment and take it from > there :-) :-) Ok, Things worked for awhile, then it started looping. I found that most of the registered environments, in KnownEnvironments, are now nil. This includes all Environments except for 'el' -> GreekEnvironment, 'ja-etoys' -> JapaneseEnvironment, 'ca' -> Latin1Environment and 'sq' -> Latin1Environment. Not sure why. > > Cheers, > - Andreas > |
In reply to this post by Rob Withers
On Tue, 13 Jul 2010, Rob Withers wrote:
> > -------------------------------------------------- > From: "Andreas Raab" <[hidden email]> > Sent: Tuesday, July 13, 2010 11:29 AM > To: "The general-purpose Squeak developers list" > <[hidden email]> > Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 > >> On 7/13/2010 6:39 AM, Rob Withers wrote: >>> The low-space watcher is running, at least before the problem starts. I >>> do eventually run out of memory, but the uninterruptable state happens >>> before this. >> >> In which case you want to do the following: >> * Launch your app and wait until it's in the "growing state" >> * Hit F2 and from the VM's preference menu choose "Debug" and then "Print >> all processes" >> >> This will dump a list of all the call stacks of all processes. One of them >> is the culprit consuming memory and you'll probably be able to tell quickly >> from just looking at it (if not, you can email the output here but it >> typically takes a domain expert to understand what's going wrong). >> > > Thanks for this pointer, Andreas. > > This time it was a Cog VM which spasmed, which I use for my client (Squeak > 4.1 for server for use with linux vm - I have no ability to compile a linux > Cog vm: would love if someone posted one that could be launched headless for > my webhost). Cog works, but i think you're trying to use the -headless switch, which (is deprecated) and tells the vm to use the X11 display, but with no window. Servers usually don't have X11, so it won't work. You better use -vm-display-null (and -vm-sound-null). Try squeak --help for further useful options (like tuning Cog). Levente > > It started running at 100% and I did your F2 -> Debug Options -> Print all > processes. It started dumping a LOT to the Debug Console, then it froze, > still at 100%, but no increase in memory now and it went (Not Responding) and > greyed out the window. > > Luckily, I was able to see enough of the stack that was causing problems. It > is infinitely looping in this method: > > LanguageEnvironment class>>#localeID: localeID > ^self knownEnvironments at: localeID ifAbsent: [self localeID: > (LocaleID isoLanguage: 'en')] > > This has nothing to do with my code, except I must be calling something that > enters this loop. It happens in both Cog (Windows) and Squeak4.1 (Linux > <headless> and Windows). > > Not sure how to fix this. > > Rob > >> Cheers, >> - Andreas >> > > |
In reply to this post by Rob Withers
--------------------------------------------------
From: "Rob Withers" <[hidden email]> Sent: Tuesday, July 13, 2010 12:34 PM To: "The general-purpose Squeak developers list" <[hidden email]> Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1 > -------------------------------------------------- > From: "Andreas Raab" <[hidden email]> > Sent: Tuesday, July 13, 2010 12:03 PM > To: "The general-purpose Squeak developers list" > <[hidden email]> > Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 > >> On 7/13/2010 8:57 AM, Rob Withers wrote: >> >>> This time it was a Cog VM which spasmed, which I use for my client >>> (Squeak 4.1 for server for use with linux vm - I have no ability to >>> compile a linux Cog vm: would love if someone posted one that could be >>> launched headless for my webhost). >>> >>> It started running at 100% and I did your F2 -> Debug Options -> Print >>> all processes. It started dumping a LOT to the Debug Console, then it >>> froze, still at 100%, but no increase in memory now and it went (Not >>> Responding) and greyed out the window. >>> >>> Luckily, I was able to see enough of the stack that was causing >>> problems. It is infinitely looping in this method: >>> >>> LanguageEnvironment class>>#localeID: localeID >>> ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID >>> isoLanguage: 'en')] >>> >>> This has nothing to do with my code, except I must be calling something >>> that enters this loop. It happens in both Cog (Windows) and Squeak4.1 >>> (Linux <headless> and Windows). >>> >>> Not sure how to fix this. >> >> Debugging 101: Add a "self halt' in LanguageEnvironment and take it from >> there :-) > > :-) Ok, Things worked for awhile, then it started looping. I found that > most of the registered environments, in KnownEnvironments, are now nil. > This includes all Environments except for 'el' -> GreekEnvironment, > 'ja-etoys' -> JapaneseEnvironment, 'ca' -> Latin1Environment and 'sq' -> > Latin1Environment. > > Not sure why. > I start the server and client with all known environments. At some later point in time, some of the environments change to nil and I start looping through the absent block of the dictionary lookup for localID:. It is not a #become situation, since we still have some Latin1Environment entries, and more than the Latin1Environment entries are changed to nil. There is only 2 references to LanguageEnvironment class>>#KnownEnvironments, which are LanguageEnvironment class>>#knownEnvironments and LanguageEnvironment class>>#resetKnownEnvironments. There is only one sender of LanguageEnvironment class>>#knownEnvironments, which is LanguageEnvironment class>>#localeID: There are two senders of LanguageEnvironment class>>#resetKnownEnvironments, which are NaturalLanguageTranslator>>#loadForLocaleIsoString:fromGzippedMimeLiteral: and NaturalLanguageTranslator>>#mergeTranslationFileNamed:. I have three images: echat1.image (a client), echat2.image (another client) and echat-server.image. I set 'self halt' in the absent block of #localeID: and in #resetKnownEnvironments in all images. I run the server and the 2 clients, connect the clients to the server and each other and then sit there. #KnownEnvironments have the correct environments. At some later time I try to copy text and #localID: self halt in the absent block gets called. #KnownEnvironments in that image now have nils. #resetKnownEnvironments never gets called. I am totally stumped. Rob >> >> Cheers, >> - Andreas >> > |
In reply to this post by Levente Uzonyi-2
--------------------------------------------------
From: "Levente Uzonyi" <[hidden email]> Sent: Tuesday, July 13, 2010 12:46 PM To: "The general-purpose Squeak developers list" <[hidden email]> Subject: Cog on linux (was: Re: [squeak-dev] Re: UI lockup in Squeak 4.1) > On Tue, 13 Jul 2010, Rob Withers wrote: > >> >> -------------------------------------------------- >> From: "Andreas Raab" <[hidden email]> >> Sent: Tuesday, July 13, 2010 11:29 AM >> To: "The general-purpose Squeak developers list" >> <[hidden email]> >> Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 >> >>> On 7/13/2010 6:39 AM, Rob Withers wrote: >>>> The low-space watcher is running, at least before the problem starts. I >>>> do eventually run out of memory, but the uninterruptable state happens >>>> before this. >>> >>> In which case you want to do the following: >>> * Launch your app and wait until it's in the "growing state" >>> * Hit F2 and from the VM's preference menu choose "Debug" and then >>> "Print all processes" >>> >>> This will dump a list of all the call stacks of all processes. One of >>> them is the culprit consuming memory and you'll probably be able to tell >>> quickly from just looking at it (if not, you can email the output here >>> but it typically takes a domain expert to understand what's going >>> wrong). >>> >> >> Thanks for this pointer, Andreas. >> >> This time it was a Cog VM which spasmed, which I use for my client >> (Squeak 4.1 for server for use with linux vm - I have no ability to >> compile a linux Cog vm: would love if someone posted one that could be >> launched headless for my webhost). > > Cog works, but i think you're trying to use the -headless switch, which > (is deprecated) and tells the vm to use the X11 display, but with no > window. Servers usually don't have X11, so it won't work. You better > use -vm-display-null (and -vm-sound-null). Try squeak --help for further > useful options (like tuning Cog). > I am trying to use the -headless switch. Good to know it is deprecated. So you happen to have a Cog for linux binary (version 17 - 20), which I could use? Thanks, Rob > > Levente > >> >> It started running at 100% and I did your F2 -> Debug Options -> Print >> all processes. It started dumping a LOT to the Debug Console, then it >> froze, still at 100%, but no increase in memory now and it went (Not >> Responding) and greyed out the window. >> >> Luckily, I was able to see enough of the stack that was causing problems. >> It is infinitely looping in this method: >> >> LanguageEnvironment class>>#localeID: localeID >> ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID >> isoLanguage: 'en')] >> >> This has nothing to do with my code, except I must be calling something >> that enters this loop. It happens in both Cog (Windows) and Squeak4.1 >> (Linux <headless> and Windows). >> >> Not sure how to fix this. >> >> Rob >> >>> Cheers, >>> - Andreas >>> >> >> > |
On Tue, 13 Jul 2010, Rob Withers wrote:
> -------------------------------------------------- > From: "Levente Uzonyi" <[hidden email]> > Sent: Tuesday, July 13, 2010 12:46 PM > To: "The general-purpose Squeak developers list" > <[hidden email]> > Subject: Cog on linux (was: Re: [squeak-dev] Re: UI lockup in Squeak 4.1) > >> On Tue, 13 Jul 2010, Rob Withers wrote: >> >>> >>> -------------------------------------------------- >>> From: "Andreas Raab" <[hidden email]> >>> Sent: Tuesday, July 13, 2010 11:29 AM >>> To: "The general-purpose Squeak developers list" >>> <[hidden email]> >>> Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 >>> >>>> On 7/13/2010 6:39 AM, Rob Withers wrote: >>>>> The low-space watcher is running, at least before the problem starts. I >>>>> do eventually run out of memory, but the uninterruptable state happens >>>>> before this. >>>> >>>> In which case you want to do the following: >>>> * Launch your app and wait until it's in the "growing state" >>>> * Hit F2 and from the VM's preference menu choose "Debug" and then "Print >>>> all processes" >>>> >>>> This will dump a list of all the call stacks of all processes. One of >>>> them is the culprit consuming memory and you'll probably be able to tell >>>> quickly from just looking at it (if not, you can email the output here >>>> but it typically takes a domain expert to understand what's going wrong). >>>> >>> >>> Thanks for this pointer, Andreas. >>> >>> This time it was a Cog VM which spasmed, which I use for my client (Squeak >>> 4.1 for server for use with linux vm - I have no ability to compile a >>> linux Cog vm: would love if someone posted one that could be launched >>> headless for my webhost). >> >> Cog works, but i think you're trying to use the -headless switch, which (is >> deprecated) and tells the vm to use the X11 display, but with no window. >> Servers usually don't have X11, so it won't work. You better use >> -vm-display-null (and -vm-sound-null). Try squeak --help for further useful >> options (like tuning Cog). >> > > I am trying to use the -headless switch. Good to know it is deprecated. So > you happen to have a Cog for linux binary (version 17 - 20), which I could > use? I have one, but I'm not sure it will work on your server. You can find it here: http://leves.web.elte.hu/squeak/cog17.tar.gz . It's built on ubuntu 10.04 and is optimized for core2. Levente > > Thanks, > Rob > >> >> Levente >> >>> >>> It started running at 100% and I did your F2 -> Debug Options -> Print all >>> processes. It started dumping a LOT to the Debug Console, then it froze, >>> still at 100%, but no increase in memory now and it went (Not Responding) >>> and greyed out the window. >>> >>> Luckily, I was able to see enough of the stack that was causing problems. >>> It is infinitely looping in this method: >>> >>> LanguageEnvironment class>>#localeID: localeID >>> ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID >>> isoLanguage: 'en')] >>> >>> This has nothing to do with my code, except I must be calling something >>> that enters this loop. It happens in both Cog (Windows) and Squeak4.1 >>> (Linux <headless> and Windows). >>> >>> Not sure how to fix this. >>> >>> Rob >>> >>>> Cheers, >>>> - Andreas >>>> >>> >>> >> > > |
Thanks Levente. Unfortunately it did not work: ./lib/squeak/3.9-7/squeak: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./lib/squeak/3.9-7/squeak) Rob From: Levente Uzonyi <[hidden email]> To: The general-purpose Squeak developers list <[hidden email]> Sent: Tue, July 13, 2010 3:21:43 PM Subject: Re: Cog on linux (was: Re: [squeak-dev] Re: UI lockup in Squeak 4.1) On Tue, 13 Jul 2010, Rob Withers wrote: > -------------------------------------------------- > From: "Levente Uzonyi" <[hidden email]> > Sent: Tuesday, July 13, 2010 12:46 PM > To: "The general-purpose Squeak developers list" <[hidden email]> > Subject: Cog on linux (was: Re: [squeak-dev] Re: UI lockup in Squeak 4.1) > >> On Tue, 13 Jul 2010, Rob Withers wrote: >> >>> >>> -------------------------------------------------- >>> From: "Andreas Raab" <[hidden email]> >>> Sent: Tuesday, July 13, 2010 11:29 AM >>> To: "The general-purpose Squeak developers list" <[hidden email]> >>> Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 >>> >>>> On 7/13/2010 6:39 AM, Rob Withers wrote: >>>>> The low-space watcher is running, at least before the problem starts. I >>>>> do eventually run out of memory, but the uninterruptable state happens >>>>> before this. >>>> >>>> In which case you want to do the following: >>>> * Launch your app and wait until it's in the "growing state" >>>> * Hit F2 and from the VM's preference menu choose "Debug" and then "Print all processes" >>>> >>>> This will dump a list of all the call stacks of all processes. One of them is the culprit consuming memory and you'll probably be able to tell quickly from just looking at it (if not, you can email the output here but it typically takes a domain expert to understand what's going wrong). >>>> >>> >>> Thanks for this pointer, Andreas. >>> >>> This time it was a Cog VM which spasmed, which I use for my client (Squeak 4.1 for server for use with linux vm - I have no ability to compile a linux Cog vm: would love if someone posted one that could be launched headless for my webhost). >> >> Cog works, but i think you're trying to use the -headless switch, which (is deprecated) and tells the vm to use the X11 display, but with no window. Servers usually don't have X11, so it won't work. You better use -vm-display-null (and -vm-sound-null). Try squeak --help for further useful options (like tuning Cog). >> > > I am trying to use the -headless switch. Good to know it is deprecated. So you happen to have a Cog for linux binary (version 17 - 20), which I could use? I have one, but I'm not sure it will work on your server. You can find it here: http://leves.web.elte.hu/squeak/cog17.tar.gz . It's built on ubuntu 10.04 and is optimized for core2. Levente > > Thanks, > Rob > >> >> Levente >> >>> >>> It started running at 100% and I did your F2 -> Debug Options -> Print all processes. It started dumping a LOT to the Debug Console, then it froze, still at 100%, but no increase in memory now and it went (Not Responding) and greyed out the window. >>> >>> Luckily, I was able to see enough of the stack that was causing problems. It is infinitely looping in this method: >>> >>> LanguageEnvironment class>>#localeID: localeID >>> ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID isoLanguage: 'en')] >>> >>> This has nothing to do with my code, except I must be calling something that enters this loop. It happens in both Cog (Windows) and Squeak4.1 (Linux <headless> and Windows). >>> >>> Not sure how to fix this. >>> >>> Rob >>> >>>> Cheers, >>>> - Andreas >>>> >>> >>> >> > > |
In reply to this post by Rob Withers
Rob,
put a breakpoint in the code that grows the heap (uxGrowMemoryBy?), let the heap grow to, say, 250Mb and then do (gdb) call printCallStack()
to find out what's causing the growth. Chances are you'll find your infinite recursion. HTH Eliot On Tue, Jul 13, 2010 at 11:42 AM, Rob Withers <[hidden email]> wrote: -------------------------------------------------- |
Hi Eliot, I already found it. It is this method, when the result of the dictionary lookup is nil for 'en', and it recursively calls localeID: with 'en'. LanguageEnvironment class>>#localeID: localeID ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID isoLanguage: 'en')] I start the image with an intact KnownEnvironments. Something somehow nils out the entries after I have run for awhile. ?????? Thanks, Rob From: Eliot Miranda <[hidden email]> To: The general-purpose Squeak developers list <[hidden email]> Sent: Tue, July 13, 2010 3:53:11 PM Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1 Rob, put a breakpoint in the code that grows the heap (uxGrowMemoryBy?), let the heap grow to, say, 250Mb and then do (gdb) call printCallStack()
to find out what's causing the growth. Chances are you'll find your infinite recursion. HTH Eliot On Tue, Jul 13, 2010 at 11:42 AM, Rob Withers <[hidden email]> wrote: -------------------------------------------------- |
On Tue, Jul 13, 2010 at 12:59 PM, Rob Withers <[hidden email]> wrote:
Doh!
which clearly needs to read something like LanguageEnvironment class>>#localeID: localeID
^self knownEnvironments at: localeID
ifAbsent: [self knownEnvironments at: (LocaleID isoLanguage: 'en')]
So guard against resetKnownEnvironments?
|
> From: Eliot Miranda > Sent: Tuesday, July 13, 2010 4:11 PM > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1 > > > > > > > On Tue, Jul 13, 2010 at 12:59 PM, Rob Withers <[hidden email]> > > wrote: > > > > Hi Eliot, > > > > > > I already found it. > > > > Doh! > > > It is this method, when the result of the dictionary lookup is nil for > > 'en', and it recursively calls localeID: with 'en'. > > > > > > LanguageEnvironment class>>#localeID: localeID > > ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID > > isoLanguage: 'en')] > > > > > which clearly needs to read something like > LanguageEnvironment class>>#localeID: localeID > ^self knownEnvironments > at: localeID > ifAbsent: [self knownEnvironments at: (LocaleID isoLanguage: > 'en')] > The problem is that something changed the entry for 'en' from Latin1Environment to nil. So the absent block will still fail, although this time as an Error and not a recursive, memory-growing loop. I had in mind: LanguageEnvironment class>>#localeID: localeID ^self knownEnvironments at: localeID ifAbsent: [ | env id | env := Latin1Environment new. id := LocaleID isoString: 'en'. env localeID: id. self knownEnvironments at: id put: env. ^ env]. > > > I start the image with an intact KnownEnvironments. Something somehow > > nils out the entries after I > > > have run for awhile. ?????? > > > > So guard against resetKnownEnvironments? I had a 'self halt' and it never got called. I have no idea how it was nilling out the entries. Rob |
On Tue, Jul 13, 2010 at 1:53 PM, Rob Withers <[hidden email]> wrote:
LanguageEnvironment class>>#localeID: localeID ^self knownEnvironments at: localeID ifAbsent: [self knownEnvironments at: (LocaleID isoLanguage: 'en')
ifAbsentPut: [Latin1Environment new
localeID: (LocaleID isoString: 'en');
yourself]]
No?
Are there any senders of knownEnvironments and removeKey: et al? Do you have changes to Dictionary grow code which causes a bug on rehash? etc...
|
In reply to this post by Rob Withers
On Tue, 13 Jul 2010, Rob Withers wrote:
> Thanks Levente. Unfortunately it did not work: > > ./lib/squeak/3.9-7/squeak: /lib/libc.so.6: version `GLIBC_2.11' not found (required by ./lib/squeak/3.9-7/squeak) Seems like you have to build it yourself. Fortunately it's very easy, since Eliot commits the generated sources to the svn repo. So you can build a CogVM/StackVM without VMMaker. Here is how: "How to build the Cog Croquet VM on Unix ------------------------------- 1. Install the tools (gcc, X11-devel, etc (e.g. libpng, libX11 & libxt source)) 2. Check out the following sources from svn (if you haven't already - if you're reading this in unixbuild its likely you've already got the sources) svn co http://www.squeakvm.org/svn/squeak/branches/Cog/platforms svn co http://www.squeakvm.org/svn/squeak/branches/Cog/src svn co http://www.squeakvm.org/svn/squeak/branches/Cog/unixbuild 3. Open a shell, cd into the unixbuild/bld directory and execute ../../platforms/unix/config/configure CFLAGS="-g -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DCOGMTVM=0" LIBS=-lpthread make install prefix=WhereYouWantTheVmToGo 4. At the end of it you'll get a new VM in the path provided via -prefix" Levente > > Rob > > > > ________________________________ > From: Levente Uzonyi <[hidden email]> > To: The general-purpose Squeak developers list <[hidden email]> > Sent: Tue, July 13, 2010 3:21:43 PM > Subject: Re: Cog on linux (was: Re: [squeak-dev] Re: UI lockup in Squeak 4.1) > > On Tue, 13 Jul 2010, Rob Withers wrote: > >> -------------------------------------------------- >> From: "Levente Uzonyi" <[hidden email]> >> Sent: Tuesday, July 13, 2010 12:46 PM >> To: "The general-purpose Squeak developers list" <[hidden email]> >> Subject: Cog on linux (was: Re: [squeak-dev] Re: UI lockup in Squeak 4.1) >> >>> On Tue, 13 Jul 2010, Rob Withers wrote: >>> >>>> >>>> -------------------------------------------------- >>>> From: "Andreas Raab" <[hidden email]> >>>> Sent: Tuesday, July 13, 2010 11:29 AM >>>> To: "The general-purpose Squeak developers list" <[hidden email]> >>>> Subject: [squeak-dev] Re: UI lockup in Squeak 4.1 >>>> >>>>> On 7/13/2010 6:39 AM, Rob Withers wrote: >>>>>> The low-space watcher is running, at least before the problem starts. I >>>>>> do eventually run out of memory, but the uninterruptable state happens >>>>>> before this. >>>>> >>>>> In which case you want to do the following: >>>>> * Launch your app and wait until it's in the "growing state" >>>>> * Hit F2 and from the VM's preference menu choose "Debug" and then "Print all processes" >>>>> >>>>> This will dump a list of all the call stacks of all processes. One of them is the culprit consuming memory and you'll probably be able to tell quickly from just looking at it (if not, you can email the output here but it typically takes a domain expert to understand what's going wrong). >>>>> >>>> >>>> Thanks for this pointer, Andreas. >>>> >>>> This time it was a Cog VM which spasmed, which I use for my client (Squeak 4.1 for server for use with linux vm - I have no ability to compile a linux Cog vm: would love if someone posted one that could be launched headless for my webhost). >>> >>> Cog works, but i think you're trying to use the -headless switch, which (is deprecated) and tells the vm to use the X11 display, but with no window. Servers usually don't have X11, so it won't work. You better use -vm-display-null (and -vm-sound-null). Try squeak --help for further useful options (like tuning Cog). >>> >> >> I am trying to use the -headless switch. Good to know it is deprecated. So you happen to have a Cog for linux binary (version 17 - 20), which I could use? > > I have one, but I'm not sure it will work on your server. You can find it here: http://leves.web.elte.hu/squeak/cog17.tar.gz . It's built on ubuntu 10.04 and is optimized for core2. > > > Levente > >> >> Thanks, >> Rob >> >>> >>> Levente >>> >>>> >>>> It started running at 100% and I did your F2 -> Debug Options -> Print all processes. It started dumping a LOT to the Debug Console, then it froze, still at 100%, but no increase in memory now and it went (Not Responding) and greyed out the window. >>>> >>>> Luckily, I was able to see enough of the stack that was causing problems. It is infinitely looping in this method: >>>> >>>> LanguageEnvironment class>>#localeID: localeID >>>> ^self knownEnvironments at: localeID ifAbsent: [self localeID: (LocaleID isoLanguage: 'en')] >>>> >>>> This has nothing to do with my code, except I must be calling something that enters this loop. It happens in both Cog (Windows) and Squeak4.1 (Linux <headless> and Windows). >>>> >>>> Not sure how to fix this. >>>> >>>> Rob >>>> >>>>> Cheers, >>>>> - Andreas >>>>> >>>> >>>> >>> >> >> |
In reply to this post by Eliot Miranda-2
> From: Eliot Miranda > Sent: Tuesday, July 13, 2010 5:03 PM > To: The general-purpose Squeak developers list > Subject: Re: [squeak-dev] Re: UI lockup in Squeak 4.1 > > > > > LanguageEnvironment class>>#localeID: localeID > ^self knownEnvironments > at: localeID > ifAbsent: [self knownEnvironments > at: (LocaleID isoLanguage: 'en') > ifAbsentPut: > [Latin1Environment new > localeID: (LocaleID isoString: 'en'); > yourself]] > > No? > It works. #isoLanguage: and #isoString: are the same for 'en'. Both call #isoLanguage:isoCountry:, where country is nil. I like your use of at:ifAbsentPut: much better. :-) > Are there any senders of knownEnvironments and removeKey: et al? Do you > have changes to Dictionary grow code which causes a bug on rehash? etc... > No, there is only one sender of knownEnvironments and that is localeID:. No, but I force rehashing when one of my ERefs becomes another ERef. I am testing this. I do not think I have any ERef references to an Environment or that dictionary. Rob |
Free forum by Nabble | Edit this page |