On Fri, Dec 25, 2015 at 3:36 PM, Levente Uzonyi <leves@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.

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@cuis-smalltalk.org>
To: Discussion of Cuis Smalltalk <cuis-dev@cuis-smalltalk.org>
Cc: "Phil \(list\)" <pbpublist@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@cuis-smalltalk.org
http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.

org

-- 
-KenD