Vm-dev June 2016

vm-dev@lists.squeakfoundation.org

50 participants
129 discussions

Re: [Pharo-dev] pharo 5 segfault (stack size?) [FreeBSD]
by Ben Coman 27 Jun '16

27 Jun '16

On Sun, Jun 26, 2016 at 8:37 PM, Petr Fischer <petr.fischer(a)me.com> wrote: > Yes there is "PharoVMBuilder buildFreeBSD", but some "cog*" errors occurs... So I am still building with "PharoVMSpur32Builder buildUnix32" under Linux (CentOS6) and then move compiled vm to my FreeBSD box with Linux compatibility layer. > > I compiled DEBUG vm version according to your advice and this is gdb output: > > Program received signal SIGSEGV, Segmentation fault. > 0x080aefc1 in scavengeReferentsOf (referrer=684415032) at /home/pf/pharo/pharo-vm-debug/src/vm/gcc3x-cointerp.c:39014 > 39014 if (((longAt(referent)) & ((classIndexMask()) - (isForwardedObjectClassIndexPun()))) == 0) { The C files are generated from VMMaker and the line numbers change a lot. If you look upwards in the C file you should see a generated comment that links to the Smalltalk source it was generated from. > > I need to learn a little, how to play this "core C" game in gdb... > What next? I recently learnt a bit of using gdb on the image. I'm planning to write up something but its a few weeks off. The old post How to debug the VM? [1] by Mariano needs a bit of adaption, but got me off to a good start. If you look in VMMaker package where #printAllStacks is defined you'll see some others you can call, that just print the current Smalltalk call stack. [1] https://marianopeck.wordpress.com/2011/04/23/how-to-debug-the-vm/ > > A also compiled PharoS (Pharo Stack) VM, and it's 5x slower, but stable, there is no stack errors (or other crashes) like in cog spur vm. You might also try compiling the VM from upstream sources[2], running either: * vm/build.linux32x86/squeak.cog.spur/build.debug/mvm * vm/build.linux64x64/squeak.cog.spur/build.debug/mvm Did you try the early 64-bit Pharo Image [3] suggested by Esteban in another thread ? Also, you might try Squeak 64-bit Image, since its the platform Eliot develops the VM on, so it is further advanced in 64-bit stability. Run vm/image/buildspurtrunk64image.sh. [2] https://github.com/OpenSmalltalk/vm [3] http://files.pharo.org/get-files/60/pharo-64.zip Now since you are getting down and dirty debugging this at VM level, probably good to shift this thread to [vm-dev]. http://lists.squeakfoundation.org/mailman/listinfo/vm-dev cheers -ben > > pf > > >> You could build a debug VM from here >> https://github.com/pharo-project/pharo-vm >> I also glimpsed some FreeBSD build options there you might try. >> cheers -ben >> >> On Fri, Jun 24, 2016 at 12:05 PM, Petr Fischer <petr.fischer(a)me.com> wrote: >> >> > So... I compiled latest sources (blessed) on CentOS 6.8, fine, moved >> > compiled binaries to FreeBSD and tried to load Seaside to the latest 50760 >> > image. >> > Still stack errors, log here: http://pastebin.com/raw/bf1EpWNt >> > >> > When I run this on CentOS, everything is fine (loading Seaside, no stack >> > errors), but when I run the same on FreeBSD, stack errors (segfaults) >> > occurs. >> > >> > So... There is something bad on FreeBSD side? Can I debug more? >> > >> > pf >> > >> > >> > > Try 50760 from... >> > > http://files.pharo.org/image/50/ >> > > >> > > cheers -ben >> > > >> > > On Sat, Jun 18, 2016 at 12:49 AM, Petr Fischer <petr.fischer(a)me.com> >> > wrote: >> > > > VM version (from >> > https://swing.fit.cvut.cz/jenkins/job/pharo-vm-spur-swing/): >> > > > >> > > > 5.0 #1 Sun Jan 17 14:19:14 CET 2016 gcc 4.7.2 [Production Spur ITHB VM] >> > > > CoInterpreter VMMaker.oscog-eem.1630 uuid: >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 >> > > > StackToRegisterMappingCogit VMMaker.oscog-eem.1630 uuid: >> > 2ed025ea-f400-4440-8e8b-5aa46d06c9ab Jan 17 2016 >> > > > https://github.com/estebanlm/pharo-vm.git Commit: >> > 21ec004cce7d26010c18d357c805a0e1a4ffe376 Date: 2016-01-14 11:42:33 +0100 >> > By: Esteban Lorenzano <estebanlm(a)gmail.com> Jenkins build #498 >> > > > Linux swing-hudson-lin64 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u2 >> > x86_64 GNU/Linux >> > > > plugin path: /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin [default: >> > /usr/home/pf/Work/Smalltalk/pharo5.0.centos/bin/] >> > > > >> > > > Image version (from official 5.0 download): >> > > > >> > > > [version] 5.0 #50723 >> > > > >> > > > pf >> > > > >> > > >> in fact, this is not related to FFI… but it should be fixed… >> > > >> >> > > >> along with the VM version, which version of Pharo are you using? >> > > >> >> > > >> Esteban >> > > >> >> > > >> > On 17 Jun 2016, at 14:04, Max Leske <maxleske(a)gmail.com> wrote: >> > > >> > >> > > >> > Hi Petr, >> > > >> > >> > > >> > That looks like a bug with FreeType with our FFI. It should >> > actually have been fixed but I don’t know if the VM for FreeBSD is up to >> > date. Can you post the output of “Smalltalk vm version”? >> > > >> > >> > > >> > Cheers, >> > > >> > Max >> > > >> > >> > > >> >> On 17 Jun 2016, at 13:26, Petr Fischer <petr.fischer(a)me.com> >> > wrote: >> > > >> >> >> > > >> >> Hello, I got some random segfaults (while loading Seaside) with 32 >> > bit spur vm on FreeBSD - can someone (with low level knowledge) decode >> > attached log? >> > > >> >> Is this some problem with stack size? Can I fix this? >> > > >> >> >> > > >> >> Log: >> > > >> >> http://pastebin.com/raw/NpFUnjh0 >> > > >> >> >> > > >> >> There is "**StackOverflow**" lines n the log...

2 3

VM Maker: VMMaker.oscog-eem.1890.mcz
by commits＠source.squeak.org 27 Jun '16

27 Jun '16

Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://source.squeak.org/VMMaker/VMMaker.oscog-eem.1890.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.1890 Author: eem Time: 26 June 2016, 6:03:06.041002 pm UUID: 63b22b9f-29ab-46d5-b533-05c17aa78dc6 Ancestors: VMMaker.oscog-eem.1889 Fix regression in Sista introsduced in VMMaker.oscog-eem.1877. The Sista scanMethod: should set useTwoPaths only for methods that would be frameless were it not for a store (which needs a frame if immutable). The regression was to set useTwoPaths in frameful methods containing a store; a stupid slip by your's truly. In 1890 Dutch artist Vincent van Gogh moves to Auvers-sur-Oise on the edge of Paris in the care of Dr Paul Gachet where he will produce around seventy paintings in as many days, and commit suicide soon thereafter, the Picture of Dorian Gray by Oscar Wilde is published by Philadelphia-based Lippincott's Monthly Magazine, and the United States Census Bureau begins using Herman Hollerith's tabulating machine to tabulate census returns using punched card input, a landmark in the history of computing hardware. Hollerith's company eventually becomes IBM. =============== Diff against VMMaker.oscog-eem.1889 =============== Item was changed: ----- Method: StackToRegisterMappingCogit>>scanMethod (in category 'compile abstract instructions') ----- scanMethod "Scan the method (and all embedded blocks) to determine - what the last bytecode is; extra bytes at the end of a method are used to encode things like source pointers or temp names - if the method needs a frame or not - what are the targets of any backward branches. - how many blocks it creates Answer the block count or on error a negative error code" | latestContinuation nExts descriptor pc numBlocks distance targetPC framelessStackDelta seenInstVarStore | <var: #descriptor type: #'BytecodeDescriptor *'> needsFrame := useTwoPaths := seenInstVarStore := false. self maybeInitNumFixups. self maybeInitNumCounters. prevBCDescriptor := nil. NewspeakVM ifTrue: [numIRCs := 0]. (primitiveIndex > 0 and: [coInterpreter isQuickPrimitiveIndex: primitiveIndex]) ifTrue: [^0]. pc := latestContinuation := initialPC. numBlocks := framelessStackDelta := nExts := extA := extB := 0. [pc <= endPC] whileTrue: [byte0 := (objectMemory fetchByte: pc ofObject: methodObj) + bytecodeSetOffset. descriptor := self generatorAt: byte0. descriptor isExtension ifTrue: [descriptor opcode = Nop ifTrue: "unknown bytecode tag; see Cogit class>>#generatorTableFrom:" [^EncounteredUnknownBytecode]. self loadSubsequentBytesForDescriptor: descriptor at: pc. self perform: descriptor generator]. (descriptor isReturn and: [pc >= latestContinuation]) ifTrue: [endPC := pc]. needsFrame ifFalse: [(descriptor needsFrameFunction isNil or: [self perform: descriptor needsFrameFunction with: framelessStackDelta]) ifTrue: + [needsFrame := true] - [needsFrame := true. - self cppIf: IMMUTABILITY - ifTrue: [useTwoPaths := descriptor isInstVarStore]] ifFalse: [framelessStackDelta := framelessStackDelta + descriptor stackDelta. + "With immutability we win simply by avoiding a frame build if the receiver is not immutable. + Without immutability we win if there are two or more stores amd the receiver is new." self cppIf: IMMUTABILITY + ifTrue: [useTwoPaths := descriptor isInstVarStore] - ifTrue: [] ifFalse: [descriptor isInstVarStore ifTrue: [seenInstVarStore ifTrue: [useTwoPaths := true] ifFalse: [seenInstVarStore := true]]]]]. descriptor isBranch ifTrue: [distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. targetPC := pc + descriptor numBytes + distance. (self isBackwardBranch: descriptor at: pc exts: nExts in: methodObj) ifTrue: [self initializeFixupAt: targetPC - initialPC] ifFalse: [latestContinuation := latestContinuation max: targetPC. self maybeCountFixup. self maybeCountCounter]]. descriptor isBlockCreation ifTrue: [numBlocks := numBlocks + 1. distance := self spanFor: descriptor at: pc exts: nExts in: methodObj. targetPC := pc + descriptor numBytes + distance. latestContinuation := latestContinuation max: targetPC. self maybeCountFixup]. NewspeakVM ifTrue: [descriptor hasIRC ifTrue: [numIRCs := numIRCs + 1]]. pc := pc + descriptor numBytes. descriptor isExtension ifTrue: [nExts := nExts + 1] ifFalse: [nExts := extA := extB := 0]. prevBCDescriptor := descriptor]. ^numBlocks!

1 0

Pharo 5.0 Fedora 24 crash solved
by Casimiro - GMAIL 25 Jun '16

25 Jun '16

Solved, the "Microsoft way": reinstalled all stuff (system), reloaded libraries and all, and voilà: Pharo is OK. Thanks to everybody who watched over the problem. Will try to reproduce in other environment to understand what was wrong. CdAB63 -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417*

1 0

SSLPlugin
by Eliot Miranda 25 Jun '16

25 Jun '16

Hi All, now that we're on github would those who build the SSLPlugin be willing to fold in their build to the standard VM builds so that SSLPlugin is built alongside the others? _,,,^..^,,,_ best, Eliot

3 4

Cog spur VMs crashing in new Fedora 24
by Casimiro - GMAIL 24 Jun '16

24 Jun '16

VMs are crashing. In the case of Pharo 5.0 VM does that SIGSEGV thing. Trace is: Pharo 5 crashes. VM does a SIGSEGV 0x00000000 at start Running GDB I got: (gdb) run Starting program: /home/CdAB63/Downloads/pharo5.0/bin/pharo Missing separate debuginfos, use: dnf debuginfo-install glibc-2.23.1-8.fc24.i686 [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00000000 in ?? () (gdb) backtrace full #0 0x00000000 in ?? () No symbol table info available. #1 0xf7f3dd7e in __pthread_once_slow () from /lib/libpthread.so.0 No symbol table info available. #2 0xf7aa9c05 in ?? () from /lib/libGL.so.1 No symbol table info available. #3 0xf7a722ab in ?? () from /lib/libGL.so.1 No symbol table info available. #4 0xf7fe8da1 in call_init.part () from /lib/ld-linux.so.2 No symbol table info available. #5 0xf7fe8f00 in _dl_init () from /lib/ld-linux.so.2 No symbol table info available. #6 0xf7fed80f in dl_open_worker () from /lib/ld-linux.so.2 No symbol table info available. #7 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 No symbol table info available. #8 0xf7fecd89 in _dl_open () from /lib/ld-linux.so.2 No symbol table info available. #9 0xf7f4dc05 in dlopen_doit () from /lib/libdl.so.2 No symbol table info available. #10 0xf7fe8c91 in _dl_catch_error () from /lib/ld-linux.so.2 No symbol table info available. #11 0xf7f4e35d in _dlerror_run () from /lib/libdl.so.2 No symbol table info available. #12 0xf7f4dcae in dlopen@@GLIBC_2.1 () from /lib/libdl.so.2 No symbol table info available. #13 0x080bd60f in tryLoading () No symbol table info available. #14 0x080bd751 in ioLoadModule () No symbol table info available. #15 0x080bf18b in queryLoadModule () No symbol table info available. #16 0x080bf27f in queryModule () No symbol table info available. #17 0x080bf2c7 in loadImplicit () No symbol table info available. #18 0x0805ccd7 in main () No symbol table info available. (gdb) Would be helpful if VM was compiled in debug mode so it would possible to understand better what's happening. -- The information contained in this message is confidential and intended to the recipients specified in the headers. If you received this message by error, notify the sender immediately. The unauthorized use, disclosure, copy or alteration of this message are strictly forbidden and subjected to civil and criminal sanctions. == This email may be signed using PGP key *ID: 0x4134A417*

4 9

Can't infer base LD_LIBRARY_PATH
by Ben Coman 24 Jun '16

24 Jun '16

On Sat, May 21, 2016 at 4:44 AM, Clément Bera <bera.clement(a)gmail.com> wrote: > > On Fri, May 20, 2016 at 7:29 PM, Ben Coman <btc(a)openinworld.com> wrote: >> >> I've decided to try and get the simulator working for the first >> time this weekend. Its been interesting poking through the VM with >> gdb, but its not "exactly" fun. > > > Normally if you build a cog development image: > $ svn co http://www.squeakvm.org/svn/squeak/branches/Cog/image > $ cd ./image > $ ./buildsqueaktrunkvmmakerimage.sh I'm sure I've built successfully from there before, but right now I'm getting and error.. cogspurlinuxht/squeak trunk50.image UpdateSqueakTrunkImage.st Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 to cogspurlinuxht/squeak. Please report your edit to squeak vm-dev. cogspurlinuxht/squeak SpurVMMaker.image BuildSqueakSpurTrunkVMMakerImage.st Can't infer base LD_LIBRARY_PATH. Aborting. Try adding a line for /lib/i386-linux-gnu/i686/nosegneg/libc.so.6 to cogspurlinuxht/squeak. Please report your edit to squeak vm-dev. I'm in the process of tracking that down, but just reporting in case there is a known quick fix. btw, I'm on Debian Jessie Linux dom0 3.16.0-4-686-pae #1 SMP Debian 3.16.7-ckt20-1+deb8u3 (2016-01-17) i686 GNU/Linux cheers -ben > > You have multiple scripts available with comments to run the simulator that work out of the box. It should take a couple minutes to get it working. Then the easiest is to simulate a REPL image to easily debug what you want.

4 6

Mac OS X autorelease crash
by Eliot Miranda 23 Jun '16

23 Jun '16

Hi, here's another Process: Squeak [96917] Path: /Users/USER/*/CocoaFast.app/Contents/MacOS/Squeak Identifier: org.squeak.Squeak$(VM_MONIKER) Version: 5.0.201606202053 (5.0.201606202053) Code Type: X86 (Native) Parent Process: launchd [186] Responsible: Squeak [96917] User ID: 594 Date/Time: 2016-06-23 11:39:36.916 -0700 OS Version: Mac OS X 10.9.5 (13F1808) Report Version: 11 Anonymous UUID: F54BABC9-4764-81AE-0375-EA1A9A4A38C2 Sleep/Wake UUID: 02B5D29D-A0A9-414F-93DC-4EA822100B81 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Exception Type: EXC_BAD_ACCESS (SIGBUS) Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000000000000 VM Regions Near 0: --> __PAGEZERO 0000000000000000-0000000000001000 [ 4K] ---/--- SM=NUL /Users/USER/*/CocoaFast.app/Contents/MacOS/Squeak VM_ALLOCATE 0000000000001000-000000000006e000 [ 436K] ---/--- SM=NUL Thread 0 crashed with X86 Thread State (32-bit): eax: 0x00000000 ebx: 0x00000000 ecx: 0x00000000 edx: 0x00206300 edi: 0xcc001000 esi: 0x98f848f2 ebp: 0xbfeef1c8 esp: 0xbfeef190 ss: 0x00000023 efl: 0x00010282 eip: 0x98f84a80 cs: 0x0000001b ds: 0x00000023 es: 0x00000023 fs: 0x00000000 gs: 0x0000000f cr2: 0x00000000 Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x98f84a80 (anonymous namespace)::AutoreleasePoolPage::autoreleaseSlow(objc_object*) + 412 1 libobjc.A.dylib 0x98f96799 _objc_rootAutorelease2(objc_object*) + 72 2 com.apple.CoreFoundation 0x9822bf2d +[NSArray arrayWithObjects:] + 413 3 com.apple.Foundation 0x91bfdbd4 +[NSFileAttributes _populateCatInfo:forURL:statInfo:error:] + 89 4 com.apple.Foundation 0x91bfda2c +[NSFileAttributes _attributesAtPath:partialReturn:filterResourceFork:error:] + 374 5 com.apple.Foundation 0x91bfd8ad -[NSFileManager attributesOfItemAtPath:error:] + 66 6 org.squeak.Squeak$(VM_MONIKER) 0x000e3d26 -[sqSqueakFileDirectoryInterface attributesForPath:fileMgr:isDirectory:creationDate:modificationDate:sizeIfFile:posixPermissions:isSymlink:] + 63 (sqSqueakFileDirectoryInterface.m:92) 7 org.squeak.Squeak$(VM_MONIKER) 0x000e43f0 -[sqSqueakFileDirectoryInterface dir_Lookup:length:index:name:length:creationDate:modificationDate:isDirectory:sizeIfFile:posixPermissions:isSymlink:] + 840 (sqSqueakFileDirectoryInterface.m:246) 8 org.squeak.Squeak$(VM_MONIKER) 0x000e388e dir_Lookup + 156 (sqSqueakFileDirectoryAPI.m:108) 9 org.squeak.Squeak$(VM_MONIKER) 0x00101669 primitiveDirectoryLookup + 257 10 ??? 0x04935ce8 0 + 76766440 11 org.squeak.Squeak$(VM_MONIKER) 0x0006fa5a interpret + 741 (gcc3x-cointerp.c:2547) 12 org.squeak.Squeak$(VM_MONIKER) 0x000e62ac -[sqSqueakMainApplication runSqueak] + 476 (sqSqueakMainApplication.m:200) 13 com.apple.Foundation 0x91c5af70 __NSFirePerformWithOrder + 419 14 com.apple.CoreFoundation 0x9822a2be __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 30 15 com.apple.CoreFoundation 0x9822a20f __CFRunLoopDoObservers + 399 16 com.apple.CoreFoundation 0x9821b02e __CFRunLoopRun + 974 17 com.apple.CoreFoundation 0x9821a9ea CFRunLoopRunSpecific + 394 18 com.apple.CoreFoundation 0x9821a84b CFRunLoopRunInMode + 123 19 com.apple.HIToolbox 0x95b21b5d RunCurrentEventLoopInMode + 259 20 com.apple.HIToolbox 0x95b21777 ReceiveNextEventCommon + 163 21 com.apple.HIToolbox 0x95b216bd _BlockUntilNextEventMatchingListInModeWithFilter + 92 22 com.apple.AppKit 0x961f7349 _DPSNextEvent + 1602 23 com.apple.AppKit 0x961f6870 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] + 119 24 com.apple.AppKit 0x961e915c -[NSApplication run] + 727 25 com.apple.AppKit 0x961d1ff8 NSApplicationMain + 1165 26 libdyld.dylib 0x9aacb701 start + 1 _,,,^..^,,,_ best, Eliot

1 0

[Spur] endless recursion in forward become
by Bert Freudenberg 23 Jun '16

23 Jun '16

I'm reading a 20MB text file. At some point it tries to convert the 20 MB ByteString into an 80 MB WideString using forward become. This fails resulting in an endless loop. The primitive failure code for elementsForwardIdentityTo: (primitive 72) is #'insufficient object memory' and it tries again after growing: ec == #'insufficient object memory' ifTrue: [Smalltalk garbageCollect < 1048576 ifTrue: [Smalltalk growMemoryByAtLeast: 1048576]. ^self elementsForwardIdentityTo: otherArray]. but the growMemoryByAtLeast: does not actually grow the memory: {Smalltalk garbageCollect. Smalltalk growMemoryByAtLeast: 1048576. Smalltalk garbageCollect.} ==> #(58576608 16777216 58576608) 58 MB are not enough, but it doesn't grow any further. The question is, why does it try to allocate a new object at all? The WideString exists already. I thought Spur would simply install a forwarder? To reproduce, execute (ByteString new: 20000000) writeStream nextPut: (Character value: 128169) You probably want to follow that with a user interrupt (Cmd-period). This happens using the latest Spur VM from github (r201606160944) - Bert -

4 12

The code in the src folders in the repository
by Laura Perez Cerrato 23 Jun '16

23 Jun '16

Hi everyone, Excuse me if this has been asked already or it's documented somewhere and I missed it, but what's the criteria to update the code in /src, /stacksrc, /spursrc and other similar folders in the repository? -Laura Perez Cerrato

9 17

condense .gitignore for build dirs
by Ben Coman 22 Jun '16

22 Jun '16

Looking at .gitignore I found the 311 entries for /build.* a bit overwhelming trying to understand what actually was ignored. I manage to condense that down to 55 general rules. I've detailed some analysis, implementation and testing in the pull request. https://github.com/OpenSmalltalk/vm/pull/13 cheers -ben

2 2

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev June 2016