Hmmm Ben - its interesting that other languages/environments show that same stack error - and they seem to hint at memory issues- although in our case I’m working with a simple Pharo image that has very little in it (I’ve had much larger ones in Pharo 6.x without issue).
Interestingly - since launching a zeroconf image and not going full screen - its been running now for 1.5 days without a crash (whereas previously around 24 hours or less it would crash). Having said this - I’ve just started another clean zeroconf image (not full screen) and during the initial metecallo (iceberg) load - its seg faulted again - but this one I think is iceberg related as the crash.dmp looks a bit different, and I did notice that it was loading my baseline a bit slowly (and stifling with some of the dependencies, making me think that something timing related might be at issue). Having said this - I’m still not having the smooth ride others are reporting - and 7 is still suspect to me. I’m kind of suprised this isn’t getting much traction from the core team - and I wonder if I should post this on the dev list instead? Tim > On 16 Feb 2019, at 16:27, Ben Coman <b...@openinworld.com> wrote: > > I'm not on a Mac to test, but it might be worth browsing the top few of > these.. > https://github.com/search?o=desc&q=can%27t+allocate+region+securely&s=created&type=Issues > > <https://github.com/search?o=desc&q=can%27t+allocate+region+securely&s=created&type=Issues> > > cheers -ben > > On Sat, 16 Feb 2019 at 20:10, Tim Mackinnon <tim@testit.works> wrote: > I’ve actually being using both - but 32bit has generally been considered the > older more stable cousin (until Pharo 6 - where it was felt that 64bit was > now just as stable). > > I only mentioned it - because the zeroconf example that has crashed a few of > my several times - was 32 bit (but I have also had 64 bit crash too. Probably > a good experiment to try zeroconf with the 64bit variation and load my > baseline as well). > > I just think we might have an easily reproducable (and small) example that > shows this issue that many have experienced a bit more randomly. >
