June 2015 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Monticello / OS deadlock ?

by Thierry Goubier

2015-06-02 12:14 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > Hi Thierry, > > ConfigurationOfOSProcess-ThierryGoubier.38.mcz, which corresponds to > version 4.6.2. > Ok, then this is the latest. > > Another workaround that would work for me is to be able to "resume" a > previous load attempt of a Metacello project. Or a custom "hook" in > Metacello to save the image after every dependency is successfully loaded. > Yes, this would work. I'll ask again Dave if he has any idea; the bug is hard to reproduce. Would you mind telling the linux kernel / libc version of your gentoo box? Thierry > > > 2015-06-02 11:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> Hi Jose, >> >> yes, I've noticed that as well. It was, at a point, drastic (i.e. almost >> allways lock-up) on my work development laptop; it now happens far less >> often (but it does happens to me from time to time). >> >> Dave Lewis, the author of OSProcess, fixed one issue which solved most of >> the lockups I had, but not all of them. The lockup is in the interaction >> between OSProcess inside Pharo and the external shell command (i.e. it >> concerns anything which uses OSProcess), and seems like missing a signal. >> It is also machine and linux version dependent (Ubuntu 14.10 was horrible, >> 14.04 and 15.04 on the same hardware are far less sensitive), and seems to >> also depend on the load of the machine itself. >> >> By the way, which version of OSProcess you are using? >> >> Thierry >> >> >> 2015-06-02 11:10 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: >> >>> Hi, >>> >>> In one of our projects we are using Pharo4. The image gets built by >>> gradle, which loads the Metacello project. Sometimes, we see the build >>> process hangs. It just don't progress. >>> >>> When adding local gitfiletree:// dependencies manually through >>> Monticello after a while Pharo gets frozen. It's not always the same >>> repository, it's not always the same number of repositories before it hangs. >>> >>> I launched the image with strace, and attached gdb to the frozen process. >>> It turns out It's waiting for a lock that gets never released. >>> >>> The environment is a 64b Gentoo Linux with enough of everything >>> (multiple monitors, multiple cores, enough RAM). >>> >>> I hope anybody could point me how to dig deeper into this. >>> >>> # gdb >>> (gdb) attach [pid] >>> [..] >>> Reading symbols from /usr/lib32/libbz2.so.1...(no debugging symbols >>> found)...done. >>> Loaded symbols for /usr/lib32/libbz2.so.1 >>> 0x0809d8bb in signalSemaphoreWithIndex () >>> (gdb) backtrace >>> #0 0x0809d8bb in signalSemaphoreWithIndex () >>> #1 0x0810868c in handleSignal () >>> #2 <signal handler called> >>> #3 0x0809d8c8 in signalSemaphoreWithIndex () >>> #4 0x0809f0af in aioPoll () >>> #5 0xf76f9671 in display_ioRelinquishProcessorForMicroseconds () from >>> /home/chous/realhome/toolbox/pharo-5.0/pharo-vm/vm-display-X11 >>> #6 0x080a1887 in ioRelinquishProcessorForMicroseconds () >>> #7 0x080767fa in primitiveRelinquishProcessor () >>> #8 0xb6fc838c in ?? () >>> #9 0xb6fc3700 in ?? () >>> #10 0xb7952882 in ?? () >>> #11 0xb6fc3648 in ?? () >>> (gdb) disassemble >>> Dump of assembler code for function handleSignal: >>> 0x081085e0 <+0>: sub $0x9c,%esp >>> 0x081085e6 <+6>: mov %ebx,0x90(%esp) >>> 0x081085ed <+13>: mov 0xa0(%esp),%ebx >>> 0x081085f4 <+20>: mov %esi,0x94(%esp) >>> 0x081085fb <+27>: mov %edi,0x98(%esp) >>> 0x08108602 <+34>: movzbl 0x8168420(%ebx),%esi >>> 0x08108609 <+41>: mov %ebx,%eax >>> 0x0810860b <+43>: mov %esi,%edx >>> 0x0810860d <+45>: call 0x81070d0 <forwardSignaltoSemaphoreAt> >>> 0x08108612 <+50>: call 0x805aae0 <pthread_self@plt> >>> 0x08108617 <+55>: mov 0x8168598,%edi >>> 0x0810861d <+61>: cmp %edi,%eax >>> 0x0810861f <+63>: je 0x8108680 <handleSignal+160> >>> 0x08108621 <+65>: lea 0x10(%esp),%esi >>> 0x08108625 <+69>: mov %esi,(%esp) >>> 0x08108628 <+72>: call 0x805b330 <sigemptyset@plt> >>> 0x0810862d <+77>: mov %ebx,0x4(%esp) >>> 0x08108631 <+81>: mov %esi,(%esp) >>> 0x08108634 <+84>: call 0x805b0c0 <sigaddset@plt> >>> 0x08108639 <+89>: movl $0x0,0x8(%esp) >>> 0x08108641 <+97>: mov %esi,0x4(%esp) >>> 0x08108645 <+101>: movl $0x0,(%esp) >>> 0x0810864c <+108>: call 0x805ada0 <pthread_sigmask@plt> >>> 0x08108651 <+113>: mov %ebx,0x4(%esp) >>> 0x08108655 <+117>: mov %edi,(%esp) >>> 0x08108658 <+120>: call 0x805b240 <pthread_kill@plt> >>> 0x0810865d <+125>: mov 0x90(%esp),%ebx >>> 0x08108664 <+132>: mov 0x94(%esp),%esi >>> 0x0810866b <+139>: mov 0x98(%esp),%edi >>> 0x08108672 <+146>: add $0x9c,%esp >>> 0x08108678 <+152>: ret >>> 0x08108679 <+153>: lea 0x0(%esi,%eiz,1),%esi >>> 0x08108680 <+160>: test %esi,%esi >>> 0x08108682 <+162>: je 0x810865d <handleSignal+125> >>> 0x08108684 <+164>: mov %esi,(%esp) >>> 0x08108687 <+167>: call 0x809d8a0 <signalSemaphoreWithIndex> >>> => 0x0810868c <+172>: jmp 0x810865d <handleSignal+125> >>> End of assembler dump. >>> (gdb) up 3 >>> (gdb) disassemble >>> Dump of assembler code for function signalSemaphoreWithIndex: >>> 0x0809d8a0 <+0>: push %esi >>> 0x0809d8a1 <+1>: xor %eax,%eax >>> 0x0809d8a3 <+3>: push %ebx >>> 0x0809d8a4 <+4>: sub $0x24,%esp >>> 0x0809d8a7 <+7>: mov 0x30(%esp),%esi >>> 0x0809d8ab <+11>: test %esi,%esi >>> 0x0809d8ad <+13>: jle 0x809d918 <signalSemaphoreWithIndex+120> >>> 0x0809d8af <+15>: mov $0x1,%edx >>> 0x0809d8b4 <+20>: lea 0x0(%esi,%eiz,1),%esi >>> 0x0809d8b8 <+24>: mfence >>> 0x0809d8bb <+27>: mov $0x0,%eax >>> 0x0809d8c0 <+32>: lock cmpxchg %edx,0x8152d80 >>> => 0x0809d8c8 <+40>: mov %eax,0x1c(%esp) >>> 0x0809d8cc <+44>: mov 0x1c(%esp),%eax >>> 0x0809d8d0 <+48>: test %eax,%eax >>> 0x0809d8d2 <+50>: jne 0x809d8b8 <signalSemaphoreWithIndex+24> >>> 0x0809d8d4 <+52>: mov 0x8152d84,%edx >>> 0x0809d8da <+58>: cmp $0x1ff,%edx >>> 0x0809d8e0 <+64>: lea 0x1(%edx),%ebx >>> 0x0809d8e3 <+67>: cmove %eax,%ebx >>> 0x0809d8e6 <+70>: mov 0x8152d88,%eax >>> 0x0809d8eb <+75>: cmp %ebx,%eax >>> 0x0809d8ed <+77>: je 0x809d920 <signalSemaphoreWithIndex+128> >>> 0x0809d8ef <+79>: mov 0x8152d84,%eax >>> 0x0809d8f4 <+84>: mov %esi,0x8152da0(,%eax,4) >>> 0x0809d8fb <+91>: mfence >>> 0x0809d8fe <+94>: mov %ebx,0x8152d84 >>> 0x0809d904 <+100>: movl $0x0,0x8152d80 >>> 0x0809d90e <+110>: call 0x807c2c0 <forceInterruptCheck> >>> 0x0809d913 <+115>: mov $0x1,%eax >>> 0x0809d918 <+120>: add $0x24,%esp >>> 0x0809d91b <+123>: pop %ebx >>> 0x0809d91c <+124>: pop %esi >>> 0x0809d91d <+125>: ret >>> 0x0809d91e <+126>: xchg %ax,%ax >>> 0x0809d920 <+128>: movl $0x810c888,(%esp) >>> 0x0809d927 <+135>: movl $0x0,0x8152d80 >>> 0x0809d931 <+145>: call 0x80a3720 <error> >>> 0x0809d936 <+150>: jmp 0x809d8ef <signalSemaphoreWithIndex+79> >>> End of assembler dump. >>> >>> Meanwhile, strace gets frozen showing this: >>> [..] >>> clone(child_stack=0, >>> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, >>> child_tidptr=0x7f63665cd9d0) = 3736 >>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >>> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 >>> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >>> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 >>> rt_sigaction(SIGINT, {0x42a8a0, [], SA_RESTORER, 0x7f6365ba3ad0}, >>> {SIG_DFL, [], SA_RESTORER, 0x7f6365ba3ad0}, 8) = 0 >>> wait4(-1, 0x7ffc4ef7f7e8, 0, NULL) = ? ERESTARTSYS (To be restarted >>> if SA_RESTART is set) >>> --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- >>> wait4(-1, >>> >> >> >

