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.w...@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...@gmail.com] > Sent: 2015年10月23日 15:34 > To: Kai Wang X > Cc: chet.ra...@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.w...@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...@gmail.com] >> Sent: 2015年10月23日 1:08 >> To: Kai Wang X >> Cc: chet.ra...@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.w...@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...@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.w...@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.ra...@case.edu] >>>> Sent: 2015年10月20日 21:31 >>>> To: Kai Wang X; bug-bash@gnu.org >>>> Cc: chet.ra...@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 c...@case.edu http://cnswww.cns.cwru.edu/~chet/