restrict initial stack space expansion to rlimit - the process killer...
in [Kernel]
|
Prev: ACPI / EC: Remove race between EC driver and suspend process (rev. 3)
Next: restrict initial stack space expansion to rlimit - the process killer...
From: Paweł Sikora on 4 Mar 2010 04:50 Hi all, i'm currently testing the 2.6.32.9 and observing random process killing on my builder machine (x86-64) which contains several tcl/bash scripts for svn checkout, compilation, archive and ftp deploying. here's a fragment of build log: (...) [CXX] obj-release-i486-gnu-linux/genMappingRst.o [CXX] obj-release-i486-gnu-linux/otelloVerdiThread.o i486-gnu-linux-g++: Internal error: Killed (program as) Please submit a full bug report. See <http://gcc.gnu.org/bugs.html> for instructions. make[1]: *** [obj-release-i486-gnu-linux/genMappingRst.o] Error 1 the builder process tree looks like this: $ pstree -Acl ?---screen-+-bash---loop.sh-+-loop.sh---tclsh8.4---temp_9_12676174---tclsh8.4---temp_3_12676174---tclsh8.4---temp_4_12676174---tclsh8.4---temp_9_12676176---make---make-+-sh---ccache---x86_64-gnu-linu-+-as | | | `-cc1plus | | `-sh---ccache---x86_64-gnu-linu-+-as | | `-cc1plus | `-tee `-bash---pstree as you can see there're few levels of bash and tclsh(8.4) and make/ccache/binutils/g++ workers at the bottom. i've noticed that rolling back to the 2.6.32.8 (or just reverting the 'ulimit -s' commit: 35e2093d5d7b632c083af3578c05876375828314) fixes the problem. so, is it my stack ulimit (8192) to small, or maybe the new limit calculations are wrong? shoud i bump the stack limit for new kernels? please CC me on reply. BR, Pawel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Paweł Sikora on 4 Mar 2010 08:30
Dnia 04-03-2010 o 11:05:03 Américo Wang <xiyou.wangcong(a)gmail.com> napisał(a): > 2010/3/4 Paweł Sikora <pawel.sikora(a)agmk.net>: >> Hi all, >> >> i'm currently testing the 2.6.32.9 and observing random process killing >> on my builder machine (x86-64) which contains several tcl/bash >> scripts for svn checkout, compilation, archive and ftp deploying. >> >> here's a fragment of build log: >> >> (...) >> [CXX] obj-release-i486-gnu-linux/genMappingRst.o >> [CXX] obj-release-i486-gnu-linux/otelloVerdiThread.o >> i486-gnu-linux-g++: Internal error: Killed (program as) >> Please submit a full bug report. >> See <http://gcc.gnu.org/bugs.html> for instructions. >> make[1]: *** [obj-release-i486-gnu-linux/genMappingRst.o] Error 1 >> >> the builder process tree looks like this: >> >> $ pstree -Acl >> ?---screen-+-bash---loop.sh-+-loop.sh---tclsh8.4---temp_9_12676174---tclsh8.4---temp_3_12676174---tclsh8.4---temp_4_12676174---tclsh8.4---temp_9_12676176---make---make-+-sh---ccache---x86_64-gnu-linu-+-as >> | >> | >> | `-cc1plus >> | >> | >> `-sh---ccache---x86_64-gnu-linu-+-as >> | >> | >> `-cc1plus >> | `-tee >> `-bash---pstree >> >> >> as you can see there're few levels of bash and tclsh(8.4) >> and make/ccache/binutils/g++ workers at the bottom. >> >> i've noticed that rolling back to the 2.6.32.8 (or just reverting >> the 'ulimit -s' commit: 35e2093d5d7b632c083af3578c05876375828314) >> fixes the problem. >> >> so, is it my stack ulimit (8192) to small, or maybe the new limit >> calculations are wrong? shoud i bump the stack limit for new kernels? > > > Please check if you have this patch: > > http://lkml.org/lkml/2010/2/15/61 > > Thanks! 2.6.32.9 + a17e18790a8c47113a73139d54a375dc9ccd8f08 works fine. i think it should be pushed to 2.6.32.10 as soon as possible. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |