restrict initial stack space expansion to rlimit - the process killer...

restrict initial stack space expansion to rlimit - the process killer...

[Paweł Sikora]

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.

Re: restrict initial stack space expansion to rlimit - the process killer...

[Américo Wang]

2010/3/4 Paweł Sikora <pawel.sikora@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!

Re: restrict initial stack space expansion to rlimit - the process killer...

[Paweł Sikora]

Dnia 04-03-2010 o 11:05:03 Américo Wang <xiyou.wangcong@gmail.com>  
napisał(a):

> 2010/3/4 Paweł Sikora <pawel.sikora@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.

Re: restrict initial stack space expansion to rlimit - the process killer...

[Michael Neuling]

In message <op.u81oymnjzipv1w@pawels.alatek.krakow.pl> you wrote:
> Dnia 04-03-2010 o 11:05:03 Am=C3=A9rico Wang <xiyou.wangcong@gmail.com> =
>  =
> 
> napisa=C5=82(a):
> 
> > 2010/3/4 Pawe=C5=82 Sikora <pawel.sikora@agmk.net>:
> >> Hi all,
> >>
> >> i'm currently testing the 2.6.32.9 and observing random process killi=
> ng
> >> 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---tem=
> p_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.

Agreed.  It unfortunately missed .9 by a few hours.

Mikey