2016-02-08 10:11 GMT+01:00 Nicolai Hess nicolaihess@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@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@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:
- delete a line. If the line’s too short it won’t work though
- 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@openInWorld.com btc@openinworld.com> wrote:
On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias tinchodias@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@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@lists.pharo.org pharo-dev-bounces@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-fi...
Best regards,
Henrik
From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Blondeau Vincent Sent: Friday, February 5, 2016 1:54 PM To: Pharo Development List pharo-dev@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@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@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...
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.