Vm-dev May 2013

vm-dev@lists.squeakfoundation.org

20 participants
145 discussions

VM Maker: CMakeVMMaker-IgorStasenko.205.mcz
by commits＠source.squeak.org 30 May '13

30 May '13

Igor Stasenko uploaded a new version of CMakeVMMaker to project VM Maker: http://source.squeak.org/VMMaker/CMakeVMMaker-IgorStasenko.205.mcz ==================== Summary ==================== Name: CMakeVMMaker-IgorStasenko.205 Author: IgorStasenko Time: 30 May 2013, 3:37:29.743 pm UUID: 1387af88-274a-4677-83c3-fcce592e2bce Ancestors: CMakeVMMaker-EstebanLorenzano.204 - change 3rd party libs download logic to try downloading from pharo file server first =============== Diff against CMakeVMMaker-EstebanLorenzano.204 =============== Item was changed: ----- Method: CMCairo>>unpack (in category 'generating actions') ----- unpack "produce commands for unpacking the library archive. the output of this command should use a directory ${workDir}/${libName} where the unpacked library sources will be located. see #setVariables method for understanding what variables used here NOTE: had to override since cairo uses 7z compression " gen set: #unpackTarget toString: '${libSourcesDir}/touch.cmake'. gen puts: 'add_custom_command(OUTPUT "${unpackTarget}" + COMMAND tar -Jxf "${archiveFileName}" - COMMAND tar -Jxf "${libName}.tgz" COMMAND touch "${unpackTarget}" COMMENT "Unpacking ${libName} ... " ) '. ! Item was added: + ----- Method: CMThirdpartyLibrary>>archiveFileName (in category 'as yet unclassified') ----- + archiveFileName + ^ self downloadURL asUrl fileName ! Item was changed: ----- Method: CMThirdpartyLibrary>>download (in category 'generating actions') ----- download "Produce output to download library archive. By default, we use .tgz extension.. since it is most often used by OSS. Note, that we check if file is already present, to not download it every time we build" gen puts: + 'if (NOT EXISTS "${workDir}/${archiveFileName}") + Message("Downloading ',self fileServerURL,'${archiveFileName}") + - 'if (NOT EXISTS "${workDir}/${libName}.tgz") - Message("Downloading ${url} ....") - Message("Into: ${workDir}/${libName}.tgz") - FILE(DOWNLOAD + ', self fileServerURL , self archiveFileName ,' + "${workDir}/${archiveFileName}" + STATUS downloadStatus - ${url} - "${workDir}/${libName}.tgz" SHOW_PROGRESS - EXPECTED_MD5 ${md5sum} ) + + LIST(GET downloadStatus 0 downloadError) + if (NOT downloadError EQUAL 0) + Message("File is missing on file server (', self fileServerURL,'), downloading from official repository...") + FILE(DOWNLOAD + ${url} + "${workDir}/${archiveFileName}" + STATUS downloadStatus + SHOW_PROGRESS + EXPECTED_MD5 ${md5sum} + ) + LIST(GET downloadStatus 0 downloadError) + endif () + if (NOT downloadError EQUAL 0) + message(FATAL_ERROR "Cannot find/download the source file from:" ${url}) + endif () + + + endif () - endif (NOT EXISTS "${workDir}/${libName}.tgz") '! Item was added: + ----- Method: CMThirdpartyLibrary>>fileServerURL (in category 'settings') ----- + fileServerURL + "Base url to file server where all external libs sources stored" + ^'http://files.pharo.org/vm/src/lib/'! Item was changed: ----- Method: CMThirdpartyLibrary>>setVariables (in category 'generating actions') ----- setVariables gen set: #libName toString: self canonicalName; set: #workDir toString: '${thirdpartyDir}/${libName}'; set: #unpackedDirName toString: self unpackedDirName; set: #libSourcesDir toString: '${workDir}/${unpackedDirName}'; set: #url toString: self downloadURL; set: #md5sum toString: self archiveMD5Sum; + set: #archiveFileName toString: self archiveFileName; set: #installPrefix toString: '${thirdpartyDir}/out'.! Item was changed: ----- Method: CMThirdpartyLibrary>>unpack (in category 'generating actions') ----- unpack "produce commands for unpacking the library archive. the output of this command should use a directory ${workDir}/${libName} where the unpacked library sources will be located. see #setVariables method for understanding what variables used here " gen set: #unpackTarget toString: '${libSourcesDir}/touch.cmake'. gen puts: 'add_custom_command(OUTPUT "${unpackTarget}" + COMMAND tar -xzf "${archiveFileName}" - COMMAND tar -xzf "${libName}.tgz" COMMAND touch "${unpackTarget}" COMMENT "Unpacking ${libName} ... " ) '. ! Item was changed: + ----- Method: CMWin32ZLib>>archiveMD5Sum (in category 'package properties') ----- - ----- Method: CMWin32ZLib>>archiveMD5Sum (in category 'as yet unclassified') ----- archiveMD5Sum "answer the MD5 checksum (in string) for downloaded library archive (to check that downloaded file is not corrupt). You can take this sum by issuing: md5 filename from command line " ^ '44d667c142d7cda120332623eab69f40'! Item was changed: + ----- Method: CMWin32ZLib>>build (in category 'generating actions') ----- - ----- Method: CMWin32ZLib>>build (in category 'as yet unclassified') ----- build ' COMMAND ./configure --prefix="${installPrefix}" --archs="-arch i386" '. gen puts: ' add_custom_command(OUTPUT "${libzInstalled}" COMMAND make -fwin32/Makefile.gcc COMMAND make install -fwin32/Makefile.gcc prefix="${installPrefix}" INCLUDE_PATH="${installPrefix}/include" LIBRARY_PATH="${installPrefix}/lib" BINARY_PATH="${installPrefix}/bin" SHARED_MODE=1 WORKING_DIRECTORY "${libSourcesDir}" DEPENDS "${unpackTarget}" COMMENT "Building ${libName}" ) ' ! Item was changed: + ----- Method: CMWin32ZLib>>copyArtefacts (in category 'generating actions') ----- - ----- Method: CMWin32ZLib>>copyArtefacts (in category 'as yet unclassified') ----- copyArtefacts self copy: '${libzInstalled}' to: '${externalModulesDir}/${libraryFileName}' ! Item was changed: + ----- Method: CMWin32ZLib>>defineAsTarget (in category 'generating actions') ----- - ----- Method: CMWin32ZLib>>defineAsTarget (in category 'as yet unclassified') ----- defineAsTarget gen puts: 'add_custom_target(', self buildTarget , ' DEPENDS "${externalModulesDir}/${libraryFileName}" )' "${externalModulesDir}/${libraryFileName}" ! Item was changed: + ----- Method: CMWin32ZLib>>defineGlobalTargets (in category 'generating actions') ----- - ----- Method: CMWin32ZLib>>defineGlobalTargets (in category 'as yet unclassified') ----- defineGlobalTargets ! Item was changed: + ----- Method: CMWin32ZLib>>downloadURL (in category 'package properties') ----- - ----- Method: CMWin32ZLib>>downloadURL (in category 'as yet unclassified') ----- downloadURL ^ 'http://zlib.net/zlib-1.2.8.tar.gz'! Item was changed: + ----- Method: CMWin32ZLib>>libraryFileName (in category 'package properties') ----- - ----- Method: CMWin32ZLib>>libraryFileName (in category 'as yet unclassified') ----- libraryFileName ^ 'zlib1.dll'! Item was changed: + ----- Method: CMWin32ZLib>>setVariables (in category 'generating actions') ----- - ----- Method: CMWin32ZLib>>setVariables (in category 'as yet unclassified') ----- setVariables super setVariables. gen set: #libraryFileName to: self libraryFileName; set: #libzInstalled toString: '${installPrefix}/bin/${libraryFileName}'. ! Item was changed: + ----- Method: CMWin32ZLib>>unpackedDirName (in category 'package properties') ----- - ----- Method: CMWin32ZLib>>unpackedDirName (in category 'as yet unclassified') ----- unpackedDirName ^ 'zlib-1.2.8'!

