- Pharo-users - lists.pharo.org

Re: [Pharo-users] Visualizing a repository tree

by Peter UhnÃ¡k

On Tue, Jun 2, 2015 at 3:07 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Interesting. The dominance tree layout is quite interesting for this use > case. > There were some upward lines at the bottom of the graph for no apparent reason, not sure what was going on there yet, so I'll look into the layout when I have more time. Alternatively you could also use Sugiyama, however either due to the choice of heuristics, or some bug it places high priority on last levels which is really bad (since it is no longer at proper hierarchical layers). Peter > Doru > > On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > >> 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 >>>> >>>> >>>> >>> >>> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

June 2, 2015

Re: [Pharo-users] sorting repositories in monticello browser

by Peter UhnÃ¡k

> > Hum. Alphabetical order on what? That is, to take your example > me/my-project, should it be done on 'me' or on 'my-project'? > Hm, that's a good question. It should however be the first letter; so if there is "Uko/QualityAssistant" I would expect it sorted by "Uko"; otherwise there is no much sense in sorting since I can't do binary-ish search. If it was by the package name, then the name would have to be swapped; "QualityAssistant by Uko" or something like that so I can always look at the first letter. > > At the moment, repositories ordered by time of addition in your image has > a 'known' behavior: your own repositories come last (and to find them, you > just have to look last). Alphabetical ordering would make a mess of that. > Really? Is that something new? This is a screenshot from Pharo 4.0; but it's possible that I have broken something â The order seems to me at least to be the order in which the repositories were added. Could your ordering be solved by just having more readable entries (the > entries you suggest)? > I would say that it would improve it regardless of sorting. Peter

June 2, 2015

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

by Thierry Goubier

2015-06-02 15:03 GMT+02:00 Jose San Leandro <jose.sanleandro(a)osoco.es>: > No problem, of course. > > It's a dual-core running a custom 4.0.4-hardened-r2 kernel, > hardened/linux/amd64/selinux profile (but in permissive mode), glibc > version 2.20-r2, with multilib and selinux USE flags active. > > I can provide more information if that helps, of course. Even ssh to a > Docker container running in it, but it won't support X I fear. > When the pharo process get locked, can you do a kill -SIGUSR1 on the pharo process and look at the output? It will give the status inside the vm. Thierry > > Thanks! > > 2015-06-02 14:34 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > >> >> >> 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

Re: [Pharo-users] Visualizing a repository tree

by Tudor Girba

Interesting. The dominance tree layout is quite interesting for this use case. Doru On Tue, Jun 2, 2015 at 12:09 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > 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 >>> >>> >>> >> >> > -- www.tudorgirba.com "Every thing has its own flow"

June 2, 2015

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

by Jose San Leandro

No problem, of course. It's a dual-core running a custom 4.0.4-hardened-r2 kernel, hardened/linux/amd64/selinux profile (but in permissive mode), glibc version 2.20-r2, with multilib and selinux USE flags active. I can provide more information if that helps, of course. Even ssh to a Docker container running in it, but it won't support X I fear. Thanks! 2015-06-02 14:34 GMT+02:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 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

Re: [Pharo-users] Visualizing a repository tree

by Thierry Goubier

2015-06-02 12:09 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > 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 > It's a Roassal packages issue. Last time I looked, history was cut at a certain point in most Roassal packages, but I don't know if this was done on purpose. Thierry > - 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

Re: [Pharo-users] sorting repositories in monticello browser

by Thierry Goubier

2015-06-02 12:33 GMT+02:00 Peter UhnÃ¡k <i.uhnak(a)gmail.com>: > 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) > Good idea. I'll have a look into doing that. > and of course sorted by alphabet. > Hum. Alphabetical order on what? That is, to take your example me/my-project, should it be done on 'me' or on 'my-project'? At the moment, repositories ordered by time of addition in your image has a 'known' behavior: your own repositories come last (and to find them, you just have to look last). Alphabetical ordering would make a mess of that. Could your ordering be solved by just having more readable entries (the entries you suggest)? Thierry > Thanks, > Peter >

June 2, 2015

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