vw7.7.1nc can't find source on Windows
Locked
12
12
vw7.7.1nc can't find source on Windows
 
|
I have an image that I created under Linux but would now like to use
under Windows. The image is not hooking up with visual.sou. I think initially it could not find the file at all; now the class comments are blank and method source says (Object>>at:put:) " ***This is decompiled code.*** The source was unavailable because the source pointer appears to point to an incorrect position in the file. The file may have been modified after this method was updated." Any suggestions how to fix this? Among other things I have used the "set visual works home" in the GUI, with or without "paste current" (the latter seems to give my working directory, not the root). I have created a project in the project launcher and copied the image to it. I started the image without the project launcher. I executed SourceFileManager default sourceFileName:. I edited the registry. Currently set visual works home shows c:\Program Files\Cincom\vw7.7.1nc\, which I think is what it should be (also tried without the final \, and with / and with \\). It is possible the image began with a slightly different version, e.g., 7.7. I recall one install off CD was followed by a huge update. Running Vista 32 bit. A couple of side issues: What is the right way to handle an existing image with the new VisualWorks Projects launcher in Windows? I'm running in Windows because the image, created under Debian Lenny, will not launch successfully in Debian squeeze. Image is about 36MB on disk. Attempted launch produces 100% CPU utilitization, a largish use of memory (~500MB), no windows popping up, and, after a long time, a crash (but not because of OS-level memory exhaustion). The stock image launches successfully under squeeze. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows
|
|
> I'm running in Windows because the image, created under Debian Lenny,
> will not launch successfully in Debian squeeze. Image is about 36MB on > disk. Attempted launch produces 100% CPU utilitization, a largish use > of memory (~500MB), no windows popping up, and, after a long time, a > crash (but not because of OS-level memory exhaustion). The stock image > launches successfully under squeeze. Can you please run that image that won't start correctly with a debug VM and post any output to the console? Also, run the VM with the -xq switch. This should produce a file called stack.txt. I'd like to see that too. Andres. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
On 8/11/2011 11:58 AM, Andres Valloud wrote:
>> I'm running in Windows because the image, created under Debian Lenny, >> will not launch successfully in Debian squeeze. Image is about 36MB on >> disk. Attempted launch produces 100% CPU utilitization, a largish use >> of memory (~500MB), no windows popping up, and, after a long time, a >> crash (but not because of OS-level memory exhaustion). The stock image >> launches successfully under squeeze. > Can you please run that image that won't start correctly with a debug VM > and post any output to the console? Where do I find the debug VM? > Also, run the VM with the -xq > switch. -xq is for the debug VM or regular? > This should produce a file called stack.txt. I'd like to see > that too. > > Andres. Would the output of ldd be useful too? Ross > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
[vw 7.6] InputField of type Object
|
|
Hi,
I wish to have an input field set up in a window which is of type Object. My aim #1 is to set one of my classes (say MyTestInputField) as the default object of the input field and display on the input field the value set in the instance variable instVar1. (This i am able to do with vw7.4.1 using the #displayString message,but not in 7.6) my aim #2 is to set the instVar1 with the value inserted in the inputField (get always aMyTestInputField in the inputField value holder and the user input in the instVar1 of that object) can some one help? Simon displays _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows
|
|
In reply to this post by Ross Boylan
You can find where it
thinks any of the source files are by looking in the settings, under
System->Source->Source Files. Normally it's going to look for it
in $(VISUALWORKS)/image/visual.sou. If that file isn't there or isn't
the appropriate one for the image, then you'll get decompiled code.
Being the appropriate one includes coming from the same release. If your
image was 7.7 and the source file is 7.7.1, or vice versa, the source
pointers won't be correct and you'll get decompiled code. Probably the
simplest thing is to copy the one from the Linux side if it worked. Make
sure that you copy it in a way that preserves the file precisely.
Copying methods which attempt to convert line end conventions for you
will make the file useless.
With the project launcher, the simplest thing would probably be to create a new project called ForMyOldImage, then copy your image into the resulting project directory over top of the image created by the launcher. There's nothing special about the images it creates, it just puts them somewhere that it knows where to find them.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Ross Boylan-2
On Thu, 2011-08-11 at 12:21 -1000, Ross Boylan wrote:
> On 8/11/2011 11:58 AM, Andres Valloud wrote: > >> I'm running in Windows because the image, created under Debian Lenny, > >> will not launch successfully in Debian squeeze. Image is about 36MB on > >> disk. Attempted launch produces 100% CPU utilitization, a largish use > >> of memory (~500MB), no windows popping up, and, after a long time, a > >> crash (but not because of OS-level memory exhaustion). The stock image > >> launches successfully under squeeze. > > Can you please run that image that won't start correctly with a debug VM > > and post any output to the console? > Where do I find the debug VM? /usr/local/src/vw7.7.1nc$ bin/linux86/debug/vwlinux86dbg ross.im For ~5 hours it used all CPU and slowly increased in memory useage. Since then (total of ~14 hours since launch) it has no CPU useage and is holding at 512.6M. There was no output on the terminal until I copied the command line above, at which point ^[[A^[[A^[[A appeared. I think that was random stuff from me hitting keys, not the program. I don't see anything plausible in .xsession-errors or the logs. debug.log is empty. It's possible the CPU useage went quiet before the crash with the regular VM. Should I keep this running? Attach a debugger to it? > > Also, run the VM with the -xq > > switch. > -xq is for the debug VM or regular? still wondering about this. > > This should produce a file called stack.txt. I'd like to see > > that too. > > > > Andres. > Would the output of ldd be useful too? Here it is, just in case: ross@cotton:/usr/local/src/vw7.7.1nc$ ldd bin/linux86/visual linux-gate.so.1 => (0xb7860000) libX11.so.6 => /usr/lib/libX11.so.6 (0xb772e000) libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7715000) librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb770b000) libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7707000) libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb76e1000) libz.so.1 => /usr/lib/libz.so.1 (0xb76cd000) libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7587000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb756d000) /lib/ld-linux.so.2 (0xb7861000) libXau.so.6 => /usr/lib/libXau.so.6 (0xb756a000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7565000) > Ross > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows [solved]
|
|
In reply to this post by Alan Knight-2
On 8/12/2011 3:49 AM, Alan Knight wrote:
You can find where it thinks any of the source files are by looking in the settings, under System->Source->Source Files. Normally it's going to look for it in $(VISUALWORKS)/image/visual.sou. If that file isn't there or isn't the appropriate one for the image, then you'll get decompiled code. Being the appropriate one includes coming from the same release. If your image was 7.7 and the source file is 7.7.1, or vice versa, the source pointers won't be correcteThat's the one. The image was created with 7.7. I took the visual.sou file from 7.7, put it in the same directory as my image, and executed SourceFileManager default sourcesFileName: 'c:\Users\ross\Documents\MedIns\visual7.7nc.sou' (I renamed the source file). Now everything is good. So how does one migrate an image between releases? Thanks very much for the help. Ross P.S. My side issue of the image not running in Debian squeeze is still unresolved; at least I can run it somewhere! and you'll get decompiled code. Probably the simplest thing is to copy the one from the Linux side if it worked. Make sure that you copy it in a way that preserves the file precisely. Copying methods which attempt to convert line end conventions for you will make the file useless. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows [solved]
|
|
Typically one doesn't
migrate an image between releases, one migrates the code.
So, e.g. publish the code into Store from a 7.7.1 image, load it into an 7.8 image, and run it from there. This has the additional advantage of making sure that your code can be loaded into a clean image, and if the image gets into a state from which it can't be opened, it's not difficult to be rebuild it. It is possible to ugprade an image between releases, at least most of the time. Just load the newer versions of all of the base packages and all of the other packages you're using. However, it's still necessary to use the .sou file from the release that the image came from, because loading that new code doesn't change anything about that, it just means that any changed methods will have their source in the changes file, not in the sources. Also, it's not always possible to load the newer versions, particularly with core components like Base VisualWorks. Smalltalk is a live system, so when the new code is being loaded, Smalltalk code is running using that code. For example, not that long ago we had a release that made significant changes to the way hashing worked. You can't just load that code into an older image because the older image would have many sets, dictionaries, and other objects that had been created using the old hashing, and would give incorrect answers using the new unless they were rehashed. And many of those objects are used in the process of loading code. So, as soon as you, say, installed code in the system which changed the way that class names and method selectors were looked up, any code that did those things would fail. The code that installs code in the system has to do that, so it will fail, and now you have a badly broken system. The newer loaders in Store are much more robust with those sorts of conditions, but there are still quite a few things (like that change to hashing) that are unlikely to be loadable without doing it very carefully. In the case of the example with the hashing we did that by having a number of different versions which had to be loaded in sequence, and each of which still left the system in a stable state while moving towards the new mechanism. But we don't ship that code.
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows [solved]
|
|
On 8/15/2011 6:58 AM, Alan Knight wrote:
> Typically one doesn't migrate an image between releases, one migrates > the code. What about the data and other interesting stuff in the image? Ross _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
|
|
Well, data should ideally something you load in at runtime, not something you persist in the image over time.
Having said that, you can use BOSS to dump data out of an image and reload it into another. Unless your starting point is way back (sometime in the 5i or earlier era), then you should be able to BOSS out of the current and into 7.8 On Aug 15, 2011, at 2:20 PM, Ross Boylan wrote: > On 8/15/2011 6:58 AM, Alan Knight wrote: >> Typically one doesn't migrate an image between releases, one migrates >> the code. > What about the data and other interesting stuff in the image? > Ross > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc James Robertson http://www.jarober.com [hidden email] _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows [solved]
|
|
In reply to this post by Ross Boylan-2
On Mon, Aug 15, 2011 at 1:20 PM, Ross Boylan
<[hidden email]> wrote: > On 8/15/2011 6:58 AM, Alan Knight wrote: >> Typically one doesn't migrate an image between releases, one migrates >> the code. > What about the data and other interesting stuff in the image? Don't be seduced by the image. Images make many things very easy. It is easy to treat them like a database, to just save your work by saving the image. This is easy in the short run, dangerous in the long run. It is not possible to merge images. Eventually something will break in your image, and you might not have an earlier working version. My rule is to build a new image every week. I make sure that I can save all data outside the image. It takes work to write data input/export unless I just save binary versions of objects. I used to think this was a problem unique to Smalltalk. But I've seen people do the same things with vmware. They make a vmware image that they then distribute, and they make improvements to their system by editing an image and then saving it again. I've also been on projects that used a database where the database was configured by hand and just copied from installation to installation, and nobody knew for sure how to configure a new database other than by copying the old one. So it is a general problem, and Smalltalk images are just another example. But expert Smalltalkers understand it as well as anybody. This is a kind of biological propagation; creation by reproduction. But even though researchers often try to make engineered systems more like biological systems, this is one place where we usually shouldn't want to. If we are going to understand the systems we create, we need to create them from understandable parts, and have a reproducible process for creating them. A lot of the current work on modularizing and shrinking Smalltalk (well, I don't know if people still worry about that in VisualWorks, but the Squeak people are still working on that) is due to trying to make the system more understandable and more reproducible. -Ralph Johnson _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc can't find source on Windows [solved]
|
|
+100
Also, you need to consider what happens when people leave and the responsibility for maintaining the system falls to a new person. Having everything reproducible from source at least ensures the build documentation, i.e. the source, is accurate and gives a new person a solid place to start from. Terry =========================================================== Terry Raymond Crafted Smalltalk 80 Lazywood Ln. Tiverton, RI 02878 (401) 624-4517 [hidden email] <http://www.craftedsmalltalk.com> =========================================================== > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Ralph Johnson > Sent: Monday, August 15, 2011 2:45 PM > To: Ross Boylan > Cc: VWNC NC > Subject: Re: [vwnc] vw7.7.1nc can't find source on Windows [solved] > > On Mon, Aug 15, 2011 at 1:20 PM, Ross Boylan > <[hidden email]> wrote: > > On 8/15/2011 6:58 AM, Alan Knight wrote: > >> Typically one doesn't migrate an image between releases, one migrates > >> the code. > > What about the data and other interesting stuff in the image? > > Don't be seduced by the image. > > Images make many things very easy. It is easy to treat them like a > database, to just save your work by saving the image. This is easy in > the short run, dangerous in the long run. It is not possible to > merge images. Eventually something will break in your image, and > you might not have an earlier working version. > > My rule is to build a new image every week. I make sure that I can > save all data outside the image. It takes work to write data > input/export unless I just save binary versions of objects. > > I used to think this was a problem unique to Smalltalk. But I've > seen people do the same things with vmware. They make a vmware image > that they then distribute, and they make improvements to their system > by editing an image and then saving it again. I've also been on > projects that used a database where the database was configured by > hand and just copied from installation to installation, and nobody > knew for sure how to configure a new database other than by copying > the old one. So it is a general problem, and Smalltalk images are > just another example. But expert Smalltalkers understand it as well > as anybody. > > This is a kind of biological propagation; creation by reproduction. > But even though researchers often try to make engineered systems more > like biological systems, this is one place where we usually shouldn't > want to. If we are going to understand the systems we create, we > need to create them from understandable parts, and have a reproducible > process for creating them. A lot of the current work on modularizing > and shrinking Smalltalk (well, I don't know if people still worry > about that in VisualWorks, but the Squeak people are still working on > that) is due to trying to make the system more understandable and more > reproducible. > > -Ralph Johnson > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Ross Boylan-3
I started the program with vmlinux86dbg -o11s about 4.5 days ago. It
continues to run, spitting out messages on the launching terminal like checkMarksInOt: incremenal GC was conservative by xxx objects. It uses all of one CPU, and has slowly grown to 442M. Since the process is 51M when it runs successfully on lenny, and the image file is 37M on disk, something has likely already gone very wrong. I attached the debugger to it, but I am unable to reattach. When I do so, I get the message Attaching to program ... Cannot access memory at address xxxx A program is being debugged already. Kill it? (y or n) I say n, and then the debugger just sits there; ps shows the program (vmlinux86dbg) is stopped. If I kill the debugger process, the vm resumes execution. There are no other gdb processes. Can anyone suggest what to do? I'm running gdb 7.0.1-debian under emacs 23.2.1. I suspect this problem arises because I initially attached using the wrong path to the program, as a result of which it said no symbols were found. I may also have made some attempts to debug specifying the wrong vm (7.7 vs the 7.7.1 vm that is actually running). Searching the net on the Kill it? message shows nothing that looks particularly relevant; some people respond y, which I assume would lose 4.5 days work; and others respond n and get a gdb prompt. I don't get a gdb prompt, nor does sending ^c (via typing it twice in emacs) do anything. Ross On Fri, 2011-08-12 at 08:14 -1000, Ross Boylan wrote: > On Thu, 2011-08-11 at 12:21 -1000, Ross Boylan wrote: > > On 8/11/2011 11:58 AM, Andres Valloud wrote: > > >> I'm running in Windows because the image, created under Debian Lenny, > > >> will not launch successfully in Debian squeeze. Image is about 36MB on > > >> disk. Attempted launch produces 100% CPU utilitization, a largish use > > >> of memory (~500MB), no windows popping up, and, after a long time, a > > >> crash (but not because of OS-level memory exhaustion). The stock image > > >> launches successfully under squeeze. > > > Can you please run that image that won't start correctly with a debug VM > > > and post any output to the console? > > Where do I find the debug VM? > I did > /usr/local/src/vw7.7.1nc$ bin/linux86/debug/vwlinux86dbg ross.im > For ~5 hours it used all CPU and slowly increased in memory useage. > Since then (total of ~14 hours since launch) it has no CPU useage and > is holding at 512.6M. There was no output on the terminal until I > copied the command line above, at which point > ^[[A^[[A^[[A > appeared. I think that was random stuff from me hitting keys, not the > program. > I don't see anything plausible in .xsession-errors or the logs. > debug.log is empty. > > It's possible the CPU useage went quiet before the crash with the > regular VM. > > Should I keep this running? Attach a debugger to it? > > > > Also, run the VM with the -xq > > > switch. > > -xq is for the debug VM or regular? > still wondering about this. > > > This should produce a file called stack.txt. I'd like to see > > > that too. > > > > > > Andres. > > Would the output of ldd be useful too? > Here it is, just in case: > ross@cotton:/usr/local/src/vw7.7.1nc$ ldd bin/linux86/visual > linux-gate.so.1 => (0xb7860000) > libX11.so.6 => /usr/lib/libX11.so.6 (0xb772e000) > libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7715000) > librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb770b000) > libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7707000) > libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb76e1000) > libz.so.1 => /usr/lib/libz.so.1 (0xb76cd000) > libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7587000) > libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb756d000) > /lib/ld-linux.so.2 (0xb7861000) > libXau.so.6 => /usr/lib/libXau.so.6 (0xb756a000) > libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7565000) > > Ross > > > > > > _______________________________________________ > > > vwnc mailing list > > > [hidden email] > > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
Hi Ross
try to launch the image with vmlinux86dbg -o10s visual.im > debug.log All message sends will be printed to stdout. I assume that there is an infinite recursion, which should be diagnosable by looking at the output. If it's a headfull image, my buest guess is an infinite debugger recursion. You might want to try to add the following parcel to the image and run it on Squeeze: http://dl.dropbox.com/u/21555916/StartupPatch.zip it will create an error.log file when the windowing system is not active. On 23.08.2011 06:33, Ross Boylan wrote: > I started the program with vmlinux86dbg -o11s about 4.5 days ago. It > continues to run, spitting out messages on the launching terminal like > checkMarksInOt: incremenal GC was conservative by xxx objects. > It uses all of one CPU, and has slowly grown to 442M. > > Since the process is 51M when it runs successfully on lenny, and the > image file is 37M on disk, something has likely already gone very wrong. > > I attached the debugger to it, but I am unable to reattach. When I do > so, I get the message > Attaching to program ... > Cannot access memory at address xxxx > A program is being debugged already. Kill it? (y or n) _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
StartupPatch.pcl (2K)
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Ross Boylan
I take it that if you save the image while the VM process is using so
much memory, the resulting file will be on the order of 37M, right? I'd try figuring out the gdb attaching issues, and from then examining the C heap to see what is allocated. With -o11s, it's normal that the CPU uses 100% all the time. Due to extended checks, the IGC can't make progress from the idle loop. Go to the idle loop process method, comment out the IGC calls, and shut down the IGC by doing a GC. On 8/22/2011 9:33 PM, Ross Boylan wrote: > I started the program with vmlinux86dbg -o11s about 4.5 days ago. It > continues to run, spitting out messages on the launching terminal like > checkMarksInOt: incremenal GC was conservative by xxx objects. > It uses all of one CPU, and has slowly grown to 442M. > > Since the process is 51M when it runs successfully on lenny, and the > image file is 37M on disk, something has likely already gone very wrong. > > I attached the debugger to it, but I am unable to reattach. When I do > so, I get the message > Attaching to program ... > Cannot access memory at address xxxx > A program is being debugged already. Kill it? (y or n) > > I say n, and then the debugger just sits there; ps shows the program > (vmlinux86dbg) is stopped. If I kill the debugger process, the vm > resumes execution. There are no other gdb processes. > > Can anyone suggest what to do? > > I'm running gdb 7.0.1-debian under emacs 23.2.1. I suspect this problem > arises because I initially attached using the wrong path to the program, > as a result of which it said no symbols were found. I may also have > made some attempts to debug specifying the wrong vm (7.7 vs the 7.7.1 vm > that is actually running). > > Searching the net on the Kill it? message shows nothing that looks > particularly relevant; some people respond y, which I assume would lose > 4.5 days work; and others respond n and get a gdb prompt. I don't get a > gdb prompt, nor does sending ^c (via typing it twice in emacs) do > anything. > > Ross > On Fri, 2011-08-12 at 08:14 -1000, Ross Boylan wrote: >> On Thu, 2011-08-11 at 12:21 -1000, Ross Boylan wrote: >>> On 8/11/2011 11:58 AM, Andres Valloud wrote: >>>>> I'm running in Windows because the image, created under Debian Lenny, >>>>> will not launch successfully in Debian squeeze. Image is about 36MB on >>>>> disk. Attempted launch produces 100% CPU utilitization, a largish use >>>>> of memory (~500MB), no windows popping up, and, after a long time, a >>>>> crash (but not because of OS-level memory exhaustion). The stock image >>>>> launches successfully under squeeze. >>>> Can you please run that image that won't start correctly with a debug VM >>>> and post any output to the console? >>> Where do I find the debug VM? >> I did >> /usr/local/src/vw7.7.1nc$ bin/linux86/debug/vwlinux86dbg ross.im >> For ~5 hours it used all CPU and slowly increased in memory useage. >> Since then (total of ~14 hours since launch) it has no CPU useage and >> is holding at 512.6M. There was no output on the terminal until I >> copied the command line above, at which point >> ^[[A^[[A^[[A >> appeared. I think that was random stuff from me hitting keys, not the >> program. >> I don't see anything plausible in .xsession-errors or the logs. >> debug.log is empty. >> >> It's possible the CPU useage went quiet before the crash with the >> regular VM. >> >> Should I keep this running? Attach a debugger to it? >> >>>> Also, run the VM with the -xq >>>> switch. >>> -xq is for the debug VM or regular? >> still wondering about this. >>>> This should produce a file called stack.txt. I'd like to see >>>> that too. >>>> >>>> Andres. >>> Would the output of ldd be useful too? >> Here it is, just in case: >> ross@cotton:/usr/local/src/vw7.7.1nc$ ldd bin/linux86/visual >> linux-gate.so.1 => (0xb7860000) >> libX11.so.6 => /usr/lib/libX11.so.6 (0xb772e000) >> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7715000) >> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb770b000) >> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7707000) >> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb76e1000) >> libz.so.1 => /usr/lib/libz.so.1 (0xb76cd000) >> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7587000) >> libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb756d000) >> /lib/ld-linux.so.2 (0xb7861000) >> libXau.so.6 => /usr/lib/libXau.so.6 (0xb756a000) >> libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7565000) >>> Ross >> >> >> >>>> _______________________________________________ >>>> vwnc mailing list >>>> [hidden email] >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >>> >> >> > > vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Holger Kleinsorgen-4
Under -o11s, 100% CPU utilization is a side effect of very expensive
checks being performed while running the IGC in interruptible mode. Basically, the length of the checks effectively ensure the IGC will always be interrupted before you can do any work. Go to the memory policy and you will find something equivalent to idleLoopIGCAction [ self igcObjects: nil interruptibly: true. self updateMemoryStatus. self memoryStatus incGCIsResting ] whileFalse. self updateNumScavengesAsOfLastGC. ObjectMemory resetSpaceLimitsIfHigher. (self shouldForkCompactData or: [self dataNeedsCompacting]) ifTrue: [self forkCompactData]. self shrinkMemoryIfRequired (your implementation may vary since I've been cleaning up that stuff). Either comment out the IGC code, or change the code so that the idle loop never decides to use the IGC. On 8/23/2011 12:03 AM, Holger Kleinsorgen wrote: > Hi Ross > > try to launch the image with > > vmlinux86dbg -o10s visual.im > debug.log > > All message sends will be printed to stdout. I assume that there is an > infinite recursion, which should be diagnosable by looking at the output. > > If it's a headfull image, my buest guess is an infinite debugger > recursion. You might want to try to add the following parcel to the > image and run it on Squeeze: > > http://dl.dropbox.com/u/21555916/StartupPatch.zip > > it will create an error.log file when the windowing system is not active. > > On 23.08.2011 06:33, Ross Boylan wrote: >> I started the program with vmlinux86dbg -o11s about 4.5 days ago. It >> continues to run, spitting out messages on the launching terminal like >> checkMarksInOt: incremenal GC was conservative by xxx objects. >> It uses all of one CPU, and has slowly grown to 442M. >> >> Since the process is 51M when it runs successfully on lenny, and the >> image file is 37M on disk, something has likely already gone very wrong. >> >> I attached the debugger to it, but I am unable to reattach. When I do >> so, I get the message >> Attaching to program ... >> Cannot access memory at address xxxx >> A program is being debugged already. Kill it? (y or n) > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Holger Kleinsorgen-4
On Tue, 2011-08-23 at 09:03 +0200, Holger Kleinsorgen wrote:
> Hi Ross > > try to launch the image with > > vmlinux86dbg -o10s visual.im > debug.log > > All message sends will be printed to stdout. I assume that there is an > infinite recursion, which should be diagnosable by looking at the output. Is -o10s going to show me anything that -o11s doesn't already? > > If it's a headfull image, my buest guess is an infinite debugger > recursion. Why do you think that? Although I'm running under the debugger, the misbehavior (huge memory, high CPU, no windows) occurred with a regular VM. > You might want to try to add the following parcel to the > image and run it on Squeeze: > > http://dl.dropbox.com/u/21555916/StartupPatch.zip > > it will create an error.log file when the windowing system is not active. Thanks for the tip; since the window system doesn't come up, that could be very useful. Ross P.S. For now I'm leaving my existing test running, hoping for a solution to my gdb problems. It does appear to have stopped emitting the "incremental GC was conservative" messages, although the CPU is still 100%. Memory use, 476M, is now around where it maxed out before, although I assume the debugging VM uses some extra memory. > > On 23.08.2011 06:33, Ross Boylan wrote: > > I started the program with vmlinux86dbg -o11s about 4.5 days ago. It > > continues to run, spitting out messages on the launching terminal like > > checkMarksInOt: incremenal GC was conservative by xxx objects. > > It uses all of one CPU, and has slowly grown to 442M. > > > > Since the process is 51M when it runs successfully on lenny, and the > > image file is 37M on disk, something has likely already gone very wrong. > > > > I attached the debugger to it, but I am unable to reattach. When I do > > so, I get the message > > Attaching to program ... > > Cannot access memory at address xxxx > > A program is being debugged already. Kill it? (y or n) > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Andres Valloud-6
On Tue, 2011-08-23 at 02:13 -0700, Andres Valloud wrote:
> I take it that if you save the image while the VM process is using so > much memory, the resulting file will be on the order of 37M, right? I can't save the image while the process is using so much memory, because no windows ever appear on the screen. The image the process is attempting to open is 37M on disk. > I'd > try figuring out the gdb attaching issues, I was hoping someone here had some ideas. > and from then examining the C > heap to see what is allocated. > > With -o11s, it's normal that the CPU uses 100% all the time. Even with a regular vm and no debug options, the process used 100% CPU until it was around 450M, and then CPU dropped to 0. No windows ever opened; sometimes I'm pretty sure it eventually crashed. > Due to > extended checks, the IGC can't make progress from the idle loop. Go to > the idle loop process method, comment out the IGC calls, and shut down > the IGC by doing a GC. Can you point me to the method to change? I'd have to modify the image under Debian lenny and then launch it on squeeze. I could also try testing on faster hardware, but it is 64 bit (vs 32 for what I've done so far) and would be running under a OS level VM (that is, kvm, not the VisualWorks virtual machine). Ross > > On 8/22/2011 9:33 PM, Ross Boylan wrote: > > I started the program with vmlinux86dbg -o11s about 4.5 days ago. It > > continues to run, spitting out messages on the launching terminal like > > checkMarksInOt: incremenal GC was conservative by xxx objects. > > It uses all of one CPU, and has slowly grown to 442M. > > > > Since the process is 51M when it runs successfully on lenny, and the > > image file is 37M on disk, something has likely already gone very wrong. > > > > I attached the debugger to it, but I am unable to reattach. When I do > > so, I get the message > > Attaching to program ... > > Cannot access memory at address xxxx > > A program is being debugged already. Kill it? (y or n) > > > > I say n, and then the debugger just sits there; ps shows the program > > (vmlinux86dbg) is stopped. If I kill the debugger process, the vm > > resumes execution. There are no other gdb processes. > > > > Can anyone suggest what to do? > > > > I'm running gdb 7.0.1-debian under emacs 23.2.1. I suspect this problem > > arises because I initially attached using the wrong path to the program, > > as a result of which it said no symbols were found. I may also have > > made some attempts to debug specifying the wrong vm (7.7 vs the 7.7.1 vm > > that is actually running). > > > > Searching the net on the Kill it? message shows nothing that looks > > particularly relevant; some people respond y, which I assume would lose > > 4.5 days work; and others respond n and get a gdb prompt. I don't get a > > gdb prompt, nor does sending ^c (via typing it twice in emacs) do > > anything. > > > > Ross > > On Fri, 2011-08-12 at 08:14 -1000, Ross Boylan wrote: > >> On Thu, 2011-08-11 at 12:21 -1000, Ross Boylan wrote: > >>> On 8/11/2011 11:58 AM, Andres Valloud wrote: > >>>>> I'm running in Windows because the image, created under Debian Lenny, > >>>>> will not launch successfully in Debian squeeze. Image is about 36MB on > >>>>> disk. Attempted launch produces 100% CPU utilitization, a largish use > >>>>> of memory (~500MB), no windows popping up, and, after a long time, a > >>>>> crash (but not because of OS-level memory exhaustion). The stock image > >>>>> launches successfully under squeeze. > >>>> Can you please run that image that won't start correctly with a debug VM > >>>> and post any output to the console? > >>> Where do I find the debug VM? > >> I did > >> /usr/local/src/vw7.7.1nc$ bin/linux86/debug/vwlinux86dbg ross.im > >> For ~5 hours it used all CPU and slowly increased in memory useage. > >> Since then (total of ~14 hours since launch) it has no CPU useage and > >> is holding at 512.6M. There was no output on the terminal until I > >> copied the command line above, at which point > >> ^[[A^[[A^[[A > >> appeared. I think that was random stuff from me hitting keys, not the > >> program. > >> I don't see anything plausible in .xsession-errors or the logs. > >> debug.log is empty. > >> > >> It's possible the CPU useage went quiet before the crash with the > >> regular VM. > >> > >> Should I keep this running? Attach a debugger to it? > >> > >>>> Also, run the VM with the -xq > >>>> switch. > >>> -xq is for the debug VM or regular? > >> still wondering about this. > >>>> This should produce a file called stack.txt. I'd like to see > >>>> that too. > >>>> > >>>> Andres. > >>> Would the output of ldd be useful too? > >> Here it is, just in case: > >> ross@cotton:/usr/local/src/vw7.7.1nc$ ldd bin/linux86/visual > >> linux-gate.so.1 => (0xb7860000) > >> libX11.so.6 => /usr/lib/libX11.so.6 (0xb772e000) > >> libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb7715000) > >> librt.so.1 => /lib/i686/cmov/librt.so.1 (0xb770b000) > >> libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb7707000) > >> libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb76e1000) > >> libz.so.1 => /usr/lib/libz.so.1 (0xb76cd000) > >> libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb7587000) > >> libxcb.so.1 => /usr/lib/libxcb.so.1 (0xb756d000) > >> /lib/ld-linux.so.2 (0xb7861000) > >> libXau.so.6 => /usr/lib/libXau.so.6 (0xb756a000) > >> libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7565000) > >>> Ross > >> > >> > >> > >>>> _______________________________________________ > >>>> vwnc mailing list > >>>> [hidden email] > >>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > >>> > >> > >> > > > > _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
In reply to this post by Andres Valloud-6
On Tue, 2011-08-23 at 02:16 -0700, Andres Valloud wrote:
> Under -o11s, 100% CPU utilization is a side effect of very expensive > checks being performed while running the IGC in interruptible mode. > Basically, the length of the checks effectively ensure the IGC will > always be interrupted before you can do any work. Go to the memory > policy and you will find something equivalent to > > idleLoopIGCAction > > [ > self igcObjects: nil interruptibly: true. > self updateMemoryStatus. > self memoryStatus incGCIsResting > ] whileFalse. > self updateNumScavengesAsOfLastGC. > ObjectMemory resetSpaceLimitsIfHigher. > (self shouldForkCompactData or: [self dataNeedsCompacting]) > ifTrue: [self forkCompactData]. > self shrinkMemoryIfRequired > > > (your implementation may vary since I've been cleaning up that stuff). > Either comment out the IGC code, or change the code so that the idle > loop never decides to use the IGC. > stay? Ross > > On 8/23/2011 12:03 AM, Holger Kleinsorgen wrote: > > Hi Ross > > > > try to launch the image with > > > > vmlinux86dbg -o10s visual.im > debug.log > > > > All message sends will be printed to stdout. I assume that there is an > > infinite recursion, which should be diagnosable by looking at the output. > > > > If it's a headfull image, my buest guess is an infinite debugger > > recursion. You might want to try to add the following parcel to the > > image and run it on Squeeze: > > > > http://dl.dropbox.com/u/21555916/StartupPatch.zip > > > > it will create an error.log file when the windowing system is not active. > > > > On 23.08.2011 06:33, Ross Boylan wrote: > >> I started the program with vmlinux86dbg -o11s about 4.5 days ago. It > >> continues to run, spitting out messages on the launching terminal like > >> checkMarksInOt: incremenal GC was conservative by xxx objects. > >> It uses all of one CPU, and has slowly grown to 442M. > >> > >> Since the process is 51M when it runs successfully on lenny, and the > >> image file is 37M on disk, something has likely already gone very wrong. > >> > >> I attached the debugger to it, but I am unable to reattach. When I do > >> so, I get the message > >> Attaching to program ... > >> Cannot access memory at address xxxx > >> A program is being debugged already. Kill it? (y or n) > > > > > > _______________________________________________ > > vwnc mailing list > > [hidden email] > > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Re: vw7.7.1nc problems under Debian squeeze
|
|
This may or may not help.....
But I ran into exactly the same symptoms while upgrading from vw77 to vw78. The image would launch, the cpu would peg at 100%, and memory use would grow to 500mb and then just sit there. In my case the problem was I was using a vw77 VM to open a vw78 image -- easy to fix. maybe that can point your investigation in a useful direction. On Tue, Aug 23, 2011 at 1:18 PM, Ross Boylan <[hidden email]> wrote:
_______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |