lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 4 Mar 2010 18:05:03 +0800
From:	Américo Wang <xiyou.wangcong@...il.com>
To:	Paweł Sikora <pawel.sikora@...k.net>
Cc:	linux-kernel@...r.kernel.org, mikey@...ling.org
Subject: Re: restrict initial stack space expansion to rlimit - the process 
	killer...

2010/3/4 Paweł Sikora <pawel.sikora@...k.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!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