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
I'm not on a Mac to test, but it might be worth browsing the top few of these..
cheers -ben
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.