1 0

Fwd: [Pharo-fuel] Possible collections problem
by Max Leske 30 May '13

30 May '13

Hi I'm forwarding this because I'd like to rule out a VM problem. Short summary: I fork a squeak image and then serialize objects with Fuel. In roughly 40% of the cases the fork suddenly locks and consumes 100% CPU. The trace I most often see with gdb in that case is the one with "#0 0x08060453 in updatePointersInRootObjectsFromto ()" at the top. The object processed when the lockup occufrs is always of class Timestamp, although that doesn't necessarily mean anything. Maybe it's more about the number of objects. I'm working on Debian, 32-bit and I can reproduce the problem with SqueakVM 4.4.7-2364 and 4.0.3-2202 (the newer ones wont run because of glibc). I haven't tried Cog yet. I also just checked that the problem occurs even if I don't serialize any timestamps (nor Process, Delay, Monitor, Semaphore; just to be sure). So if anyone has a clue as to what might be going on I'd really appreciate the help. Cheers, Max Begin forwarded message: > From: Mariano Martinez Peck <marianopeck(a)gmail.com> > Subject: Re: [Pharo-fuel] Possible collections problem > Date: 15. Mai 2013 16:53:10 MESZ > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > I cannot see anything in particular. Too many GC stuff. > So I wouldn't spend more time trying to debug. I would try the none large collections. Then I would try with latest Cog and latest StackVM. > > > > On Wed, May 15, 2013 at 11:47 AM, Max Leske <maxleske(a)gmail.com> wrote: > I've had several forks hanging around just now. Apart from one all of these were locked. I attached gdb and generated the c stack for all of them. Not sure if there's anything really interesting in there although clearly a lot of time is spent in GC and with creation of objects. That doesn't have to mean anything though. > > I haven't yet tried your suggestion Mariano. > > Cheers, > Max > > > [Thread debugging using libthread_db enabled] > 0x08060453 in updatePointersInRootObjectsFromto () > > #0 0x08060453 in updatePointersInRootObjectsFromto () > #1 0x08060a77 in mapPointersInObjectsFromto () > #2 0x08060bb0 in incCompBody () > #3 0x08065fa7 in incrementalGC () > #4 0x080661a4 in sufficientSpaceAfterGC () > #5 0x08069420 in primitiveNew () > #6 0x0806de15 in interpret () > #7 0x08073dfe in main () > > > > [Thread debugging using libthread_db enabled] > 0x08060453 in updatePointersInRootObjectsFromto () > > #0 0x08060453 in updatePointersInRootObjectsFromto () > #1 0x08060a77 in mapPointersInObjectsFromto () > #2 0x08060bb0 in incCompBody () > #3 0x08065fa7 in incrementalGC () > #4 0x080661a4 in sufficientSpaceAfterGC () > #5 0x08069420 in primitiveNew () > #6 0x0806de15 in interpret () > #7 0x08073dfe in main () > > > > > [Thread debugging using libthread_db enabled] > 0x08060453 in updatePointersInRootObjectsFromto () > > #0 0x08060453 in updatePointersInRootObjectsFromto () > #1 0x08060a77 in mapPointersInObjectsFromto () > #2 0x08060bb0 in incCompBody () > #3 0x08065fa7 in incrementalGC () > #4 0x080661a4 in sufficientSpaceAfterGC () > #5 0x0806fed2 in clone () > #6 0x08070095 in primitiveClone () > #7 0x0806de15 in interpret () > #8 0x08073dfe in main () > > > [Thread debugging using libthread_db enabled] > 0x08060453 in updatePointersInRootObjectsFromto () > > #0 0x08060453 in updatePointersInRootObjectsFromto () > #1 0x08060a77 in mapPointersInObjectsFromto () > #2 0x08060bb0 in incCompBody () > #3 0x08065fa7 in incrementalGC () > #4 0x080661a4 in sufficientSpaceAfterGC () > #5 0x08069270 in primitiveNewWithArg () > #6 0x0806de15 in interpret () > #7 0x08073dfe in main () > > > [Thread debugging using libthread_db enabled] > 0xb76f0f68 in select () from /lib/libc.so.6 > > #0 0xb76f0f68 in select () from /lib/libc.so.6 > #1 0x08070880 in aioPoll () > #2 0xb762419e in ?? () from /usr/lib/squeak/4.0.3-2202//so.vm-display-X11 > #3 0x08073595 in ioRelinquishProcessorForMicroseconds () > #4 0x08061f24 in primitiveRelinquishProcessor () > #5 0x0806de15 in interpret () > #6 0x08073dfe in main () > > > [Thread debugging using libthread_db enabled] > 0x08060453 in updatePointersInRootObjectsFromto () > > #0 0x08060453 in updatePointersInRootObjectsFromto () > #1 0x08060a77 in mapPointersInObjectsFromto () > #2 0x08060bb0 in incCompBody () > #3 0x08065fa7 in incrementalGC () > #4 0x080661a4 in sufficientSpaceAfterGC () > #5 0x08069420 in primitiveNew () > #6 0x0806de15 in interpret () > #7 0x08073dfe in main () > > > > [Thread debugging using libthread_db enabled] > 0x08064e7e in markAndTrace () > > #0 0x08064e7e in markAndTrace () > #1 0x0806593a in markPhase () > #2 0x08065f60 in incrementalGC () > #3 0x080661a4 in sufficientSpaceAfterGC () > #4 0x0806fed2 in clone () > #5 0x08070095 in primitiveClone () > #6 0x0806de15 in interpret () > #7 0x08073dfe in main () > > > > > On 15.05.2013, at 13:59, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> Ok. So, first thing you should try, is to replace the uses of LargeIdentityDictionary with IdentityDictionary. And LargeIdentitySet with IdentitySet. >> If the problem disappears, then yes, there is something wrong with LargeCollections. If there is a problem with them, try updating VM, since they use a particular primitive. >> Let us know! >> >> >> On Tue, May 14, 2013 at 9:29 AM, Max Leske <maxleske(a)gmail.com> wrote: >> >> On 14.05.2013, at 13:52, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: >> >>> Hi Max. Question, are you able to reproduce the problem? >> >> Yes, but not "on purpose". The situation usually happens once or twice a day and then with consistent log entries. That's why I want to use gdb the next time it happens. >> >>> >>> >>> On Tue, Apr 30, 2013 at 3:57 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> Hi guys >>> >>> I have a problem serializing a graph. Sometimes (not always) the image will consume +/- 100% CPU and stop responding. I was able to pin the problem down a bit: >>> - fails always in FLIteratingCluster>>registerIndexesOn: when called from FLFixedObjectCluster with class TimeStamp (this might not actually be relevan but it's consistent) >>> - the problem *might* be in FLLargeIdentityDictionary>>at:put: (or further up the stack) >>> >>> I've done excessive logging to a file but even with flushing after every write the results are not consistent. Sometimes the image locks after leaving #at:put: sometimes it does somewhere in the middle or in #registerIndexesOn: (but remember: the logging might not be precise). >>> >>> It's probably not the size of the objects in the cluster (the graph is big but not overly large), since there are other clusters with more objects. >>> >>> What I did find is that the #grow operation for HashedCollections can be *very* slow, up to 20 seconds or more, at other times the snapshot runs through within no time. >>> >>> So here's my theory: There migth be a VM problem with HashedCollections. >>> Now, the VM is a rather old one and I haven't had the possibility to test this with a newer one (but I'll probably have to). The version is Squeak4.0.3-2202 running on 32-bit Debian Squeeze. >>> >>> I'll try some more but if anyone has any ideas I'd be very happy :) >>> >>> Cheers, >>> Max >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > > > -- > Mariano > http://marianopeck.wordpress.com > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

3 13

Fwd: Bug#710367: squeak-vm: ftbs with ld --as-needed
by Bert Freudenberg 30 May '13

30 May '13

Begin forwarded message: > Resent-From: Julian Taylor <jtaylor.debian(a)googlemail.com> > From: Julian Taylor <jtaylor.debian(a)googlemail.com> > Subject: Bug#710367: squeak-vm: ftbs with ld --as-needed > Date: 30. Mai 2013 11:23:23 MESZ > Resent-To: debian-bugs-dist(a)lists.debian.org > To: Debian Bug Tracking System <submit(a)bugs.debian.org> > Resent-Cc: Debian Squeak Team <pkg-squeak-devel(a)lists.alioth.debian.org> > Reply-To: Julian Taylor <jtaylor.debian(a)googlemail.com>, 710367(a)bugs.debian.org > > Package: squeak-vm > Version: 1:4.10.2.2614-1 > Severity: wishlist > User: debian-gcc(a)lists.debian.org > Usertags: ld-as-needed > Tags: patch > > squeak-vm fails to build with ld --as-needed. > With --as-needed libraries need to be placed before objects needing > their symbols (including static libraries). > > Attached patch adapts the avoid_embedded_libs.patch to order the > commandline correctly. >

1 0

Keeping Pharo CPU usage low: how?
by phil＠highoctane.be 28 May '13

28 May '13

I am currently experimenting with Pharo on Amazon EC2. I'd like to keep the CPU usage low for when Pharo hasn't anything special to do. At the moment, I see that Pharo uses 2-3% of the CPU when just blinking the caret. Is there a way to get that lower? Even if it means tweaking the VM. The OS is Ubuntu 12 LTS Thanks!

2 1

CompiledMethod basicAt: problem
by Pavel Krivanek 26 May '13

26 May '13

Hi, for the Pharo Kernel ImageMap job I do something like m := CompiledMethod allInstances anyOne. 1 to: m basicSize do:[:i | m basicAt:i ]. For previous VMs it worked well without error but now the primitive fails and the SubscriptOutOfBounds error is raised at index 1. Fails on the latest Pharo VM and VM by Eliot r2714. Cheers, -- Pavel

2 2

BFS and CFS and Cogs, Oh My
by Casey Ransberger 25 May '13

25 May '13

I had a brief chat with Con Kolivas, who did BFS (which implements kernel stuff that will make Cog happier under Linux on machines with sub-supercomputing quantities of CPUs) tonight. It sounds like there are actually two reasons it hasn't made it into the mainline kernel: a) he doesn't have time to support it, and b) the other kernel folks don't want it. Oh well. Since right now I'm focused on Raspbian, I sent a message explaining what it was, why I want it, etc on their web board. If I do get it in, support would have to fall to me. Yikes, right? ;) Basically it would be a fork, done with the original author's blessing. This would also make it easy to change the (rather unfortunate) f-ing name of the thing. For the curious, at the end of this message I'm linking to a bit about why he wrote it. It's worth mentioning that it's rather in the spirit of simple-is-better, which I think fits with the Squeak ethos a little. Not to mention that it's aimed at the desktop/personal computing experience, rather than CFS's focus on big iron and tons of CPUs, so it's really appropriate to the Raspberry Pi, as well as potentially the XO. The only real advantage to forking the work is to bring support for it into the Squeak community. I doubt I'll have any more luck lobbying the kernel crowd to get it in as a secondary process scheduler than Con did, but maybe, just maybe, the Raspbian folks will see some value in making the Squeak VM go faster / possibly use less power (given that they're putting Scratch on the desktop by default) and be open to taking the patch. Especially if I can come with benchmarks that make it desirable across the board on the device (it sounds like it can probably bring the rain on that count if I'm reading this stuff right.) Whether or not I get warm feelings from the Raspbian folks, I'm going to look at "how can I make this patch as painless as possible to apply to as many distros as possible?" Of course if I actually do this, I can probably kiss my social life goodbye, so I'm not without reservations. Not to mention that the number of people who'll care is probably smaller than one might hope. I wondered what folks on vm-dev might think. If this is another one of my crazy projects that no one actually wants, please let me know posthaste :D P.S. If you're worried that I might not be qualified to maintain a kernel patch, I think this should help to assuage your fears: http://media.tumblr.com/tumblr_me0qrvGwDP1r3z80e.jpg And here's Con's rationale for implementing it. Warning: you might not want to pull this up while your parents are watching unless you've had a good long talk with them about what words are appropriate to use in various social contexts. Raising parents can be very challenging! And putting soap in their mouths only seems to upset them... http://ck.kolivas.org/patches/bfs/bfs-faq.txt -- Casey Ransberger

