RE: [Pharo-project] VM crash on Windows
Locked
RE: [Pharo-project] VM crash on Windows
 
|
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 |
Re: [Pharo-project] VM crash on Windows
|
|
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 > |
Re: [Pharo-project] VM crash on Windows
|
|
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 |
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 > |
Re: [Pharo-project] VM crash on Windows
|
|
ok so excellent then.
I though that having a max counter to get let us say 1000 last crash could help. I do not know what is the situation of dabblebd like setup. Stef On Mar 11, 2010, at 9:09 AM, Andreas Raab wrote: > 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 >> > |
RE: [Pharo-project] VM crash on Windows
|
|
In reply to this post by Andreas.Raab
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 |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |