[Pharo-users] Stability of Pharo 7 vs 6?

Tim Mackinnon tim at testit.works
Sun Feb 17 20:00:51 EST 2019


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 <btc at 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 at 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-users_lists.pharo.org/attachments/20190218/1134192c/attachment-0001.html>


More information about the Pharo-users mailing list