4 7

Building an Interpreter VM (4.10.2.2614) on OSX
by Frank Shearar 25 May '13

25 May '13

Are there special steps to take building an Interpreter VM on OS X? http://build.squeak.org/job/SqueakTrunk-OSX/222/console shows a build failing because Undefined symbols: "_sqMemoryBase", referenced from: _primitiveMPEG3Open in Mpeg3Plugin.c.o _primitiveMPEG3CheckSig in Mpeg3Plugin.c.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [Mpeg3Plugin/so.Mpeg3Plugin] Error 1 make[1]: *** [Mpeg3Plugin/CMakeFiles/Mpeg3Plugin.dir/all] Error 2 make: *** [all] Error 2 which kind've looks like the plugin actually compiled, but failed to link. frank

2 2

[unix][rpi] vm-display-wayland
by Bert Freudenberg 24 May '13

24 May '13

Anyone needs a little project? http://www.raspberrypi.org/archives/4053 - Bert -

3 2

Fwd: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure
by Max Leske 24 May '13

24 May '13

Begin forwarded message: > From: "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> > Subject: Re: [Pharo-fuel] [Pharo-dev] Corrupt BlockClosure > Date: 24. Mai 2013 08:10:19 MESZ > To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> > > Hi, > > Thanks all of you for interest ;) > > On May 24, 2013, at 7:15 AM, Max Leske <maxleske(a)gmail.com> > wrote: > >> I played around with reverting the method and serializing but that doesn't change anything (the existing BlockClosure is obviously not modified). >> Then I thought that maybe the method was changed during a running DFSession but still couldn't reproduce. > > Me neither!! > >> >> @Roberto >> Can you tell us anything about what you did befor / during / after running your session? > > Nope. Unfortunately I've a couple of "broken sessions" I cannot serialize because of that bug.. But all of them refers sooner or later to the DFSession>>#numberOfMethodCalls method. Dunno why. > >> @Roberto >> Is it possible to reproduce the stack with a new session? Or did this only happen once? > > I have no clue how to reproduce, but it did not happen only once. As I said, there are 3/4 sessions I couldn't export due to this SubscriptOutOfBounds. > > Cheers, > Roby > > >> >> >> On 24.05.2013, at 06:44, Max Leske <maxleske(a)gmail.com> wrote: >> >>> >>> On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: >>>> theBlock instVar: 2 put: 43. >>>> The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. >>> >>> Would it help to recompile the method? >>> >>>> I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? >>> >>> No, there was never a materialization of that session. >>> >>>> >>>> Camille >>>> >>>> On 23 mai 2013, at 21:02, Max Leske wrote: >>>> >>>>> Hi Marcus >>>>> >>>>> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >>>>> >>>>> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >>>>> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >>>>> >>>>> @Roberto >>>>> Is it possible to reproduce the stack with a new session? Or did this only happen once? >>>>> >>>>> >>>>> Cheers, >>>>> Max >>>>> >>>>> >>>>> Begin forwarded message: >>>>> >>>>>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>>>>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>>>>> Date: 23. Mai 2013 14:23:45 MESZ >>>>>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>>>>> >>>>>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>>>>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>>>>> Thanks! >>>>>> >>>>>> >>>>>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>>>>> What's the compiled method? Is it a special one? Which selector in which class? >>>>>> >>>>>> Max >>>>>> >>>>>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>>>>>> >>>>>>> I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>>>>>> >>>>>>> I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>>>>>> >>>>>>> Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Roby >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#1 ########################################### >>>>>>> ########################################################################################### >>>>>>> CompiledMethod(Object)>>errorSubscriptBounds: >>>>>>> CompiledMethod(Object)>>at: >>>>>>> InstructionStream>>interpretNextInstructionFor: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>>>>>> BlockClosure>>on:do: >>>>>>> CompiledMethod>>abstractBytecodeMessageAt: >>>>>>> BlockClosure>>blockCreationBytecodeMessage >>>>>>> BlockClosure>>endPC >>>>>>> BlockClosure>>abstractBytecodeMessagesDo: >>>>>>> BlockClosure>>isClean >>>>>>> BlockClosure>>shouldBeSubstitutedByCleanCopy >>>>>>> BlockClosure>>fuelAccept: >>>>>>> FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>>>>>> FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>>>>>> FLLargeIdentityDictionary>>at:ifAbsent: >>>>>>> FLFullGlobalMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLPluggableSubstitutionMapper>>mapAndTrace: >>>>>>> FLAnalysis>>mapAndTrace: >>>>>>> FLAnalysis>>run >>>>>>> FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>>>>>> FLAnalyzer>>analysisFor: >>>>>>> FLSerialization>>analysisStep >>>>>>> FLSerialization>>run >>>>>>> DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>>>>>> DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>>>>>> FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>>>>>> BlockClosure>>ensure: >>>>>>> FLEncoder class>>on:globalEnvironment:do: >>>>>>> DFSerializer(FLSerializer)>>serialize:on: >>>>>>> >>>>>>> >>>>>>> ############################################################################################ >>>>>>> ######################################### STACK#2 ########################################### >>>>>>> ############################################################################################ >>>>>>> Decompiler(Object)>>error: >>>>>>> Decompiler>>decompileBlock: >>>>>>> BlockClosure>>decompile >>>>>>> BlockClosure>>printOn: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>>>>>> String class(SequenceableCollection class)>>streamContents:limitedTo: >>>>>>> BlockClosure(Object)>>printStringLimitedTo: >>>>>>> BlockClosure(Object)>>printString >>>>>>> BlockClosure>>DoIt >>>>>>> Compiler>>evaluate:in:to:notifying:ifFail:logged: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>>>>>> BlockClosure>>on:do: >>>>>>> SmalltalkEditor>>evaluateSelectionAndDo: >>>>>>> SmalltalkEditor>>evaluateSelection >>>>>>> PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>>>>>> PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>>>>>> TextMorphForEditView(TextMorph)>>handleEdit: >>>>>>> PluggableTextMorph>>handleEdit: >>>>>>> PluggableTextMorph>>doIt >>>>>>> SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>>>>>> BlockClosure>>cull: >>>>>>> BlockClosure>>cull:cull: >>>>>>> BlockClosure>>cull:cull:cull: >>>>>>> KMCategoryTarget>>completeMatch:buffer: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>>>>>> Array(SequenceableCollection)>>do: >>>>>>> KMKeymap>>notifyCompleteMatchTo:buffer: >>>>>>> KMKeymap>>onMatchWith:notify:andDo: >>>>>>> KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>>>>>> Set>>do: >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Pharo-fuel mailing list >>>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Mariano >>>>>> http://marianopeck.wordpress.com >>>>>> _______________________________________________ >>>>>> Pharo-fuel mailing list >>>>>> Pharo-fuel(a)lists.gforge.inria.fr >>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>>>> >>>> >>> >> >> _______________________________________________ >> Pharo-fuel mailing list >> Pharo-fuel(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel > > > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel

