Re: Bash crash

[Piotr Grzybowski]

hey Kai,

 I mean, run:

gdb --args /usr/src/debug/bash/4.3-r1/bash-4.3/bash /opt/com/bin/com.sh start

 cheers,
pg


On Fri, Oct 23, 2015 at 9:43 AM, Kai Wang X <kai.x.wang@ericsson.com> wrote:
> Hi Piotr,
>
> I am sorry I am not clear for your first question.
>
> FYI:
> bash-4.3$ /bin/sh --version
> GNU bash, version 4.3.30(1)-release (aarch64-mvista-linux-gnu)
> Copyright (C) 2013 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
>
> This is free software; you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> bash-4.3$ ls -l /bin.sh
> ls: cannot access /bin.sh: No such file or directory
> bash-4.3$ ls -l /bin/sh
> lrwxrwxrwx 1 root root 9 Oct 23  2015 /bin/sh -> /bin/bash
> bash-4.3$ ^C
>
> -----Original Message-----
> From: Piotr Grzybowski [mailto:narsil.pl@gmail.com]
> Sent: 2015年10月23日 15:34
> To: Kai Wang X
> Cc: chet.ramey@case.edu; Aharon Robbins; bug-bash@gnu.org
> Subject: Re: Bash crash
>
>  I would run the same script under gdb (in the similar manner as you examine 
> the core in the case of dead.bashbug4.3.3), what happens when you do that?
>  also, could you please (just for me) run:
>
>  /bin/sh --version
>
> sincerely,
> pg
>
>
> On Fri, Oct 23, 2015 at 7:49 AM, Kai Wang X <kai.x.wang@ericsson.com> wrote:
>> Hi Piotr,
>>
>> Actually when process com is not needed, "com.sh" will not be launched 
>> instead of commenting one line.
>> I have never tried that. From the coredump log of 4.3, seems it crashed 
>> before line 187. (crashed at 114).
>> Thank you.
>>
>> -----Original Message-----
>> From: Piotr Grzybowski [mailto:narsil.pl@gmail.com]
>> Sent: 2015年10月23日 1:08
>> To: Kai Wang X
>> Cc: chet.ramey@case.edu; Aharon Robbins; bug-bash@gnu.org
>> Subject: Re: Bash crash
>>
>>  do I understand correctly, that when you comment the line 187 the issue is 
>> not existent?
>>
>> cheers,
>> pg
>>
>>
>> On Thu, Oct 22, 2015 at 4:39 AM, Kai Wang X <kai.x.wang@ericsson.com> wrote:
>>> Hi all,
>>>
>>> Thank you all!
>>>
>>> The issue happens since we added a new process launched by a bash script. 
>>> Before that, no "sbrk issues" were found and hundreds of process including 
>>> scripts were running in my equipment. So it is hard for me to believe that 
>>> there are RAM or sbrk issues already exist on my system. Also bash is used 
>>> by more users world-wide, so ... I am being confused...
>>>
>>> The process named "com" launched by script command "com.sh start". Pls 
>>> refer to the attached files. It looks easy, doesn't it?
>>>
>>> @Piotr,
>>>
>>> Sure. Every equipment has the possibility of the issue.
>>>
>>>
>>> -----Original Message-----
>>> From: Piotr Grzybowski [mailto:narsil.pl@gmail.com]
>>> Sent: 2015年10月21日 19:27
>>> To: Kai Wang X
>>> Subject: Re: Bash crash
>>>
>>> hello,
>>>
>>>  does the problem also appear on other pieces of equipment? I mean, 
>>> different phisical machine, of the same sort?
>>>
>>> pg
>>>
>>>
>>>
>>>
>>>
>>> On Wed, Oct 21, 2015 at 4:29 AM, Kai Wang X <kai.x.wang@ericsson.com> wrote:
>>>> Hi Chet,
>>>>
>>>> Thank you for your response.
>>>>
>>>> But it does not make sense since sbrk failure will be checked:
>>>>
>>>>   mp = (union mhead *) sbrk (sbrk_amt);
>>>>
>>>>   /* Totally out of memory. */
>>>>   if ((long)mp == -1)
>>>>     goto morecore_done;
>>>>
>>>> The script just runs when my equipment boots up. Also it is hard to 
>>>> reproduce in my environment. Only every few times of my equipment booting 
>>>> up, it generates a coredump file.
>>>>
>>>> -----Original Message-----
>>>> From: Chet Ramey [mailto:chet.ramey@case.edu]
>>>> Sent: 2015年10月20日 21:31
>>>> To: Kai Wang X; bug-bash@gnu.org
>>>> Cc: chet.ramey@case.edu
>>>> Subject: Re: Bash crash
>>>>
>>>> On 10/19/15 10:47 PM, Kai Wang X wrote:
>>>>> Dear,
>>>>>
>>>>>
>>>>>
>>>>> We have two products which are using bash 4.2 and 4.3 separately.
>>>>> They all meet bash crash issue. Please refer to the attached files.
>>>>>
>>>>> It is hard for me to understand the bash source code to find the
>>>>> root cause out.
>>>>
>>>> It really looks like sbrk(2) is failing here, but since I don't have any 
>>>> way to reproduce it, that may not be it.  This could be caused by your 
>>>> process exceeding its memory resource limit or your system's swap space 
>>>> being exhausted.
>>>>
>>>> Chet
>>>>
>>>> --
>>>> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>>>>                  ``Ars longa, vita brevis'' - Hippocrates
>>>> Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/