new Cog VMs available [please read]

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

new Cog VMs available [please read]

Eliot Miranda-2
 
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2493/.  These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing.  These 2493 VMs contain code to help identify that bug.  If you're already using a 2487 VM or newer /please/ upgrade to these 2493 VMs asap.  I want to see C stack backtraces from these VMs whenever they crash.  Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window).  The C backtrace part of things looks like

this on windows:
Stack backtrace:
[004193EA] ??? + 4297706 in CogCode
[00442337] ??? + 4465463 in CogCode
[00442685] ??? + 4466309 in CogCode
[00583018] ??? + 5779480 in CogCode
[0040124B] ??? + 4198987 in CogCode
[00401298] ??? + 4199064 in CogCode
[7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll
[7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll

this on Mac
C stack backtrace:
0   nsvm                                0x00038689 reportStackState + 105
1   nsvm                                0x0003893e sigsegv + 110
2   libsystem_c.dylib                   0x9b2e259b _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   nsvm                                0x0008b2a5 sufficientSpaceAfterGC + 69
5   nsvm                                0x0008d11d primitiveNewWithArg + 221
6   ???                                 0x068b9899 0x0 + 109811865
7   nsvm                                0x00098d10 initStackPagesAndInterpret + 512
8   nsvm                                0x0002c530 EventLoopEventHandler + 16

Etc.  So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2493 VMs.  Hopefully I'll track down this regression quickly.

For the curious, what's the bug?  I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit.  These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug.

Here's the 2493 readme:
CogVM binaries as per VMMaker.oscog-eem.125/r2493.  Add callsite link/relocate
checks to catch the call 0x00000013 MNU callsite relinking bug.
Reduce the size of the simStack to something proportional to LargeContextSize.

In the Newspeak VM, don't cd to the image's directory on win32.  Fix off-by-one
error in Win32OSProcessPlugin>primitiveGetCurrentWorkingDirectory so it doesn't
include an erroneous trailing null.

Fix the 1Gb allocation bug.
--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs available [please read]

Igor Stasenko

On 22 September 2011 19:37, Eliot Miranda <[hidden email]> wrote:
>
> ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2493/.  These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing.  These 2493 VMs contain code to help identify that bug.  If you're already using a 2487 VM or newer /please/ upgrade to these 2493 VMs asap.  I want to see C stack backtraces from these VMs whenever they crash.  Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window).  The C backtrace part of things looks like

Just a little nitpick: can you make a crash.dmp to appear in more
predictable places? :)
I vote for same directory where image located.

> this on windows:
> Stack backtrace:
> [004193EA] ??? + 4297706 in CogCode
> [00442337] ??? + 4465463 in CogCode
> [00442685] ??? + 4466309 in CogCode
> [00583018] ??? + 5779480 in CogCode
> [0040124B] ??? + 4198987 in CogCode
> [00401298] ??? + 4199064 in CogCode
> [7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll
> [7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll
> this on Mac
> C stack backtrace:
> 0   nsvm                                0x00038689 reportStackState + 105
> 1   nsvm                                0x0003893e sigsegv + 110
> 2   libsystem_c.dylib                   0x9b2e259b _sigtramp + 43
> 3   ???                                 0xffffffff 0x0 + 4294967295
> 4   nsvm                                0x0008b2a5 sufficientSpaceAfterGC + 69
> 5   nsvm                                0x0008d11d primitiveNewWithArg + 221
> 6   ???                                 0x068b9899 0x0 + 109811865
> 7   nsvm                                0x00098d10 initStackPagesAndInterpret + 512
> 8   nsvm                                0x0002c530 EventLoopEventHandler + 16
> Etc.  So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2493 VMs.  Hopefully I'll track down this regression quickly.
> For the curious, what's the bug?  I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit.  These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug.
> Here's the 2493 readme:
>
> CogVM binaries as per VMMaker.oscog-eem.125/r2493.  Add callsite link/relocate
> checks to catch the call 0x00000013 MNU callsite relinking bug.
> Reduce the size of the simStack to something proportional to LargeContextSize.
>
> In the Newspeak VM, don't cd to the image's directory on win32.  Fix off-by-one
> error in Win32OSProcessPlugin>primitiveGetCurrentWorkingDirectory so it doesn't
> include an erroneous trailing null.
>
> Fix the 1Gb allocation bug.
>
> --
> best,
> Eliot
>
>



--
Best regards,
Igor Stasenko.
Reply | Threaded
Open this post in threaded view
|

Re: new Cog VMs available [please read]

Eliot Miranda-2
 


On Thu, Sep 22, 2011 at 11:01 AM, Igor Stasenko <[hidden email]> wrote:

On 22 September 2011 19:37, Eliot Miranda <[hidden email]> wrote:
>
> ...in http://www.mirandabanda.org/files/Cog/VM/VM.r2493/.  These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing.  These 2493 VMs contain code to help identify that bug.  If you're already using a 2487 VM or newer /please/ upgrade to these 2493 VMs asap.  I want to see C stack backtraces from these VMs whenever they crash.  Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window).  The C backtrace part of things looks like

Just a little nitpick: can you make a crash.dmp to appear in more
predictable places? :)
I vote for same directory where image located.

Yes, good suggestion.
 

> this on windows:
> Stack backtrace:
> [004193EA] ??? + 4297706 in CogCode
> [00442337] ??? + 4465463 in CogCode
> [00442685] ??? + 4466309 in CogCode
> [00583018] ??? + 5779480 in CogCode
> [0040124B] ??? + 4198987 in CogCode
> [00401298] ??? + 4199064 in CogCode
> [7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll
> [7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll
> this on Mac
> C stack backtrace:
> 0   nsvm                                0x00038689 reportStackState + 105
> 1   nsvm                                0x0003893e sigsegv + 110
> 2   libsystem_c.dylib                   0x9b2e259b _sigtramp + 43
> 3   ???                                 0xffffffff 0x0 + 4294967295
> 4   nsvm                                0x0008b2a5 sufficientSpaceAfterGC + 69
> 5   nsvm                                0x0008d11d primitiveNewWithArg + 221
> 6   ???                                 0x068b9899 0x0 + 109811865
> 7   nsvm                                0x00098d10 initStackPagesAndInterpret + 512
> 8   nsvm                                0x0002c530 EventLoopEventHandler + 16
> Etc.  So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2493 VMs.  Hopefully I'll track down this regression quickly.
> For the curious, what's the bug?  I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit.  These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug.
> Here's the 2493 readme:
>
> CogVM binaries as per VMMaker.oscog-eem.125/r2493.  Add callsite link/relocate
> checks to catch the call 0x00000013 MNU callsite relinking bug.
> Reduce the size of the simStack to something proportional to LargeContextSize.
>
> In the Newspeak VM, don't cd to the image's directory on win32.  Fix off-by-one
> error in Win32OSProcessPlugin>primitiveGetCurrentWorkingDirectory so it doesn't
> include an erroneous trailing null.
>
> Fix the 1Gb allocation bug.
>
> --
> best,
> Eliot
>
>



--
Best regards,
Igor Stasenko.



--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] new Cog VMs available [please read]

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
 


On Thu, Sep 22, 2011 at 12:58 PM, Tony Garnock-Jones <[hidden email]> wrote:
On 2011-09-22 1:37 PM, Eliot Miranda wrote:
> If you're already using a
> 2487 VM or newer

How do I find the VM version? Pressing cmd-I on the .app in Finder gives
a version of "Croquet Cog 4.0.0 http://www.mirandabanda.org". Presumably
there's an in-image way of finding out?

(1007 to: 1009) collect: [:i| Smalltalk getSystemAttribute: i]

which may have a nicer wrapper (e.g. included in About Squeak?).  1009 answers the svn revision and url in my VMs and the analogous info in Igor's VMs.


Regards,
 Tony



--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] new Cog VMs available [please read]

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
 


2011/9/22 Stéphane Rollandin <[hidden email]>

 I want to see
C stack backtraces from these VMs whenever they crash.

Here is one :)

Brilliant!  Found the bug!! Thanks sooo much!!


Stef






--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [squeak-dev] new Cog VMs available [please read]

Eliot Miranda-2
 


On Thu, Sep 22, 2011 at 5:16 PM, Eliot Miranda <[hidden email]> wrote:


2011/9/22 Stéphane Rollandin <[hidden email]>

 I want to see
C stack backtraces from these VMs whenever they crash.

Here is one :)

