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, 04 Mar 2010 14:26:36 +0100
From:	Paweł Sikora <pawel.sikora@...k.net>
To:	Américo Wang <xiyou.wangcong@...il.com>
Cc:	linux-kernel@...r.kernel.org, mikey@...ling.org
Subject: Re: restrict initial stack space expansion to rlimit - the process
 killer...

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

> 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!

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@...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