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

Sun Jan 17 01:49:11 UTC 2016

On Fri, Dec 25, 2015 at 3:36 PM, Levente Uzonyi <leves at caesar.elte.hu>
wrote:

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

Can I have a test case please?

>
> 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
>>>>
>>>>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160116/875b8a20/attachment.htm