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@gmail.com>:
2015-06-02 12:14 GMT+02:00 Jose San Leandro <jose.sanleandro@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@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@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,