Begin forwarded message: Date: Fri, 25 Dec 2015 04:15:23 -0500 From: "Phil \(list\) via Cuis-dev" <[hidden email]> To: Discussion of Cuis Smalltalk <[hidden email]> Cc: "Phil \(list\)" <[hidden email]> 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 [hidden email] http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org -- -KenD
-KenD
|
If you need a stable VM, then you should use 3397. 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" <[hidden email]> > To: Discussion of Cuis Smalltalk <[hidden email]> > Cc: "Phil \(list\)" <[hidden email]> > 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 > [hidden email] > http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk.org > > > -- > -KenD > |
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" <[hidden email]> > > To: Discussion of Cuis Smalltalk <[hidden email]> > > Cc: "Phil \(list\)" <[hidden email]> > > 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 > > [hidden email] > > http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk. > org > > > > > > -- > > -KenD > > |
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" <[hidden email]> >>> To: Discussion of Cuis Smalltalk <[hidden email]> >>> Cc: "Phil \(list\)" <[hidden email]> >>> 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 >>> [hidden email] >>> http://cuis-smalltalk.org/mailman/listinfo/cuis-dev_cuis-smalltalk. >> org >>> >>> >>> -- >>> -KenD >>> > |
On Fri, Dec 25, 2015 at 3:36 PM, Levente Uzonyi <[hidden email]> wrote:
Can I have a test case please?
_,,,^..^,,,_ best, Eliot |
On Sat, 16 Jan 2016, Eliot Miranda wrote: Had I had a reproducible case, I would have already let you know about it. Levente |
Free forum by Nabble | Edit this page |