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

[Phil (list)]

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