June 2, 2015

sorting repositories in monticello browser

by Peter UhnÃ¡k

Hi, is it possible to sort repositories in monticello browser? When I have many (20+) packages it is quite hard to find any one. :( Or perhaps even swap repository names around... so instead of http://smalltalkhub.com/#!/~Moose/PetitParser/ github://Uko/QualityAssistant:v0.4.1 gitfiletree:///home/.../me/my-project master there would be something like Moose/PetitParser (SmalltalkHub) Uko/QualityAssistant [v0.4.1] (GitHub) me/my-project [master] (GitFileTree) and of course sorted by alphabet. Thanks, Peter

June 2, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by Jose San Leandro

Hi Thierry, ConfigurationOfOSProcess-ThierryGoubier.38.mcz, which corresponds to version 4.6.2. Another workaround that would work for me is to be able to "resume" a previous load attempt of a Metacello project. Or a custom "hook" in Metacello to save the image after every dependency is successfully loaded. 2015-06-02 11:25 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > Hi Jose, > > yes, I've noticed that as well. It was, at a point, drastic (i.e. almost > allways lock-up) on my work development laptop; it now happens far less > often (but it does happens to me from time to time). > > Dave Lewis, the author of OSProcess, fixed one issue which solved most of > the lockups I had, but not all of them. The lockup is in the interaction > between OSProcess inside Pharo and the external shell command (i.e. it > concerns anything which uses OSProcess), and seems like missing a signal. > It is also machine and linux version dependent (Ubuntu 14.10 was horrible, > 14.04 and 15.04 on the same hardware are far less sensitive), and seems to > also depend on the load of the machine itself. > > By the way, which version of OSProcess you are using? > > Thierry > > > 2015-06-02 11:10 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > >> Hi, >> >> In one of our projects we are using Pharo4. The image gets built by >> gradle, which loads the Metacello project. Sometimes, we see the build >> process hangs. It just don't progress. >> >> When adding local gitfiletree:// dependencies manually through Monticello >> after a while Pharo gets frozen. It's not always the same repository, it's >> not always the same number of repositories before it hangs. >> >> I launched the image with strace, and attached gdb to the frozen process. >> It turns out It's waiting for a lock that gets never released. >> >> The environment is a 64b Gentoo Linux with enough of everything (multiple >> monitors, multiple cores, enough RAM). >> >> I hope anybody could point me how to dig deeper into this. >> >> # gdb >> (gdb) attach [pid] >> [..] >> Reading symbols from /usr/lib32/libbz2.so.1...(no debugging symbols >> found)...done. >> Loaded symbols for /usr/lib32/libbz2.so.1 >> 0x0809d8bb in signalSemaphoreWithIndex () >> (gdb) backtrace >> #0 0x0809d8bb in signalSemaphoreWithIndex () >> #1 0x0810868c in handleSignal () >> #2 <signal handler called> >> #3 0x0809d8c8 in signalSemaphoreWithIndex () >> #4 0x0809f0af in aioPoll () >> #5 0xf76f9671 in display_ioRelinquishProcessorForMicroseconds () from >> /home/chous/realhome/toolbox/pharo-5.0/pharo-vm/vm-display-X11 >> #6 0x080a1887 in ioRelinquishProcessorForMicroseconds () >> #7 0x080767fa in primitiveRelinquishProcessor () >> #8 0xb6fc838c in ?? () >> #9 0xb6fc3700 in ?? () >> #10 0xb7952882 in ?? () >> #11 0xb6fc3648 in ?? () >> (gdb) disassemble >> Dump of assembler code for function handleSignal: >> 0x081085e0 <+0>: sub $0x9c,%esp >> 0x081085e6 <+6>: mov %ebx,0x90(%esp) >> 0x081085ed <+13>: mov 0xa0(%esp),%ebx >> 0x081085f4 <+20>: mov %esi,0x94(%esp) >> 0x081085fb <+27>: mov %edi,0x98(%esp) >> 0x08108602 <+34>: movzbl 0x8168420(%ebx),%esi >> 0x08108609 <+41>: mov %ebx,%eax >> 0x0810860b <+43>: mov %esi,%edx >> 0x0810860d <+45>: call 0x81070d0 <forwardSignaltoSemaphoreAt> >> 0x08108612 <+50>: call 0x805aae0 <pthread_self@plt> >> 0x08108617 <+55>: mov 0x8168598,%edi >> 0x0810861d <+61>: cmp %edi,%eax >> 0x0810861f <+63>: je 0x8108680 <handleSignal+160> >> 0x08108621 <+65>: lea 0x10(%esp),%esi >> 0x08108625 <+69>: mov %esi,(%esp) >> 0x08108628 <+72>: call 0x805b330 <sigemptyset@plt> >> 0x0810862d <+77>: mov %ebx,0x4(%esp) >> 0x08108631 <+81>: mov %esi,(%esp) >> 0x08108634 <+84>: call 0x805b0c0 <sigaddset@plt> >> 0x08108639 <+89>: movl $0x0,0x8(%esp) >> 0x08108641 <+97>: mov %esi,0x4(%esp) >> 0x08108645 <+101>: movl $0x0,(%esp) >> 0x0810864c <+108>: call 0x805ada0 <pthread_sigmask@plt> >> 0x08108651 <+113>: mov %ebx,0x4(%esp) >> 0x08108655 <+117>: mov %edi,(%esp) >> 0x08108658 <+120>: call 0x805b240 <pthread_kill@plt> >> 0x0810865d <+125>: mov 0x90(%esp),%ebx >> 0x08108664 <+132>: mov 0x94(%esp),%esi >> 0x0810866b <+139>: mov 0x98(%esp),%edi >> 0x08108672 <+146>: add $0x9c,%esp >> 0x08108678 <+152>: ret >> 0x08108679 <+153>: lea 0x0(%esi,%eiz,1),%esi >> 0x08108680 <+160>: test %esi,%esi >> 0x08108682 <+162>: je 0x810865d <handleSignal+125> >> 0x08108684 <+164>: mov %esi,(%esp) >> 0x08108687 <+167>: call 0x809d8a0 <signalSemaphoreWithIndex> >> => 0x0810868c <+172>: jmp 0x810865d <handleSignal+125> >> End of assembler dump. >> (gdb) up 3 >> (gdb) disassemble >> Dump of assembler code for function signalSemaphoreWithIndex: >> 0x0809d8a0 <+0>: push %esi >> 0x0809d8a1 <+1>: xor %eax,%eax >> 0x0809d8a3 <+3>: push %ebx >> 0x0809d8a4 <+4>: sub $0x24,%esp >> 0x0809d8a7 <+7>: mov 0x30(%esp),%esi >> 0x0809d8ab <+11>: test %esi,%esi >> 0x0809d8ad <+13>: jle 0x809d918 <signalSemaphoreWithIndex+120> >> 0x0809d8af <+15>: mov $0x1,%edx >> 0x0809d8b4 <+20>: lea 0x0(%esi,%eiz,1),%esi >> 0x0809d8b8 <+24>: mfence >> 0x0809d8bb <+27>: mov $0x0,%eax >> 0x0809d8c0 <+32>: lock cmpxchg %edx,0x8152d80 >> => 0x0809d8c8 <+40>: mov %eax,0x1c(%esp) >> 0x0809d8cc <+44>: mov 0x1c(%esp),%eax >> 0x0809d8d0 <+48>: test %eax,%eax >> 0x0809d8d2 <+50>: jne 0x809d8b8 <signalSemaphoreWithIndex+24> >> 0x0809d8d4 <+52>: mov 0x8152d84,%edx >> 0x0809d8da <+58>: cmp $0x1ff,%edx >> 0x0809d8e0 <+64>: lea 0x1(%edx),%ebx >> 0x0809d8e3 <+67>: cmove %eax,%ebx >> 0x0809d8e6 <+70>: mov 0x8152d88,%eax >> 0x0809d8eb <+75>: cmp %ebx,%eax >> 0x0809d8ed <+77>: je 0x809d920 <signalSemaphoreWithIndex+128> >> 0x0809d8ef <+79>: mov 0x8152d84,%eax >> 0x0809d8f4 <+84>: mov %esi,0x8152da0(,%eax,4) >> 0x0809d8fb <+91>: mfence >> 0x0809d8fe <+94>: mov %ebx,0x8152d84 >> 0x0809d904 <+100>: movl $0x0,0x8152d80 >> 0x0809d90e <+110>: call 0x807c2c0 <forceInterruptCheck> >> 0x0809d913 <+115>: mov $0x1,%eax >> 0x0809d918 <+120>: add $0x24,%esp >> 0x0809d91b <+123>: pop %ebx >> 0x0809d91c <+124>: pop %esi >> 0x0809d91d <+125>: ret >> 0x0809d91e <+126>: xchg %ax,%ax >> 0x0809d920 <+128>: movl $0x810c888,(%esp) >> 0x0809d927 <+135>: movl $0x0,0x8152d80 >> 0x0809d931 <+145>: call 0x80a3720 <error> >> 0x0809d936 <+150>: jmp 0x809d8ef <signalSemaphoreWithIndex+79> >> End of assembler dump. >> >> Meanwhile, strace gets frozen showing this: >> [..] >> clone(child_stack=0, >> flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, >> child_tidptr=0x7f63665cd9d0) = 3736 >> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 >> rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 >> rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 >> rt_sigaction(SIGINT, {0x42a8a0, [], SA_RESTORER, 0x7f6365ba3ad0}, >> {SIG_DFL, [], SA_RESTORER, 0x7f6365ba3ad0}, 8) = 0 >> wait4(-1, 0x7ffc4ef7f7e8, 0, NULL) = ? ERESTARTSYS (To be restarted >> if SA_RESTART is set) >> --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- >> wait4(-1, >> > >

June 2, 2015

Re: [Pharo-users] Pharo Image Freeze (was Pharo 4 Image Freeze)

by Craig Johnson

Ok Case 15669 <https://pharo.fogbugz.com/f/cases/15669/Exception-inside-debugger-causes-lo…> opened. Craig On 2015/06/02 10:30 AM, Esteban Lorenzano wrote: > yes please > and weâll backport as soon as we have a fix. > > thanks! > >> On 02 Jun 2015, at 08:25, Craig Johnson <craig(a)hivemind.net> wrote: >> >> 2015-06-01 23:44 GMT+02:00*Nicolai Hess* nicolaihess at web.de <mailto:pharo-users%40lists.pharo.org?Subject=Re%3A%20%5BPharo-users%5D%20Pharo%204%20Image%20Freeze&In-Reply-To=%3CCAPED3ST3NWZD1UjO%3DLCz21KJVLy88KkHG7nT70Uy0e7_Tyt2mw%40mail.gmail.com%3E>: >> / >> /> This worked until pharo 40245 >>> -> it looks like phase4 in issue >>> 11996 <https://pharo.fogbugz.com/default.asp?11996> >>> Wrong exception handler problem >>> >>> introduced this behaviour. >> >> Thanks Nicolai. I see that it's still an issue in Pharo 5. >> I can try to create a new bug report if that Ok with the community. >> >> Craig >> >> >> >

June 2, 2015

Re: [Pharo-users] Visualizing a repository tree

by Peter UhnÃ¡k

HI Offray, I gave it a quick bash and come up with the following code. It's just a prototype and could be greatly simplified. - MCVersionInfo ancestors for whatever reason returned empty array down the line (so its cut off at the end), but I didn't investigate the problem - edge building and possibly ancestor retrieval could be simplified with builders; I think RTMondrian has methods for it but can't remember exactly (agilevisualization mentioned RTGraphBuilder but that has been removed to my knowledge) ~~~~~~~~~~~~~~~ mc := MCSmalltalkhubRepository allInstances detect: [ :m | m project = 'Roassal2' ]. root := mc versionInfoFromFileNamed: mc readableFileNames first. family := Set new. retriever := nil. retriever := [ :child | family add: child. child ancestors do: [ :a | retriever value: a ] ]. retriever value: root. obs := family asGroup. v := RTView new. es := RTEllipse new size: 15; color: Color blue; elementsOn: obs. v addAll: es. edges := RTEdge buildEdgesFromObjects: obs from: #yourself toAll: #ancestors using: (RTArrowedLine new withShorterDistanceAttachPoint; color: Color red) scope: es. v addAll: edges. es @ RTDraggable. es @ (RTLabelled new text: [ :m | m nameWithout: 'Roassal2' ]). v @ RTDraggableView. v @ RTZoomableView. RTDominanceTreeLayout new verticalGap: 30; horizontalGap: 15; on: es. v open ~~~~~~~~~~~~~~~~ Cheers, Peter â On Tue, Jun 2, 2015 at 5:39 AM, Offray Vladimir Luna CÃ¡rdenas < offray(a)riseup.net> wrote: > Hi, > > On a closer detail, seems that [1] contains the starting point I'm looking > for. I'll keep you posted and of course any other approach will be listened. > > [1] > https://dl.dropboxusercontent.com/u/31543901/AgileVisualization/Roassal/010… > > Cheers, > > Offray > > > On 01/06/15 22:04, Offray Vladimir Luna CÃ¡rdenas wrote: > >> Hi all, >> >> I had asked a similar question before with no much advances, but today I >> made a discovery that can improve the things a lot: how to export timeline >> data as structured JSON [1] (and of course this open the possibility to >> work with it on Pharo). Now I would like to graph the data as a tree with >> forks, merges and dates and authors of commits. I have seen chronia, but >> seems overkill for this feature (and is integrated with CVS only). >> >> [1] >> http://stackoverflow.com/questions/30577090/how-to-export-fossil-scm-timeli… >> >> As usual, any pointer on how to get this going will be greatly >> appreciated and I will give feedback to the community on how to do it. >> >> Cheers, >> >> Offray >> >> >> > >

June 2, 2015

PUngLite can't query large database

by Gareth Cox

Hi I've managed to create a large database, with PUnqLite, that is 562.1MB. I can't seem to query it though. I've set fetchBufferSize: (1024*1024*1023). I've set SmalltalkImage current vm extraVMMemory: (1024*1024*1023). I've played around in the info.plist setting the SqueakMaxHeapSize to ridiculous things. But I keep getting either out of memory or PqFetchError (probably because it can't fit the whole stream into the image?). This is why I was asking about the JX9 query and running a query like that to only return to the image with results I want. Any suggestions on how I can handle this? Info.plist: > <key>SqueakMaxHeapSize</key> > <integer>1073741824</integer> Pharo: > Image > ----- > *****/Pharo4.0.image > Pharo4.0 > Latest update: #40611 > Unnamed > > Operating System/Hardware > ------------------------- > Mac OS 1093 intel Kind Regards -- Gareth Cox IT Manager/Developer Inspired Org (PTY) Ltd

June 2, 2015

Re: [Pharo-users] Monticello / OS deadlock ?

by Thierry Goubier

Hi Jose, yes, I've noticed that as well. It was, at a point, drastic (i.e. almost allways lock-up) on my work development laptop; it now happens far less often (but it does happens to me from time to time). Dave Lewis, the author of OSProcess, fixed one issue which solved most of the lockups I had, but not all of them. The lockup is in the interaction between OSProcess inside Pharo and the external shell command (i.e. it concerns anything which uses OSProcess), and seems like missing a signal. It is also machine and linux version dependent (Ubuntu 14.10 was horrible, 14.04 and 15.04 on the same hardware are far less sensitive), and seems to also depend on the load of the machine itself. By the way, which version of OSProcess you are using? Thierry 2015-06-02 11:10 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > Hi, > > In one of our projects we are using Pharo4. The image gets built by > gradle, which loads the Metacello project. Sometimes, we see the build > process hangs. It just don't progress. > > When adding local gitfiletree:// dependencies manually through Monticello > after a while Pharo gets frozen. It's not always the same repository, it's > not always the same number of repositories before it hangs. > > I launched the image with strace, and attached gdb to the frozen process. > It turns out It's waiting for a lock that gets never released. > > The environment is a 64b Gentoo Linux with enough of everything (multiple > monitors, multiple cores, enough RAM). > > I hope anybody could point me how to dig deeper into this. > > # gdb > (gdb) attach [pid] > [..] > Reading symbols from /usr/lib32/libbz2.so.1...(no debugging symbols > found)...done. > Loaded symbols for /usr/lib32/libbz2.so.1 > 0x0809d8bb in signalSemaphoreWithIndex () > (gdb) backtrace > #0 0x0809d8bb in signalSemaphoreWithIndex () > #1 0x0810868c in handleSignal () > #2 <signal handler called> > #3 0x0809d8c8 in signalSemaphoreWithIndex () > #4 0x0809f0af in aioPoll () > #5 0xf76f9671 in display_ioRelinquishProcessorForMicroseconds () from > /home/chous/realhome/toolbox/pharo-5.0/pharo-vm/vm-display-X11 > #6 0x080a1887 in ioRelinquishProcessorForMicroseconds () > #7 0x080767fa in primitiveRelinquishProcessor () > #8 0xb6fc838c in ?? () > #9 0xb6fc3700 in ?? () > #10 0xb7952882 in ?? () > #11 0xb6fc3648 in ?? () > (gdb) disassemble > Dump of assembler code for function handleSignal: > 0x081085e0 <+0>: sub $0x9c,%esp > 0x081085e6 <+6>: mov %ebx,0x90(%esp) > 0x081085ed <+13>: mov 0xa0(%esp),%ebx > 0x081085f4 <+20>: mov %esi,0x94(%esp) > 0x081085fb <+27>: mov %edi,0x98(%esp) > 0x08108602 <+34>: movzbl 0x8168420(%ebx),%esi > 0x08108609 <+41>: mov %ebx,%eax > 0x0810860b <+43>: mov %esi,%edx > 0x0810860d <+45>: call 0x81070d0 <forwardSignaltoSemaphoreAt> > 0x08108612 <+50>: call 0x805aae0 <pthread_self@plt> > 0x08108617 <+55>: mov 0x8168598,%edi > 0x0810861d <+61>: cmp %edi,%eax > 0x0810861f <+63>: je 0x8108680 <handleSignal+160> > 0x08108621 <+65>: lea 0x10(%esp),%esi > 0x08108625 <+69>: mov %esi,(%esp) > 0x08108628 <+72>: call 0x805b330 <sigemptyset@plt> > 0x0810862d <+77>: mov %ebx,0x4(%esp) > 0x08108631 <+81>: mov %esi,(%esp) > 0x08108634 <+84>: call 0x805b0c0 <sigaddset@plt> > 0x08108639 <+89>: movl $0x0,0x8(%esp) > 0x08108641 <+97>: mov %esi,0x4(%esp) > 0x08108645 <+101>: movl $0x0,(%esp) > 0x0810864c <+108>: call 0x805ada0 <pthread_sigmask@plt> > 0x08108651 <+113>: mov %ebx,0x4(%esp) > 0x08108655 <+117>: mov %edi,(%esp) > 0x08108658 <+120>: call 0x805b240 <pthread_kill@plt> > 0x0810865d <+125>: mov 0x90(%esp),%ebx > 0x08108664 <+132>: mov 0x94(%esp),%esi > 0x0810866b <+139>: mov 0x98(%esp),%edi > 0x08108672 <+146>: add $0x9c,%esp > 0x08108678 <+152>: ret > 0x08108679 <+153>: lea 0x0(%esi,%eiz,1),%esi > 0x08108680 <+160>: test %esi,%esi > 0x08108682 <+162>: je 0x810865d <handleSignal+125> > 0x08108684 <+164>: mov %esi,(%esp) > 0x08108687 <+167>: call 0x809d8a0 <signalSemaphoreWithIndex> > => 0x0810868c <+172>: jmp 0x810865d <handleSignal+125> > End of assembler dump. > (gdb) up 3 > (gdb) disassemble > Dump of assembler code for function signalSemaphoreWithIndex: > 0x0809d8a0 <+0>: push %esi > 0x0809d8a1 <+1>: xor %eax,%eax > 0x0809d8a3 <+3>: push %ebx > 0x0809d8a4 <+4>: sub $0x24,%esp > 0x0809d8a7 <+7>: mov 0x30(%esp),%esi > 0x0809d8ab <+11>: test %esi,%esi > 0x0809d8ad <+13>: jle 0x809d918 <signalSemaphoreWithIndex+120> > 0x0809d8af <+15>: mov $0x1,%edx > 0x0809d8b4 <+20>: lea 0x0(%esi,%eiz,1),%esi > 0x0809d8b8 <+24>: mfence > 0x0809d8bb <+27>: mov $0x0,%eax > 0x0809d8c0 <+32>: lock cmpxchg %edx,0x8152d80 > => 0x0809d8c8 <+40>: mov %eax,0x1c(%esp) > 0x0809d8cc <+44>: mov 0x1c(%esp),%eax > 0x0809d8d0 <+48>: test %eax,%eax > 0x0809d8d2 <+50>: jne 0x809d8b8 <signalSemaphoreWithIndex+24> > 0x0809d8d4 <+52>: mov 0x8152d84,%edx > 0x0809d8da <+58>: cmp $0x1ff,%edx > 0x0809d8e0 <+64>: lea 0x1(%edx),%ebx > 0x0809d8e3 <+67>: cmove %eax,%ebx > 0x0809d8e6 <+70>: mov 0x8152d88,%eax > 0x0809d8eb <+75>: cmp %ebx,%eax > 0x0809d8ed <+77>: je 0x809d920 <signalSemaphoreWithIndex+128> > 0x0809d8ef <+79>: mov 0x8152d84,%eax > 0x0809d8f4 <+84>: mov %esi,0x8152da0(,%eax,4) > 0x0809d8fb <+91>: mfence > 0x0809d8fe <+94>: mov %ebx,0x8152d84 > 0x0809d904 <+100>: movl $0x0,0x8152d80 > 0x0809d90e <+110>: call 0x807c2c0 <forceInterruptCheck> > 0x0809d913 <+115>: mov $0x1,%eax > 0x0809d918 <+120>: add $0x24,%esp > 0x0809d91b <+123>: pop %ebx > 0x0809d91c <+124>: pop %esi > 0x0809d91d <+125>: ret > 0x0809d91e <+126>: xchg %ax,%ax > 0x0809d920 <+128>: movl $0x810c888,(%esp) > 0x0809d927 <+135>: movl $0x0,0x8152d80 > 0x0809d931 <+145>: call 0x80a3720 <error> > 0x0809d936 <+150>: jmp 0x809d8ef <signalSemaphoreWithIndex+79> > End of assembler dump. > > Meanwhile, strace gets frozen showing this: > [..] > clone(child_stack=0, > flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, > child_tidptr=0x7f63665cd9d0) = 3736 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 > rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 > rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 > rt_sigaction(SIGINT, {0x42a8a0, [], SA_RESTORER, 0x7f6365ba3ad0}, > {SIG_DFL, [], SA_RESTORER, 0x7f6365ba3ad0}, 8) = 0 > wait4(-1, 0x7ffc4ef7f7e8, 0, NULL) = ? ERESTARTSYS (To be restarted > if SA_RESTART is set) > --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- > wait4(-1, >

June 2, 2015

Monticello / OS deadlock ?

by Jose San Leandro

Hi, In one of our projects we are using Pharo4. The image gets built by gradle, which loads the Metacello project. Sometimes, we see the build process hangs. It just don't progress. When adding local gitfiletree:// dependencies manually through Monticello after a while Pharo gets frozen. It's not always the same repository, it's not always the same number of repositories before it hangs. I launched the image with strace, and attached gdb to the frozen process. It turns out It's waiting for a lock that gets never released. The environment is a 64b Gentoo Linux with enough of everything (multiple monitors, multiple cores, enough RAM). I hope anybody could point me how to dig deeper into this. # gdb (gdb) attach [pid] [..] Reading symbols from /usr/lib32/libbz2.so.1...(no debugging symbols found)...done. Loaded symbols for /usr/lib32/libbz2.so.1 0x0809d8bb in signalSemaphoreWithIndex () (gdb) backtrace #0 0x0809d8bb in signalSemaphoreWithIndex () #1 0x0810868c in handleSignal () #2 <signal handler called> #3 0x0809d8c8 in signalSemaphoreWithIndex () #4 0x0809f0af in aioPoll () #5 0xf76f9671 in display_ioRelinquishProcessorForMicroseconds () from /home/chous/realhome/toolbox/pharo-5.0/pharo-vm/vm-display-X11 #6 0x080a1887 in ioRelinquishProcessorForMicroseconds () #7 0x080767fa in primitiveRelinquishProcessor () #8 0xb6fc838c in ?? () #9 0xb6fc3700 in ?? () #10 0xb7952882 in ?? () #11 0xb6fc3648 in ?? () (gdb) disassemble Dump of assembler code for function handleSignal: 0x081085e0 <+0>: sub $0x9c,%esp 0x081085e6 <+6>: mov %ebx,0x90(%esp) 0x081085ed <+13>: mov 0xa0(%esp),%ebx 0x081085f4 <+20>: mov %esi,0x94(%esp) 0x081085fb <+27>: mov %edi,0x98(%esp) 0x08108602 <+34>: movzbl 0x8168420(%ebx),%esi 0x08108609 <+41>: mov %ebx,%eax 0x0810860b <+43>: mov %esi,%edx 0x0810860d <+45>: call 0x81070d0 <forwardSignaltoSemaphoreAt> 0x08108612 <+50>: call 0x805aae0 <pthread_self@plt> 0x08108617 <+55>: mov 0x8168598,%edi 0x0810861d <+61>: cmp %edi,%eax 0x0810861f <+63>: je 0x8108680 <handleSignal+160> 0x08108621 <+65>: lea 0x10(%esp),%esi 0x08108625 <+69>: mov %esi,(%esp) 0x08108628 <+72>: call 0x805b330 <sigemptyset@plt> 0x0810862d <+77>: mov %ebx,0x4(%esp) 0x08108631 <+81>: mov %esi,(%esp) 0x08108634 <+84>: call 0x805b0c0 <sigaddset@plt> 0x08108639 <+89>: movl $0x0,0x8(%esp) 0x08108641 <+97>: mov %esi,0x4(%esp) 0x08108645 <+101>: movl $0x0,(%esp) 0x0810864c <+108>: call 0x805ada0 <pthread_sigmask@plt> 0x08108651 <+113>: mov %ebx,0x4(%esp) 0x08108655 <+117>: mov %edi,(%esp) 0x08108658 <+120>: call 0x805b240 <pthread_kill@plt> 0x0810865d <+125>: mov 0x90(%esp),%ebx 0x08108664 <+132>: mov 0x94(%esp),%esi 0x0810866b <+139>: mov 0x98(%esp),%edi 0x08108672 <+146>: add $0x9c,%esp 0x08108678 <+152>: ret 0x08108679 <+153>: lea 0x0(%esi,%eiz,1),%esi 0x08108680 <+160>: test %esi,%esi 0x08108682 <+162>: je 0x810865d <handleSignal+125> 0x08108684 <+164>: mov %esi,(%esp) 0x08108687 <+167>: call 0x809d8a0 <signalSemaphoreWithIndex> => 0x0810868c <+172>: jmp 0x810865d <handleSignal+125> End of assembler dump. (gdb) up 3 (gdb) disassemble Dump of assembler code for function signalSemaphoreWithIndex: 0x0809d8a0 <+0>: push %esi 0x0809d8a1 <+1>: xor %eax,%eax 0x0809d8a3 <+3>: push %ebx 0x0809d8a4 <+4>: sub $0x24,%esp 0x0809d8a7 <+7>: mov 0x30(%esp),%esi 0x0809d8ab <+11>: test %esi,%esi 0x0809d8ad <+13>: jle 0x809d918 <signalSemaphoreWithIndex+120> 0x0809d8af <+15>: mov $0x1,%edx 0x0809d8b4 <+20>: lea 0x0(%esi,%eiz,1),%esi 0x0809d8b8 <+24>: mfence 0x0809d8bb <+27>: mov $0x0,%eax 0x0809d8c0 <+32>: lock cmpxchg %edx,0x8152d80 => 0x0809d8c8 <+40>: mov %eax,0x1c(%esp) 0x0809d8cc <+44>: mov 0x1c(%esp),%eax 0x0809d8d0 <+48>: test %eax,%eax 0x0809d8d2 <+50>: jne 0x809d8b8 <signalSemaphoreWithIndex+24> 0x0809d8d4 <+52>: mov 0x8152d84,%edx 0x0809d8da <+58>: cmp $0x1ff,%edx 0x0809d8e0 <+64>: lea 0x1(%edx),%ebx 0x0809d8e3 <+67>: cmove %eax,%ebx 0x0809d8e6 <+70>: mov 0x8152d88,%eax 0x0809d8eb <+75>: cmp %ebx,%eax 0x0809d8ed <+77>: je 0x809d920 <signalSemaphoreWithIndex+128> 0x0809d8ef <+79>: mov 0x8152d84,%eax 0x0809d8f4 <+84>: mov %esi,0x8152da0(,%eax,4) 0x0809d8fb <+91>: mfence 0x0809d8fe <+94>: mov %ebx,0x8152d84 0x0809d904 <+100>: movl $0x0,0x8152d80 0x0809d90e <+110>: call 0x807c2c0 <forceInterruptCheck> 0x0809d913 <+115>: mov $0x1,%eax 0x0809d918 <+120>: add $0x24,%esp 0x0809d91b <+123>: pop %ebx 0x0809d91c <+124>: pop %esi 0x0809d91d <+125>: ret 0x0809d91e <+126>: xchg %ax,%ax 0x0809d920 <+128>: movl $0x810c888,(%esp) 0x0809d927 <+135>: movl $0x0,0x8152d80 0x0809d931 <+145>: call 0x80a3720 <error> 0x0809d936 <+150>: jmp 0x809d8ef <signalSemaphoreWithIndex+79> End of assembler dump. Meanwhile, strace gets frozen showing this: [..] clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f63665cd9d0) = 3736 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0 rt_sigaction(SIGINT, {0x42a8a0, [], SA_RESTORER, 0x7f6365ba3ad0}, {SIG_DFL, [], SA_RESTORER, 0x7f6365ba3ad0}, 8) = 0 wait4(-1, 0x7ffc4ef7f7e8, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGWINCH {si_signo=SIGWINCH, si_code=SI_KERNEL} --- wait4(-1,

