Your message dated Sat, 23 Jan 2016 11:51:25 +0100 with message-id <[email protected]> and subject line Re: Bug#570283: runaway memory leak when processing DBOX2 CDK configure scripts has caused the Debian Bug report #570283, regarding runaway memory leak when processing DBOX2 CDK configure scripts to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 570283: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=570283 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Package: dash Version: 0.5.5.1-3 Severity: important Hi all, this is a bit of a weird problem. I tried to compile a DBOX2 (tuxbox) image on a SheevaPlug and found dash would eat up all memory while running certain configure scripts. In order to find out what's going on, I compiled dash with - apt-get source dash - cd dash-0.5.5.1 - dkpg-buildpackage -rfakeroot -nc and link the resulting binary to /bin/dash for debugging purposes. However, the problem did not occur with the binary compiled this way, with or without debugging information (DEB_BUILD_OPTIONS set ot unset) In order to reproduce the problem, a rather lengthy procedure is required (on a SheevaPlug with Debian Sequeeze and development tools): # useradd dbox # su - dbox $ mkdir prj; cd prj $ mkdir tuxbox; cd tuxbox $ for i in apps boot driver hostapps cdk; do git clone git://gitorious.org/~seife/tuxbox-cvs/$i.git done $ cd cdk $ ./autogen.sh $ ./configure --with-cvsdir=/home/dbox/tuxbox \ --prefix=/home/dbox/tuxbox/dbox2 \ --with-boxtype=dbox2 \ --with-checkImage=rename \ --enable-fx2-c64emu \ --enable-fx2-lemm \ --enable-fx2-mines \ --enable-fx2-sudoku \ --enable-fx2-yahtzee \ --enable-fx2-solitair \ --enable-fx2-satfind \ --enable-dvbsnoop \ --with-procps $ make yadd-neutrino This may work fine (I remember seeing an OOM in dmesg but it was somewhere in the middle of the build and hard to evaluate so I rebuilt with /bin/sh pointing to /bin/bash.) It will take around 1-2 hours to bootstrap the cross-build environment and compile the base installation. The next step, however, seems easier to reproduce: $ ulimit -v 786432 $ make extra ( rm -rf ncftp-3.2.2 || /bin/true ) && bunzip2 -cd /home/dbox/prj/tuxbox/cdk/Archive/ncftp-3.2.2-src.tar.bz2 | TAPE=- tar -x && / ((for f1 in config.guess config.sub; do (for f2 in `find ncftp-3.2.2 -name / $f1`; do (test -e $f2 && rm -f $f2 && ln -s / /home/dbox/prj/tuxbox/cdk/Patches/$f1 $f2 && echo "updated $f2") done) / / done) || /bin/true) updated ncftp-3.2.2/sh/config.guess updated ncftp-3.2.2/sh/config.sub cd ncftp-3.2.2 && \ AR=powerpc-tuxbox-linux-gnu-ar AS=powerpc-tuxbox-linux-gnu-as CC=powerpc-tuxbox-linux-gnu-gcc CXX=powerpc-tuxbox-linux-gnu-g++ NM=powerpc-tuxbox-linux-gnu-nm RANLIB=powerpc-tuxbox-linux-gnu-ranlib STRIP=powerpc-tuxbox-linux-gnu-strip CFLAGS="-pipe -Os" CXXFLAGS="-pipe -Os" LDFLAGS="-Wl,-O1" PKG_CONFIG_PATH=/home/dbox/prj/tuxbox/dbox2/cdkroot/lib/pkgconfig \ ./configure \ --build=armv5tel-unknown-linux-gnueabi \ --host=powerpc-tuxbox-linux-gnu \ --prefix= && \ make clean all LD=powerpc-tuxbox-linux-gnu-ld && \ make install DESTDIR=/home/dbox/prj/tuxbox/dbox2/cdkroot creating cache ./config.cache checking if you set and exported the environment variable CC... powerpc-tuxbox-linux-gnu-gcc checking for environment variable CFLAGS... -pipe -Os checking for environment variable CPPFLAGS... no checking for environment variable LDFLAGS... -Wl,-O1 checking for environment variable LIBS... no checking version of C library... Segmentation fault ^C This is where dash used up all of the memory and ended up with a SEGV because I set "ulimit -v 786432". As mentioned above, trying to compile dash on the SheevaPlug resulted in a binary that did not show this particular behavior. Might be an issue with the gcc version used to compile the packages, or a cross-compile issue... -- System Information: Debian Release: squeeze/sid APT prefers testing APT policy: (500, 'testing') Architecture: armel (armv5tel) Kernel: Linux 2.6.32-cm1.0-kirkwood Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages dash depends on: ii debianutils 3.2.2 Miscellaneous utilities specific t ii dpkg 1.15.5.6 Debian package management system ii libc6 2.10.2-2 GNU C Library: Shared libraries dash recommends no packages. dash suggests no packages. -- debconf information: * dash/sh: true
--- End Message ---
--- Begin Message ---Hello, I am closing this bug report: the issue you reported is not reproducible on other setups with the current version of dash. Feel free to reopen if you are still experiencing this problem. Regards, -- Gioele Barabucci <[email protected]>
--- End Message ---
