Begin forwarded message:

Date: Fri, 25 Dec 2015 03:41:51 -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: [Cuis-dev] More robust package loading?

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