From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32374 invoked by alias); 29 May 2019 21:16:01 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 32358 invoked by uid 89); 29 May 2019 21:16:01 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,SPF_PASS autolearn=ham version=3.3.1 spammy=Download, H*r:network, Luck, apt X-HELO: muller.mulle-kybernetik.com Received: from muller.mulle-kybernetik.com (HELO muller.mulle-kybernetik.com) (78.46.34.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 29 May 2019 21:15:59 +0000 Received: (qmail 41307 invoked from network); 29 May 2019 23:15:56 +0200 Received: from unknown (HELO ?192.168.2.34?) (nat@78.46.34.175) by mail.mulle-kybernetik.com with ESMTPS (ECDHE-RSA-AES128-SHA encrypted); 29 May 2019 23:15:56 +0200 Subject: Re: Problem with atexit and _dl_fini To: libc-help@sourceware.org, Adhemerval Zanella References: <87blzypg5j.fsf@mid.deneb.enyo.de> <0a7c2435-43f8-8dfb-83ab-22ceff7ca51c@mulle-kybernetik.com> <115bdae5-bcd3-0e41-8325-784a0d702259@linaro.org> <5CE522F8.9090505@mulle-kybernetik.com> <3976645d-167d-fb9a-d1bb-69789e5d13b1@linaro.org> <5CE56AD3.1070505@mulle-kybernetik.com> <5339669a-ddff-5376-be95-2d2fa1823b61@linaro.org> From: Nat! Message-ID: <4bd3b601-7bf8-2673-b96c-983b89907e1d@mulle-kybernetik.com> Date: Wed, 29 May 2019 21:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: <5339669a-ddff-5376-be95-2d2fa1823b61@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2019-05/txt/msg00054.txt.bz2 On 22.05.19 21:34, Adhemerval Zanella wrote: > > Do you have a easy way to provide the environment you are testing? > Now I can provide a way to reproduce the problem and debug it. While this may look a little daunting at first, it's mostly just copy/paste of commands and in the end you have a gdb session with a glibc that can be stepped through in the debugger. atexit-bug.md --- This is about the simplest way to reproduce the `atexit` problem in glibc. ## Create a docker with the development environment Get the Dockerfile: ``` curl -L -O 'https://raw.githubusercontent.com/MulleFoundation/foundation-developer/release/Dockerfile' ``` As we want to debug with the newest **glibc** we need to use `ubuntu:disco` instead of `ubuntu:bionic`, so change the first line of the `Dockerfile` to `FROM ubuntu:disco`. Now you are ready to build the container: ``` sudo docker build -t foundation -f Dockerfile "`mktemp -d`" sudo docker run --cap-add=SYS_PTRACE --security-opt seccomp=unconfined -i -t --rm foundation ``` ## Get some tools via apt Inside the docker get some prerequisites for debugging and for **glibc**: ``` sudo apt-get -y install vim gdb gawk bison gettext texinfo ``` ## Download the project Inside the docker get the **MulleObjC** project. This will place you in a virtual environment subshell.  With `exit` you can get out (you should). ``` mulle-sde https://github.com/mulle-objc/MulleObjC/archive/latest.tar.gz exit ``` ## Remove atexit fix With the `atexit` fix, there are no problems, so we need to take it out: ``` cd MulleObjC/test mulle-sde environment set MULLE_ATEXIT_URL 'https://github.com/mulle-core/mulle-atexit/archive/placebo.tar.gz' ``` ## Build with a debug version of glibc Build everything with a custom built version of **glibc**, so we can debug it. While still being in `MulleObjC/test`: ``` mulle-sourcetree -N add --nodetype 'tar' --marks 'no-all-load,no-import' --userinfo 'aliases=c' --url '${GLIBC_2_29_URL:-https://ftp.gnu.org/gnu/glibc/glibc-2.29.tar.xz}' --branch '${GLIBC_2_29_BRANCH}' 'glibc' mulle-sourcetree move glibc top mulle-sde dependency craftinfo set glibc CC_DEBUG '-O1 -g' mulle-sde dependency craftinfo set glibc SKIP_AUTOCONF YES mulle-sde test craft ``` ## Build first test and observe the error While still being in `MulleObjC/test`: ``` mulle-sde -vvv test run --keep-exe 0_noleak/noleak.m ``` The error should appear. Now you can look at the debugger to seem the wrong atexit order: ``` MULLE_TESTALLOCATOR=1 MULLE_OBJC_PEDANTIC_EXIT=YES gdb /MulleObjC/test/0_noleak/noleak.debug.exe ``` > Breakpoints to set: > > b atexit > b mulle_testallocator_exit > b mulle_objc_global_atexit --- I tried these steps and it worked out successfully for me. Good Luck    Nat!