[Vm-dev] Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

Sun May 15 14:21:59 UTC 2016

2016-02-08 10:11 GMT+01:00 Nicolai Hess <nicolaihess at gmail.com>:

> I traced this back to
> Object>>withArgs:executeMethod:
> (primitive 188)
>
> in OpalCompiler>>#evaluate
>
> It does not happen on squeaks spur vm as far as I know (but I don't know
> what is the latests squeak spur vm).
>
>
>
>
>
> 2016-02-08 5:17 GMT+01:00 Martin Dias <tinchodias at gmail.com>:
>
>> Very interesting...
>>
>> I created case 17543
>> <https://pharo.fogbugz.com/f/cases/17543/VM-crash-in-Windows-when-compiling-many-symbols>,
>> with Vincent's script and other quotes from this thread. I did it because
>> this Windows issue is independent from Epicea (whose integration only
>> exposed the Windows issue).
>>
>> Martin
>>
>
I added a note to the issue report:

the crash happens in the vm, in method compileCogMethod (mingw library
__chkstk_ms).
This method (__chkstk_ms) is called on the call to alloca()
There is a check in compileCogMethod for the size of allocated:

    if (allocSize > MaxStackAllocSize) {

And on a squeak cog spur vm, evaluating this long list of symbols does not
crash.
I compared the "Size of Stack reserve" value in the image header
(PE-Header) of squeaks and pharos vm executable:
squeak : 0x00400000
pharo :  0x00200000
Somehow, the default stack size is twice as large in squeak than in pharos
vm.

If I add this change to:

CogWindowsConfig>>#setExtraTargetProperties: maker
    maker addExternalLibraries: self externalLibraries.
    maker set: 'EXECUTABLE_OUTPUT_PATH' toString: '${outputDir}'.

    maker set: 'CMAKE_EXE_LINKER_FLAGS' toString:'${CMAKE_EXE_LINKER_FLAGS}
-Wl,--stack,4194304'.  "<<---- NEW ! "
    maker puts: 'set_source_files_properties(${srcVMDir}/gcc3x-cointerp.c
PROPERTIES COMPILE_FLAGS -O1)'

the executeble will have the "Size of Stack reserve" value in pharo.
And evaluating this long list of symbols does not crash the vm anymore.

