VM crash on Windows
Locked
 
|
Hello all,
I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. Is there any way to get it to log the output? So far, the things I have found online say that it will write a dump when it crashes, but it's not doing it. Bill _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hello all,
Good news/bad news: I got it running again :) I have no idea what was wrong, nor what is right now :( A corrupt image file is not out of the question. I was having huge problems with Ubuntu (perhaps Linux in general??[*]) and cifs writing to windows shares. That problem suddenly went away some weeks ago, but maybe it is simply less frequent now?? Nearly the same image was running just fine on a sibling box, and copying the image from there to the offending machine got me going again. What bothers me here is not so much that Pharo crashed but that it did it so abruptly and without logging anything that I could find. Suggestions would be most welcome. I also wondered about the vm on the misbehaving box and tried to download a new one from the Pharo site - I have not been able to successfully download it but the alternate link appears to work. Bill [*] I was building up to trying Mandriva when I discovered things had radically improved on Ubuntu. Some writings on the net lead me to suspect that it might have been more than just Ubuntu users suffering, but I am simply not certain. -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Schwab,Wilhelm K Sent: Monday, March 08, 2010 7:27 PM To: [hidden email] Subject: [Pharo-project] VM crash on Windows Hello all, I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. Is there any way to get it to log the output? So far, the things I have found online say that it will write a dump when it crashes, but it's not doing it. Bill _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On Mon, Mar 08, 2010 at 07:47:16PM -0500, Schwab,Wilhelm K wrote:
> Hello all, > > Good news/bad news: I got it running again :) I have no idea what was wrong, nor what is right now :( > > A corrupt image file is not out of the question. I was having huge problems with Ubuntu (perhaps Linux in general??[*]) and cifs writing to windows shares. That problem suddenly went away some weeks ago, but maybe it is simply less frequent now?? Nearly the same image was running just fine on a sibling box, and copying the image from there to the offending machine got me going again. > > What bothers me here is not so much that Pharo crashed but that it did it so abruptly and without logging anything that I could find. Suggestions would be most welcome. Bill, Whatever is wrong, it is probably not the fault of the Pharo image. When the VM crashes abruptly with no log file generated, it is most likely because it encountered an access violation (segfault) error in some plugin or in an FFI call. If you get a hard failure like that, the image is not able to write the debug log file (because it is already dead - d'oh!). I think that various people have reported problems with virus scanners and that sort of thing on windows. And it is possible that running on network file systems (cifs etc) will expose bugs that do not show up when running on local file systems. I think you're going to be stuck doing some good old process of elimination work here :( Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
David,
The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of David T. Lewis Sent: Monday, March 08, 2010 8:09 PM To: [hidden email] Subject: Re: [Pharo-project] VM crash on Windows On Mon, Mar 08, 2010 at 07:47:16PM -0500, Schwab,Wilhelm K wrote: > Hello all, > > Good news/bad news: I got it running again :) I have no idea what was > wrong, nor what is right now :( > > A corrupt image file is not out of the question. I was having huge problems with Ubuntu (perhaps Linux in general??[*]) and cifs writing to windows shares. That problem suddenly went away some weeks ago, but maybe it is simply less frequent now?? Nearly the same image was running just fine on a sibling box, and copying the image from there to the offending machine got me going again. > > What bothers me here is not so much that Pharo crashed but that it did it so abruptly and without logging anything that I could find. Suggestions would be most welcome. Bill, Whatever is wrong, it is probably not the fault of the Pharo image. When the VM crashes abruptly with no log file generated, it is most likely because it encountered an access violation (segfault) error in some plugin or in an FFI call. If you get a hard failure like that, the image is not able to write the debug log file (because it is already dead - d'oh!). I think that various people have reported problems with virus scanners and that sort of thing on windows. And it is possible that running on network file systems (cifs etc) will expose bugs that do not show up when running on local file systems. I think you're going to be stuck doing some good old process of elimination work here :( Dave _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
Hi Bill -
If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: > I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: ((ProtoObject subclass: #Bummerator instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Objects') superclass: nil; new) bummer. The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. Contrast this with, say the result of an FFI crash: (ExternalLibraryFunction name:'' module: '' callType: 0 returnType: ExternalType void argumentTypes: #()) setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); invoke This does generate a crash.dmp since the support code can catch the problem. However, to catch the former issue you can run the vm with -log: <logfile> which will contain the resulting output. > The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. They do if you tell 'em to. Cheers, - Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Andreas,
I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. Thanks!! Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab Sent: Wednesday, March 10, 2010 12:32 AM To: Pharo Development Subject: Re: [Pharo-project] VM crash on Windows Hi Bill - If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: > I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: ((ProtoObject subclass: #Bummerator instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'Kernel-Objects') superclass: nil; new) bummer. The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. Contrast this with, say the result of an FFI crash: (ExternalLibraryFunction name:'' module: '' callType: 0 returnType: ExternalType void argumentTypes: #()) setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); invoke This does generate a crash.dmp since the support code can catch the problem. However, to catch the former issue you can run the vm with -log: <logfile> which will contain the resulting output. > The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. They do if you tell 'em to. Cheers, - Andreas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Hi Bill -
The just released 3.11.8 VM does take care of the issue you're reporting. It creates a proper crash.dmp for all of the cases that would previously silently quit. Try that doIt below in with 3.11.8 to compare to the previous behavior. Cheers, - Andreas On 3/10/2010 5:12 AM, Schwab,Wilhelm K wrote: > Andreas, > > I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. > > Thanks!! > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab > Sent: Wednesday, March 10, 2010 12:32 AM > To: Pharo Development > Subject: Re: [Pharo-project] VM crash on Windows > > Hi Bill - > > If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. > > On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. > > The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: > > ((ProtoObject subclass: #Bummerator > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Kernel-Objects') > superclass: nil; > new) bummer. > > The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. > > Contrast this with, say the result of an FFI crash: > > (ExternalLibraryFunction > name:'' module: '' callType: 0 > returnType: ExternalType void argumentTypes: #()) > setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); > invoke > > This does generate a crash.dmp since the support code can catch the problem. > > However, to catch the former issue you can run the vm with -log: > <logfile> which will contain the resulting output. > > > The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. > > They do if you tell 'em to. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
In reply to this post by Schwab,Wilhelm K
bill
did you not notice problem with the size of the log file with the appening behavior? Because I started to have a huge file where all the crashes reports were added one by one and I was wondering if on a server this may not be a problem (probably having a limit for the size of the report could be a good idea - but I do not know). Stef On Mar 10, 2010, at 2:12 PM, Schwab,Wilhelm K wrote: > Andreas, > > I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. > > Thanks!! > > Bill > > > > -----Original Message----- > From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab > Sent: Wednesday, March 10, 2010 12:32 AM > To: Pharo Development > Subject: Re: [Pharo-project] VM crash on Windows > > Hi Bill - > > If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. > > On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. > > The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: > > ((ProtoObject subclass: #Bummerator > instanceVariableNames: '' > classVariableNames: '' > poolDictionaries: '' > category: 'Kernel-Objects') > superclass: nil; > new) bummer. > > The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. > > Contrast this with, say the result of an FFI crash: > > (ExternalLibraryFunction > name:'' module: '' callType: 0 > returnType: ExternalType void argumentTypes: #()) > setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); > invoke > > This does generate a crash.dmp since the support code can catch the problem. > > However, to catch the former issue you can run the vm with -log: > <logfile> which will contain the resulting output. > >> The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. > > They do if you tell 'em to. > > Cheers, > - Andreas > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
On 3/10/2010 11:40 PM, Stéphane Ducasse wrote:
> did you not notice problem with the size of the log file with the appening behavior? > Because I started to have a huge file where all the crashes reports were added one by one and I was wondering if > on a server this may not be a problem (probably having a limit for the size of the report could be a good idea - but I do not know). One a production server? Do the math: 1GB of disk space costs cents. One hour of two of your engineers trying to recreate the problem or recover the information costs a few hundred bucks. That's a ratio of 10000:1. On our main server the size of the logs is 500MB going back six months or so when we reimaged it last. That's 0.1% of the disk space on the box. The other day we bought a few more TBs of cheap scratch storage which we use for throwaway VMs in QA (vmware VMs, not Squeak so it's 20+GB each). On a production server it makes no sense whatsoever to limit logging unless you're logging *excessively*. In an emergency the logs are all you have to find out what is going wrong, it's worth keeping them. Cheers, - Andreas > > Stef > > On Mar 10, 2010, at 2:12 PM, Schwab,Wilhelm K wrote: > >> Andreas, >> >> I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. >> >> Thanks!! >> >> Bill >> >> >> >> -----Original Message----- >> From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab >> Sent: Wednesday, March 10, 2010 12:32 AM >> To: Pharo Development >> Subject: Re: [Pharo-project] VM crash on Windows >> >> Hi Bill - >> >> If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. >> >> On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >>> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. >> >> The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: >> >> ((ProtoObject subclass: #Bummerator >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Kernel-Objects') >> superclass: nil; >> new) bummer. >> >> The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. >> >> Contrast this with, say the result of an FFI crash: >> >> (ExternalLibraryFunction >> name:'' module: '' callType: 0 >> returnType: ExternalType void argumentTypes: #()) >> setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); >> invoke >> >> This does generate a crash.dmp since the support code can catch the problem. >> >> However, to catch the former issue you can run the vm with -log: >> <logfile> which will contain the resulting output. >> >>> The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. >> >> They do if you tell 'em to. >> >> Cheers, >> - Andreas >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
|
|
Andreas, Stef,
I agree that logs are good, especially for rare problems; sometimes just a callstack can point to a weakness that would otherwise be nearly impossible to find. I have had Dolphin apps logging for quite a long time, and have not run into problems (just had to say that...<g>). I am fairly new at running Pharo images, and even newer at running them on machines that actually work. A 500 MB log would be no problem as long as it does not itself crash the image trying to open it. Do you have any tools to parse logs? Chris Uppal wrote Ghoul for parsing Dolphin crash dumps. It parses the dump and uses current code in the image to create a debugger-like view of a single "record" (one crash) from the dump; a drop-down list allows switching between records in a given file. It would be nice to have something similar here. Bill -----Original Message----- From: [hidden email] [mailto:[hidden email]] On Behalf Of Andreas Raab Sent: Thursday, March 11, 2010 3:10 AM To: [hidden email]; [hidden email] Subject: Re: [Pharo-project] VM crash on Windows On 3/10/2010 11:40 PM, Stéphane Ducasse wrote: > did you not notice problem with the size of the log file with the appening behavior? > Because I started to have a huge file where all the crashes reports > were added one by one and I was wondering if on a server this may not be a problem (probably having a limit for the size of the report could be a good idea - but I do not know). One a production server? Do the math: 1GB of disk space costs cents. One hour of two of your engineers trying to recreate the problem or recover the information costs a few hundred bucks. That's a ratio of 10000:1. On our main server the size of the logs is 500MB going back six months or so when we reimaged it last. That's 0.1% of the disk space on the box. The other day we bought a few more TBs of cheap scratch storage which we use for throwaway VMs in QA (vmware VMs, not Squeak so it's 20+GB each). On a production server it makes no sense whatsoever to limit logging unless you're logging *excessively*. In an emergency the logs are all you have to find out what is going wrong, it's worth keeping them. Cheers, - Andreas > > Stef > > On Mar 10, 2010, at 2:12 PM, Schwab,Wilhelm K wrote: > >> Andreas, >> >> I will give that a try. I think it should be active by default, but it won't matter too much once I modify the shortcuts on a few boxes. Other wish list items would be to have a similar option on Linux and to ensure that the contents of the log are concatenated vs. replaced with each crash. >> >> Thanks!! >> >> Bill >> >> >> >> -----Original Message----- >> From: [hidden email] >> [mailto:[hidden email]] On Behalf Of >> Andreas Raab >> Sent: Wednesday, March 10, 2010 12:32 AM >> To: Pharo Development >> Subject: Re: [Pharo-project] VM crash on Windows >> >> Hi Bill - >> >> If you have problems like these consider cross-posting to squeak-dev or vm-dev. I only check Pharo in irregular intervals. >> >> On 3/8/2010 4:27 PM, Schwab,Wilhelm K wrote: >>> I am having a sudden problem with Pharo crashing on Windows - it's quitting on handling Seaside requests, and I'm getting **no** information. The VM pops up the output console, writes a lot of (probably useful) information to it, and then promptly exits. >> >> The issue you're seeing is caused by a recursive MessageNotUnderstood error. You can easily recreate this by doing the following: >> >> ((ProtoObject subclass: #Bummerator >> instanceVariableNames: '' >> classVariableNames: '' >> poolDictionaries: '' >> category: 'Kernel-Objects') >> superclass: nil; >> new) bummer. >> >> The reason why that doesn't result in a regular crash.dmp is that the support code (which catches the crashes and writes the dump) isn't involved at all. The interpreter just quits. >> >> Contrast this with, say the result of an FFI crash: >> >> (ExternalLibraryFunction >> name:'' module: '' callType: 0 >> returnType: ExternalType void argumentTypes: #()) >> setHandle: ((ExternalAddress new) at: 1 put: 1; yourself); >> invoke >> >> This does generate a crash.dmp since the support code can catch the problem. >> >> However, to catch the former issue you can run the vm with -log: >> <logfile> which will contain the resulting output. >> >>> The rebuttal: if it has time/ability to write information all over part of the screen, it can open a file and make sure it leaves a trace of what happened. Right? The current vms (Windows and Linux) appear to be totally disinterested in logging crashes, and that needs to change. >> >> They do if you tell 'em to. >> >> Cheers, >> - Andreas >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |