To reproduce, just load System-cmm.602 from a MC browser and it quits quite
fast...
>From assert cog vm, here is the end of the report:

**IncrementalGC**
**FullGC**

stack page bytes 2048 available headroom 1252 minimum unused headroom 724

    (sweep failed to find exact end of memory)
Abort trap

and the beginning is:

sweep failed to find exact end of memory

Squeak VM version: 4.0 4.0.2778 Mac OS X built on Aug  8 2013 07:43:35
Compiler: 4.2.1 (Apple Inc. build 5666) (dot 3) [Assert VM]
Built from: CoInterpreter * VMMaker.oscog-nice.336 uuid:
409e5084-5ffa-466c-a844-2473662c1ebf Sep  8 2013
With: StackToRegisterMappingCogit * VMMaker.oscog-nice.336 uuid:
409e5084-5ffa-466c-a844-2473662c1ebf Sep  8 2013
Revision: VM: r2778 http://squeakvm.org/svn/squeak/branches/Cog
Plugins: r2545 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins


C stack backtrace:
0   Squeak                              0x0004deec reportStackState + 147
1   Squeak                              0x0004e26b error + 31
2   Squeak                              0x000b43ec fullGC + 897
3   Squeak                              0x000b4cd5 sufficientSpaceAfterGC +
64
4   Squeak                              0x000b6094 primitiveNewWithArg + 147
5   ???                                 0x11acc789 0x0 + 296535945
6   Squeak                              0x000c9795 interpret + 32627
7   Squeak                              0x000429dd EventLoopEventHandler +
28
8   HIToolbox                           0x911eac2f
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
+ 1567
9   HIToolbox                           0x911e9ef6
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
+ 411
10  HIToolbox                           0x911e9d55
SendEventToEventTargetWithOptions + 58
11  HIToolbox                           0x9121ea24
_ZL29ToolboxEventDispatcherHandlerP25OpaqueEventHandlerCallRefP14OpaqueEventRefPv
+ 3006
12  HIToolbox                           0x911eb080
_ZL23DispatchEventToHandlersP14EventTargetRecP14OpaqueEventRefP14HandlerCallRec
+ 2672
13  HIToolbox                           0x911e9ef6
_ZL30SendEventToEventTargetInternalP14OpaqueEventRefP20OpaqueEventTargetRefP14HandlerCallRec
+ 411
14  HIToolbox                           0x9120c7f3 SendEventToEventTarget +
52
15  HIToolbox                           0x91395c17 ToolboxEventDispatcher +
86
16  HIToolbox                           0x91395d4f RunApplicationEventLoop
+ 243
17  Squeak                              0x00040e61
RunApplicationEventLoopWithSqueak + 185
18  Squeak                              0x0004de37 main + 1079
19  Squeak                              0x000027be start + 54


Smalltalk stack dump:
0xbffeb058 M Array(SequenceableCollection)>select: 0x13fe1d04: a(n) Array
0xbffeb074 M MCFileRepositoryInspector>versionNamesForSelectedPackage
0x135d28b0: a(n) MCFileRepositoryInspector
0xbffeb094 M MCFileRepositoryInspector(MCRepositoryInspector)>versionList
0x135d28b0: a(n) MCFileRepositoryInspector

Squeak stack has no importance, I just clicked somewhere in a MC trunk repo
inspector...

It sounds like memory corruption...

What it interesting is that loading this mcz also blow a 4.10.10
interpreter VM...

I just fail to see what could cause such a violent ... Ah WAIT WAIT WAIT:

MCPackageLoader>>basicLoad invoke RecentMessages default suspendWhile: [ ]
suspendWhile is using the last instance variable... which is being shifted
inside the suspendWhile: []...
So when we're back from the block, it's not long before die...

At least i'm happy it's not related to CharacterScanner stuff.



2013/10/16 Nicolas Cellier <nicolas.cellier.aka.nice at gmail.com>

> Ah, interesting, but MorphicExtras-nice.125.mcz is changing a class that
> is essentially unused, and I'm sure it was possible to update before...
>
>
> 2013/10/16 Bob Arning <arning315 at comcast.net>
>
>>  FWIW, after it starts loading System-cmm.602, it starts reshaping
>> MorphicExtras-nice.125. Then it dies.
>>
>> Cheers,
>> Bob
>>
>>  On 10/15/13 5:05 PM, Frank Shearar wrote:
>>
>> On 15 October 2013 21:30, Frank Shearar <frank.shearar at gmail.com> <frank.shearar at gmail.com> wrote:
>>
>>  On 15 October 2013 19:45,  <commits at source.squeak.org> <commits at source.squeak.org> wrote:
>>
>>  Chris Muller uploaded a new version of System to project The Trunk:http://source.squeak.org/trunk/System-cmm.602.mcz
>>
>> ==================== Summary ====================
>>
>> Name: System-cmm.602
>> Author: cmm
>> Time: 15 October 2013, 1:45:33.881 pm
>> UUID: 7a452144-3c88-4726-9692-a6afa93ef46e
>> Ancestors: System-eem.601
>>
>> - Support Preferences class>>#readDocumentAtStartup: false, so that Squeak can accept arbitrary arguments without requiring the first one to be a document URL.
>> - Convenience method for checking for any of the various headless VM  options.
>> - API consistency for accessing command-line arguments.
>> - Remove duplicate code (#extractParameters).  Bid to remove apparently-unused code.
>> - RecentMessages simplifications, fixes and cleanups.
>>
>> =============== Diff against System-eem.601 ===============
>>
>>  This might be temporal, or temperamental, coincidence buthttp://build.squeak.org/job/SqueakTrunk/561/console shows a segfault
>> while updating to this commit.
>>
>> I'm going to rerun the build, just in case it was a once-off. I'll
>> report back when it's done.
>>
>> Here's the top part of the stack; see the URL for full details:
>>
>>  http://build.squeak.org/job/SqueakTrunk/562/console shows it happening
>> again. So either something's very badly wrong, or something's very
>> badly wrong just on that slave. (But you'll see in its history that it
>> can run builds.)
>>
>> frank
>>
>>
>>
>>
>>
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131016/5a209c2f/attachment.htm