[Vm-dev] Fw: Re: [Cuis-dev] More robust package loading?

Levente Uzonyi leves at caesar.elte.hu
Fri Dec 25 23:36:42 UTC 2015


Hi Phil,

Well, I don't know what MessageTally bug there was, but I found post 3397 
VMs unstable, as in random crashes happened using them.

Levente

On Fri, 25 Dec 2015, Phil (list) wrote:

>
> Levente,
>
> On Fri, 2015-12-25 at 20:55 +0100, Levente Uzonyi wrote:
>>  
>> If you need a stable VM, then you should use 3397.
>>
>
> I don't believe 3397 fixed the MessageTally bug reported by Juan a
> while back (which is what I was hoping to correct with 3427).  I tried
> 3397 and 3410 previously and iirc, each was less reliable than 3390 for
> me on Linux.
>
> Thanks,
> Phil
>
>> Levente
>>
>> On Fri, 25 Dec 2015, KenD wrote:
>>
>>>
>>>
>>>
>>> Begin forwarded message:
>>>
>>> Date: Fri, 25 Dec 2015 04:15:23 -0500
>>> From: "Phil \(list\) via Cuis-dev" <cuis-dev at cuis-smalltalk.org>
>>> To: Discussion of Cuis Smalltalk <cuis-dev at cuis-smalltalk.org>
>>> Cc: "Phil \(list\)" <pbpublist at gmail.com>
>>> Subject: Re: [Cuis-dev] More robust package loading?
>>>
>>>
>>> Just a quick update on my current issue for anyone else on Linux at
>>> least: I forgot that I recently upgraded my vm from 15.25.3390
>>> to 15.33.3427.  The problem appears to be the vm: 3390 loads
>> everything
>>> as expected but has problems with MessageTally, 3427 works with
>>> MessageTally but has problems loading things... grrr...
>>>
>>> Still think more robust package loading could be useful...
>>>
>>> On Fri, 2015-12-25 at 03:41 -0500, Phil (list) wrote:
>>>> Happy holidays all!  Here's my gift to the list... ;-)
>>>>
>>>> It's been a couple of weeks since I attempted to rebuild
>> completely
>>>> from a totally clean base image (2595) and of course it failed
>>>> utterly
>>>> and completely.  After some trial and error, I finally narrowed it
>>>> down
>>>> to a problem installing the stock FFI.pck.st.  I am running a
>> rather
>>>> fluid version of Linux (Debian testing) and it's entirely likely
>> that
>>>> a
>>>> recent system update is causing the problem but I'm having a
>>>> difficult
>>>> time getting more specific than that because when I attempt to
>> load
>>>> FFI, all I get is this wonderful segfault:
>>>>
>>>> C stack backtrace & registers:
>>>>         eax 0xff887b24 ebx 0xff887a40 ecx 0xff887ad8 edx
>> 0xff887a8c
>>>>         edi 0xff887910 esi 0xff887910 ebp 0xff8879a8 esp
>> 0xff8879f4
>>>>         eip 0xff887c08
>>>> *[0xff887c08]
>>>> ../lib/squeak/4.5-3427/squeak[0x805e8c0]
>>>> ../lib/squeak/4.5-3427/squeak[0x805ebac]
>>>> linux-gate.so.1(__kernel_rt_sigreturn+0x0)[0xf77a4b50]
>>>> ../lib/squeak/4.5-3427/squeak[0x80769bd]
>>>> ../lib/squeak/4.5-3427/squeak(incrementalGC+0x237)[0x807c217]
>>>> ../lib/squeak/4.5-3427/squeak[0x807cb66]
>>>> ../lib/squeak/4.5-3427/squeak[0x807cf7f]
>>>> ../lib/squeak/4.5-3427/squeak[0x807d0bd]
>>>> ../lib/squeak/4.5-3427/squeak(ceStackOverflow+0x6d)[0x807f44d]
>>>> [0xb35832e6]
>>>> ../lib/squeak/4.5-3427/squeak(interpret+0x7b6)[0x8087ef6]
>>>> ../lib/squeak/4.5-3427/squeak(main+0x2af)[0x805f30f]
>>>> /lib/i386-linux-
>>>> gnu/i686/cmov/libc.so.6(__libc_start_main+0xde)[0xf753c70e]
>>>> ../lib/squeak/4.5-3427/squeak[0x8131564]
>>>>
>>>>
>>>> Smalltalk stack dump:
>>>> 0xff894cd0 M Array(SequenceableCollection)>at:ifAbsent:
>> 0xb4c9705c:
>>>> a(n) Array
>>>> 0xff894cf0 M Array(Scanner)>typeTableAt: 0xb4ca8ee0: a(n) Array
>>>> 0xff894d0c M Array(Scanner)>scanToken 0xb4ca8ee0: a(n) Array
>>>> 0xff894d28 M Array(Parser)>advance 0xb4ca8ee0: a(n) Array
>>>> 0xff894d40 M Array(Parser)>init:notifying:failBlock: 0xb4ca8ee0:
>> a(n)
>>>> Array
>>>> 0xff894d68 M Array(Parser)>privateReadSelectorFrom: 0xb4ca8ee0:
>> a(n)
>>>> Array
>>>> 0xff894d84 M Parser class>selectorFrom: 0xb3753bd0: a(n) Parser
>> class
>>>> 0xff894da4 M INVALID RECEIVER>addMethodChange: 0xb4ca5d04: a(n)
>> bad
>>>> class
>>>> 0xff894dc0 M INVALID RECEIVER>methodChange: 0xb4ca5d04: a(n) bad
>>>> class
>>>> 0xff894ddc M CodePackageFile(CodeFile)>method: 0xb4c8f2ec: a(n)
>>>> CodePackageFile
>>>> Segmentation fault Fri Dec 25 03:05:08 2015
>>>>
>>>> (and so on...)
>>>>
>>>> Granted my main issue is largely the (lack of) information in the
>> VM
>>>> output on the crash (i.e. I have no idea what class/method/line
>> the
>>>> is
>>>> the cause of the problem) but since this is unlikely to change in
>> the
>>>> near term, some sort of verbose package loading mode would be most
>>>> helpful (i.e. 'loading method foo... completed loading method foo'
>>>> type
>>>> messages to transcript when a package is being installed)  While
>> this
>>>> is just about a worst case package loading problem for me, I have
>> had
>>>> other issues in the past loading packages (almost always with the
>>>> code
>>>> being imported, not the package loader itself) and am thinking a
>> more
>>>> robust package loading process (at least when running in some sort
>> of
>>>> debug mode) would be most welcome... does this sound useful to
>> anyone
>>>> else?
>>>>
>>>> Thanks,
>>>> Phil
>>>
>>> _______________________________________________
>>> Cuis-dev mailing list
>>> Cuis-dev at cuis-smalltalk.org
>>> http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.
>> org
>>>
>>>
>>> -- 
>>> -KenD
>>>
>


More information about the Vm-dev mailing list