1 0

Re: [Pharo-dev] Corrupt BlockClosure
by Max Leske 24 May '13

24 May '13

On 23.05.2013, at 22:58, Camille Teruel <camille.teruel(a)gmail.com> wrote: > Hi, > > This is indeed strange, the BlockClosure has an incorrect startpc (31 instead of 43). You can fix it with: > theBlock instVar: 2 put: 43. > The wrong startpc corresponds to the beginning of the block in the previous version of the method (DFSession>>#numberOfMethodCalls), but I don't know why. Would it help to recompile the method? > I don't know fuel enough but could it be because the method of the block changed between serialization and materialization? No, there was never a materialization of that session. > > Camille > > On 23 mai 2013, at 21:02, Max Leske wrote: > >> Hi Marcus >> >> Roberto sent this mail to the Fuel-dev list. When we looked at the problem we noticed that serialization fails because of a corrupt BlockClosure. Since that's not really our territorry Mariano suggested to forward this to you. >> >> The image with the corrupt BlockClosure is available here: https://dl.dropboxusercontent.com/u/6281855/DFlow-SubscriptOutOfBounds.zip. >> To see the stack, right click on the only entry in the right window and click "export session". You'll find the corrupt BlockClosure at BlockClosure>>fuelAccept: >> >> @Roberto >> Is it possible to reproduce the stack with a new session? Or did this only happen once? >> >> >> Cheers, >> Max >> >> >> Begin forwarded message: >> >>> From: Mariano Martinez Peck <marianopeck(a)gmail.com> >>> Subject: Re: [Pharo-fuel] [Fuel] SubscriptOutOfBounds: 27 >>> Date: 23. Mai 2013 14:23:45 MESZ >>> To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>> Reply-To: The Fuel Project <pharo-fuel(a)lists.gforge.inria.fr> >>> >>> Indeed, it would be nice if you can known which CompiledMethod and blockclosure are having the problem. Not only the source code but the real bytecodes. >>> Also, can you isolate and just try to serialize them alone and reproduce the problem? In other words, a reproducible test case? :) >>> Thanks! >>> >>> >>> On Thu, May 23, 2013 at 8:41 AM, Max Leske <maxleske(a)gmail.com> wrote: >>> What's the compiled method? Is it a special one? Which selector in which class? >>> >>> Max >>> >>> On 23.05.2013, at 12:45, "roberto.minelli(a)usi.ch" <roberto.minelli(a)usi.ch> wrote: >>> >>> > Hi, >>> > >>> > While using Fuel in a 2.0 image to serialize some objects (including CompiledMethods) I'm getting this error: SubscriptOutOfBounds: 27. >>> > >>> > I spent hours in the debugger before writing this email, but I'm not able to figure out why this is happening. I attach the full stack of the error (STACK#1). >>> > >>> > I understood that it has something to do with a particular CompiledMethod in my image and/or a BlockClosure which for some reason cannot be printed (i.e., the printString returns <error in printString: evaluate "self printString" to debug>) and when I try to printString to debug I got the STACK#2 which in turn does not bring me to any possible solution. >>> > >>> > Hope some of you will have an intuition on that or at least tell me where to look or how to script a possible workaround. >>> > >>> > Thanks in advance, >>> > Roby >>> > >>> > ############################################################################################ >>> > ######################################### STACK#1 ########################################### >>> > ########################################################################################### >>> > CompiledMethod(Object)>>errorSubscriptBounds: >>> > CompiledMethod(Object)>>at: >>> > InstructionStream>>interpretNextInstructionFor: >>> > CompiledMethod>>abstractBytecodeMessageAt: in Block: [(InstructionStream new method: self pc: pc)... >>> > BlockClosure>>on:do: >>> > CompiledMethod>>abstractBytecodeMessageAt: >>> > BlockClosure>>blockCreationBytecodeMessage >>> > BlockClosure>>endPC >>> > BlockClosure>>abstractBytecodeMessagesDo: >>> > BlockClosure>>isClean >>> > BlockClosure>>shouldBeSubstitutedByCleanCopy >>> > BlockClosure>>fuelAccept: >>> > FLFullGeneralMapper(FLLightGeneralMapper)>>mapAndTrace: >>> > FLFullGlobalMapper>>mapAndTrace: in Block: [(anObject class == CompiledMethod... >>> > FLLargeIdentityDictionary>>at:ifAbsent: >>> > FLFullGlobalMapper>>mapAndTrace: >>> > FLPluggableSubstitutionMapper>>mapAndTrace: >>> > FLPluggableSubstitutionMapper>>mapAndTrace: >>> > FLAnalysis>>mapAndTrace: >>> > FLAnalysis>>run >>> > FLAnalyzer>>setDefaultAnalysis in Block: [:anObject | (FLAnalysis... >>> > FLAnalyzer>>analysisFor: >>> > FLSerialization>>analysisStep >>> > FLSerialization>>run >>> > DFSerializer(FLSerializer)>>setDefaultSerialization in Block: [:anObject :anEncoder | (FLSerialization... >>> > DFSerializer(FLSerializer)>>serialize:on: in Block: [:anEncoder | ... >>> > FLEncoder class>>on:globalEnvironment:do: in Block: [aBlock value: anEncoder] >>> > BlockClosure>>ensure: >>> > FLEncoder class>>on:globalEnvironment:do: >>> > DFSerializer(FLSerializer)>>serialize:on: >>> > >>> > >>> > ############################################################################################ >>> > ######################################### STACK#2 ########################################### >>> > ############################################################################################ >>> > Decompiler(Object)>>error: >>> > Decompiler>>decompileBlock: >>> > BlockClosure>>decompile >>> > BlockClosure>>printOn: >>> > BlockClosure(Object)>>printStringLimitedTo: in Block: [:s | self printOn: s] >>> > String class(SequenceableCollection class)>>streamContents:limitedTo: >>> > BlockClosure(Object)>>printStringLimitedTo: >>> > BlockClosure(Object)>>printString >>> > BlockClosure>>DoIt >>> > Compiler>>evaluate:in:to:notifying:ifFail:logged: >>> > SmalltalkEditor>>evaluateSelectionAndDo: in Block: [rcvr class evaluatorClass new... >>> > BlockClosure>>on:do: >>> > SmalltalkEditor>>evaluateSelectionAndDo: >>> > SmalltalkEditor>>evaluateSelection >>> > PluggableTextMorph>>doIt in Block: [textMorph editor evaluateSelection] >>> > PluggableTextMorph>>handleEdit: in Block: [result := editBlock value] >>> > TextMorphForEditView(TextMorph)>>handleEdit: >>> > PluggableTextMorph>>handleEdit: >>> > PluggableTextMorph>>doIt >>> > SmalltalkEditor class>>buildSmalltalkEditorKeymappingsOn: in Block: [:morph | morph doIt] >>> > BlockClosure>>cull: >>> > BlockClosure>>cull:cull: >>> > BlockClosure>>cull:cull:cull: >>> > KMCategoryTarget>>completeMatch:buffer: >>> > KMKeymap>>notifyCompleteMatchTo:buffer: in Block: [:l | l completeMatch: self buffer: aBuffer] >>> > Array(SequenceableCollection)>>do: >>> > KMKeymap>>notifyCompleteMatchTo:buffer: >>> > KMKeymap>>onMatchWith:notify:andDo: >>> > KMCategory>>onMatchWith:notify:andDo: in Block: [:entry | entry... >>> > Set>>do: >>> > >>> > >>> > >>> > _______________________________________________ >>> > Pharo-fuel mailing list >>> > Pharo-fuel(a)lists.gforge.inria.fr >>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >>> >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> _______________________________________________ >>> Pharo-fuel mailing list >>> Pharo-fuel(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel >> >

1 1

← Newer
1
2
3
4
5
6
7
8
...
15
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev May 2013