June 2, 2015

Re: [Pharo-users] Pharo Image Freeze (was Pharo 4 Image Freeze)

by Esteban Lorenzano

yes please and weâll backport as soon as we have a fix. thanks! > On 02 Jun 2015, at 08:25, Craig Johnson <craig(a)hivemind.net> wrote: > > 2015-06-01 23:44 GMT+02:00*Nicolai Hess* nicolaihess at web.de <mailto:pharo-users%40lists.pharo.org?Subject=Re%3A%20%5BPharo-users%5D%20Pharo%204%20Image%20Freeze&In-Reply-To=%3CCAPED3ST3NWZD1UjO%3DLCz21KJVLy88KkHG7nT70Uy0e7_Tyt2mw%40mail.gmail.com%3E>: > / > /> This worked until pharo 40245 >> -> it looks like phase4 in issue >> 11996 <https://pharo.fogbugz.com/default.asp?11996> >> Wrong exception handler problem >> >> introduced this behaviour. > > > Thanks Nicolai. I see that it's still an issue in Pharo 5. > I can try to create a new bug report if that Ok with the community. > > Craig > > >

June 2, 2015

Re: [Pharo-users] Slot questions

by Marcus Denker

Yes, indeedâ¦ Knuthâs Literary Programming was one radical (yet very static and Book-Like) try. We added the tutorials, that is already better than just the class comment, but they are then not âconnectedâ with the codeâ¦ So indeed: a lot of open space for research + practical improvements. For Slots I will stay very old fashioned and write a Tutorial. Marcus > On 01 Jun 2015, at 11:44, tsl4 <scott(a)hnn.bz> wrote: > > As usual, though, a lot of interesting ideas emerge from this. > > If we were to do documentation in a "Smalltalky" way, then what would it > look like? > > Perhaps something like Doug Engelbart's NLS system, in outlines, but each > element of the outline would have an associative history to it. That would > mean breaking the process of description down to familiar component parts. > Selecting a version of the software would flow through the outline, calling > up the appropriate historical elements. That would enable comparative > documentation. > > Or is it possible to find some kind of self documentation that would be > better than the useful but a little crude class comments? > > It seems like such a basic thing to get right, but really very little work > has been done on it. > > > > -- > View this message in context: http://forum.world.st/Slot-questions-tp4679631p4829738.html > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. >

June 2, 2015