Brilliant!  Found the bug!! Thanks sooo much!!

well, I spoke too soon.  I still don't understand it. But at least I know why it bites :(  Keep them coming.



Stef






--
best,
Eliot




--
best,
Eliot

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-project] [squeak-dev] new Cog VMs available [please read]

laza
In reply to this post by Eliot Miranda-2
 
2011/9/22 Eliot Miranda <[hidden email]>
which may have a nicer wrapper (e.g. included in About Squeak?).  1009 answers the svn revision and url in my VMs and the analogous info in Igor's VMs.

In Squeak one can find the SystemReporter [1] at Help>>"About this System" of the main DockingBar

Alex

[1] http://www.squeaksource.com/SystemReporter.html

 
Reply | Threaded
Open this post in threaded view
|

new Cog VMs available [please read]

Eliot Miranda-2
In reply to this post by Eliot Miranda-2
 
Hi All,

    yesterday's new VMs bore fruit and I found and fixed a bug that could cause fatal VM crashes.  Alas it was not the one I was looking for, simply closely related.  So I've uploaded new VMs to http://www.mirandabanda.org/files/Cog/VM/VM.r2494/README.2494 and would ask you, especially if you used yesterday's VM, to upgrade to today's VM and hopefully I can nail the one I was after in the first place.

