(sent again with dump zipped) Hello, I just built a new VM for 64bits with latest sources and is crashing in mac :( Latest version I tested (and it was working) was based on VMMaker.oscog-nice.1991 and is from november 2016. I’m adding the dump… any idea? Esteban crash.dmp.zip (86K) Download Attachment |
Hi Esteban, can you put your image up somewhere and I'll take a look? It crashes on startup? _,,,^..^,,,_ (phone) > On Jan 9, 2017, at 5:02 AM, Esteban Lorenzano <[hidden email]> wrote: > > (sent again with dump zipped) > > Hello, > > I just built a new VM for 64bits with latest sources and is crashing in mac :( > Latest version I tested (and it was working) was based on VMMaker.oscog-nice.1991 and is from november 2016. > > I’m adding the dump… > > any idea? > > Esteban > > > <crash.dmp.zip> |
In reply to this post by EstebanLM
Esteban, On Mon, Jan 9, 2017 at 5:02 AM, Esteban Lorenzano <[hidden email]> wrote:
What version are you building from? Latest version I tested (and it was working) was based on VMMaker.oscog-nice.1991 and is from november 2016. there was a Slang bug that caused new sources to break that I fixed in VMMaker.oscog-eem.2071. What version are you working from?
_,,,^..^,,,_ best, Eliot |
In reply to this post by EstebanLM
and since it's crashing in GC you could run with the leak checker enabled (e.g --leakcheck 3) and see if it shows anything before the crash. On Mon, Jan 9, 2017 at 5:02 AM, Esteban Lorenzano <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
In reply to this post by Eliot Miranda-2
15 GLEngine 0x00007fffc882ce18 glFlush_ExecThread + 15 16 Pharo 0x00000001084b67f6 -[sqSqueakOSXOpenGLView drawThelayers] + 116 17 Pharo 0x00000001084bdf26 -[sqSqueakScreenAndWindow ioForceDisplayUpdate] + 188 18 Pharo 0x00000001084bdc0b ioForceDisplayUpdate + 61 19 Pharo 0x000000010847cc67 primitiveShowDisplayRect + 228 It is possible we are trying to draw a screen size bigger than what has been allocated in the image. I had added a number of changes last fall to prevent that during screen resizing, so maybe a better guard clauses is needed? On Mon, Jan 9, 2017 at 8:34 AM, Eliot Miranda <[hidden email]> wrote:
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== |
Silly me, the crash.dmp file has 4 different crash logs in it... The openGL one is quite stale. On Mon, Jan 9, 2017 at 8:43 AM, John McIntosh <[hidden email]> wrote:
=========================================================================== John M. McIntosh. Corporate Smalltalk Consulting Ltd https://www.linkedin.com/in/smalltalk =========================================================================== |
In reply to this post by Eliot Miranda-2
is just a regular pharo64 image, http://files.pharo.org/get-files/60/pharo-64.zip and yes, it crashes at startup. Esteban
|
In reply to this post by johnmci
oops… that’s why is so big ;) Esteban
|
In reply to this post by Eliot Miranda-2
build.macos64x64/pharo.cog.spur
the version I built is with VMMaker.oscog-rsf.2077 and latest platform sources. Esteban
|
In reply to this post by johnmci
Hi Esteban, I just generated fresh sources and I see multiple assert fails in GC. I'm taking a look. On Mon, Jan 9, 2017 at 8:43 AM, John McIntosh <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
thanks Eliot :)
|
In reply to this post by EstebanLM
Hi All, Hi Nicolas, Hi Esteban, ok, I see the problem. It's a Slang bug. With current Slang and current sources, turning off the remembered bit clears half the header word on 64-bits. i.e. setIsRememberedOf: referrer to: false translates to longAtput(referrer, (longAt(referrer)) & (~(1U << (rememberedBitShift())))); not longAtput(referrer, (longAt(referrer)) & (~(1UL << (rememberedBitShift())))); and 1U is an int. No doubt this affects plenty of places in the VM, but for now the first symptom I see is the above, when remembered objects are scavenged and their remembered bit gets cleared. I think the simple fix is that numeric constants should always be 1UL, or 1L, never 1U or 1, but I need to check the 32-bit sources too. Anyway, we should be able to fix this soon, certainly before tomorrow a.m. CET. On Mon, Jan 9, 2017 at 5:02 AM, Esteban Lorenzano <[hidden email]> wrote:
_,,,^..^,,,_ best, Eliot |
On Mon, Jan 9, 2017 at 11:26 AM, Eliot Miranda <[hidden email]> wrote:
And always casting integer constants to at least long would be wrong because Win64 is LLP64. In fact the bug is in generateBitInvert:on:indent:, which for bitnvert64, now that we handle LLP64, needs to cast integer expressions to usqIntptr_t in 64-bits and to unsigned long long in 32 bits.
Normal service should be restored shortly ;-) [sschurley broken /is/ normal service, hic! ed.]
_,,,^..^,,,_ best, Eliot |
Free forum by Nabble | Edit this page |