>
>> On Sat, Feb 6, 2016 at 6:41 AM, Max Leske <maxleske at gmail.com> wrote:
>>
>>> Changing the scheduler didn’t have any effect. However, it seems to me
>>> that the size of the input matters. I can make it work in two ways:
>>> 1. delete a line. If the line’s too short it won’t work though
>>> 2. delete a couple of characters from some symbols
>>>
>>> That would suggest that not the number of symbols / items in the array
>>> is significant but the number of bytes. So maybe there’s a problem with
>>> memory allocation in the VM. I haven’t been able to come up with an exact
>>> number, but the VM starts crashing at around 7096 characters. Sometimes I
>>> can go over 7100, other times not. Smaller numbers always work.
>>>
>>> HTH,
>>> Max
>>>
>>> On 06 Feb 2016, at 07:25, Ben Coman <btc at openInWorld.com
>>> <btc at openinworld.com>> wrote:
>>>
>>> On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias at gmail.com>
>>> wrote:
>>>
>>> In fact, this integration step
>>> (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z)
>>> was
>>> already passed by Epicea in December. That was before spur, it might be
>>> related to spur.
>>>
>>> That time, the integration of Epicea revealed a bug in delay's
>>> scheduling...
>>>
>>>
>>> Was that these issues integrated in build 50466...
>>> https://pharo.fogbugz.com/default.asp?17066
>>> https://pharo.fogbugz.com/default.asp?13756
>>>
>>> which should have left the current scheduler as
>>> DelayExperimentalSpinScheduler
>>> but in current build 50564 "Delay delaySchedulerClass" -->
>>> DelayMicrosecondScheduler
>>>
>>> Maybe Delay class >> initialize has been executed since
>>>      Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ].
>>>      Scheduler := DelayMicrosecondScheduler new.
>>>      Scheduler startTimerEventLoop.
>>>      Smalltalk addToStartUpList: self.
>>>
>>> but I don't see any updates that might have invoked it.
>>> Anyway, maybe changing that will help.
>>>
>>> cheers -ben
>>>
>>>
>>>
>>> maybe now it's revealing some bug in Windows+spur...?
>>>
>>> Martin
>>>
>>>
>>> On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent
>>> <vincent.blondeau at worldline.com> wrote:
>>>
>>>
>>> If you remove any line, it stops crashing…
>>>
>>> I really don’t know what is going on…
>>>
>>>
>>>
>>> Vincent
>>>
>>>
>>>
>>> De : Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org
>>> <pharo-dev-bounces at lists.pharo.org>] De la part de
>>> Henrik Nergaard
>>> Envoyé : vendredi 5 février 2016 14:03
>>>
>>>
>>> À : Pharo Development List
>>> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE:
>>> [ANN]
>>> We are in "code freeze" for Pharo 5)
>>>
>>>
>>>
>>> Removing
>>>
>>> #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp:
>>> visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral:
>>> visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable:
>>> visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray:
>>> visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp:
>>> visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar:
>>> visitSend: ))
>>>
>>> And it stops crashing.
>>>
>>>
>>>
>>> - BTW, there is not crash.dmp, does it works with spur?
>>>
>>>
>>>
>>> https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-file-is-created-but-nothing-is-written-to-it-Windows
>>>
>>>
>>>
>>> Best regards,
>>>
>>> Henrik
>>>
>>>
>>>
>>> From: Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org] On Behalf Of
>>> Blondeau Vincent
>>> Sent: Friday, February 5, 2016 1:54 PM
>>> To: Pharo Development List <pharo-dev at lists.pharo.org>
>>> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE:
>>> [ANN] We are in "code freeze" for Pharo 5)
>>>
>>>
>>>
>>> Very strange bug indeed that happens on windows machines that crashes the
>>> VM. I succeeded to reduce the problem to an evaluation of a collection…
>>>
>>> Can someone have the same issue under Windows or Mac?
>>>
>>>
>>>
>>> To reproduce : Copy paste the contents of the attached file in the
>>> playground and print it or do it
>>>
>>> It works on pre-spur vm.
>>>
>>>
>>>
>>> BTW, there is not crash.dmp, does it works with spur?
>>>
>>> Vincent
>>>
>>>
>>>
>>> De : Pharo-dev [mailto:pharo-dev-bounces at lists.pharo.org] De la part de
>>> Marcus Denker
>>> Envoyé : vendredi 5 février 2016 13:01
>>> À : Pharo Development List
>>> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE:
>>> [ANN]
>>> We are in "code freeze" for Pharo 5)
>>>
>>>
>>>
>>>
>>>
>>> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker at inria.fr> wrote:
>>>
>>>
>>>
>>> I will try do integrate it now…
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> No, it still fails.
>>>
>>>
>>>
>>>
>>>
>>> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/label=win/706/
>>>
>>>
>>>
>>> The last test it executed seems to be this:
>>>
>>> running suite: Refactoring-Tests-Environment
>>>
>>> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ...
>>>
>>> Very strange...
>>>
>>>       Marcus
>>>
>>>
>>>
>>>
>>>
>>> ________________________________
>>>
>>>
>>> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
>>> exclusif de ses destinataires. Il peut également être protégé par le
>>> secret
>>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
>>> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
>>> pouvant être assurée sur Internet, la responsabilité de Worldline ne
>>> pourra
>>> être recherchée quant au contenu de ce message. Bien que les meilleurs
>>> efforts soient faits pour maintenir cette transmission exempte de tout
>>> virus, l'expéditeur ne donne aucune garantie à cet égard et sa
>>> responsabilité ne saurait être recherchée pour tout dommage résultant
>>> d'un
>>> virus transmis.
>>>
>>> This e-mail and the documents attached are confidential and intended
>>> solely for the addressee; it may also be privileged. If you receive this
>>> e-mail in error, please notify the sender immediately and destroy it. As
>>> its
>>> integrity cannot be secured on the Internet, the Worldline liability
>>> cannot
>>> be triggered for the message content. Although the sender endeavours to
>>> maintain a computer virus-free network, the sender does not warrant that
>>> this transmission is virus-free and will not be liable for any damages
>>> resulting from any virus transmitted.
>>>
>>>
>>> ________________________________
>>>
>>> Ce message et les pièces jointes sont confidentiels et réservés à l'usage
>>> exclusif de ses destinataires. Il peut également être protégé par le
>>> secret
>>> professionnel. Si vous recevez ce message par erreur, merci d'en avertir
>>> immédiatement l'expéditeur et de le détruire. L'intégrité du message ne
>>> pouvant être assurée sur Internet, la responsabilité de Worldline ne
>>> pourra
>>> être recherchée quant au contenu de ce message. Bien que les meilleurs
>>> efforts soient faits pour maintenir cette transmission exempte de tout
>>> virus, l'expéditeur ne donne aucune garantie à cet égard et sa
>>> responsabilité ne saurait être recherchée pour tout dommage résultant
>>> d'un
>>> virus transmis.
>>>
>>> This e-mail and the documents attached are confidential and intended
>>> solely for the addressee; it may also be privileged. If you receive this
>>> e-mail in error, please notify the sender immediately and destroy it. As
>>> its
>>> integrity cannot be secured on the Internet, the Worldline liability
>>> cannot
>>> be triggered for the message content. Although the sender endeavours to
>>> maintain a computer virus-free network, the sender does not warrant that
>>> this transmission is virus-free and will not be liable for any damages
>>> resulting from any virus transmitted.
>>>
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160515/2b9d8fec/attachment-0001.htm