thanks for the great response!

Eliot


P.S.  Here's the readme, and a reiteration of what I need from you

CogVM source as per VMMaker.oscog-eem.126. Fix cPICEndSize mis-computation
caused by using rounded-up closedPICSize.  Compute cPICEndSize and /then/
round-up closedPICSize.
These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing.  These 2494 VMs contain code to help identify that bug.  If you're already using a 2487 VM or newer /please/ upgrade to these 2494 VMs asap.  I want to see C stack backtraces from these VMs whenever they crash.  Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window).  The C backtrace part of things looks like

this on windows:
Stack backtrace:
[004193EA] ??? + 4297706 in CogCode
[00442337] ??? + 4465463 in CogCode
[00442685] ??? + 4466309 in CogCode
[00583018] ??? + 5779480 in CogCode
[0040124B] ??? + 4198987 in CogCode
[00401298] ??? + 4199064 in CogCode
[7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll
[7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll

this on Mac
C stack backtrace:
0   nsvm                                0x00038689 reportStackState + 105
1   nsvm                                0x0003893e sigsegv + 110
2   libsystem_c.dylib                   0x9b2e259b _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   nsvm                                0x0008b2a5 sufficientSpaceAfterGC + 69
5   nsvm                                0x0008d11d primitiveNewWithArg + 221
6   ???                                 0x068b9899 0x0 + 109811865
7   nsvm                                0x00098d10 initStackPagesAndInterpret + 512
8   nsvm                                0x0002c530 EventLoopEventHandler + 16

Etc.  So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2494 VMs.  Hopefully I'll track down this regression quickly.

For the curious, what's the bug?  I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit.  These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug.
On Thu, Sep 22, 2011 at 10:37 AM, Eliot Miranda <[hidden email]> wrote:
...in http://www.mirandabanda.org/files/Cog/VM/VM.r2493/.  These VMs are not much changed from the 2487 VMs, BUT the 2487 VMs introduced a bug while providing faster doesNotUnderstand: processing.  These 2493 VMs contain code to help identify that bug.  If you're already using a 2487 VM or newer /please/ upgrade to these 2493 VMs asap.  I want to see C stack backtraces from these VMs whenever they crash.  Typically the VMs produce a crash.dmp file somewhere in the file system (may be / on Mac OS, may be in the directory containing the VM or the current directory on other OSs, but it will be called crash.dmp, and on Mac OS info will be printed to the console or to a crash report window).  The C backtrace part of things looks like

this on windows:
Stack backtrace:
[004193EA] ??? + 4297706 in CogCode
[00442337] ??? + 4465463 in CogCode
[00442685] ??? + 4466309 in CogCode
[00583018] ??? + 5779480 in CogCode
[0040124B] ??? + 4198987 in CogCode
[00401298] ??? + 4199064 in CogCode
[7C816FE7] RegisterWaitForInputIdle + 73 in kernel32.dll
[7C913BA7] RtlDosApplyFileIsolationRedirection_Ustr + 1824 in ntdll.dll

this on Mac
C stack backtrace:
0   nsvm                                0x00038689 reportStackState + 105
1   nsvm                                0x0003893e sigsegv + 110
2   libsystem_c.dylib                   0x9b2e259b _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   nsvm                                0x0008b2a5 sufficientSpaceAfterGC + 69
5   nsvm                                0x0008d11d primitiveNewWithArg + 221
6   ???                                 0x068b9899 0x0 + 109811865
7   nsvm                                0x00098d10 initStackPagesAndInterpret + 512
8   nsvm                                0x0002c530 EventLoopEventHandler + 16

Etc.  So please feel free to email me the crash.dmp's and/or the C backtraces of any crashes you have with 2493 VMs.  Hopefully I'll track down this regression quickly.

For the curious, what's the bug?  I don't know yet. The symptom is that very rarely the inline cache linking machinery for MNU PICs relinks the call of an MNU PIC to the address 0x00000013, which causes a crash when the call is next executed, long after the bug bit.  These VMs contain code that will raise an error when the relinking attempt is made, which should reveal the bug.

Here's the 2493 readme:
CogVM binaries as per VMMaker.oscog-eem.125/r2493.  Add callsite link/relocate
checks to catch the call 0x00000013 MNU callsite relinking bug.
Reduce the size of the simStack to something proportional to LargeContextSize.

In the Newspeak VM, don't cd to the image's directory on win32.  Fix off-by-one
error in Win32OSProcessPlugin>primitiveGetCurrentWorkingDirectory so it doesn't
include an erroneous trailing null.

Fix the 1Gb allocation bug.
--
best,
Eliot




--
best,
Eliot