From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Antipov Newsgroups: gmane.emacs.devel Subject: Re: Dumper problems and a possible solutions Date: Wed, 25 Jun 2014 22:30:22 +0400 Message-ID: <53AB153E.4080905@yandex.ru> References: <20140624171955.GS179@brightrain.aerifal.cx> <53AB0EF8.4090608@yandex.ru> <20140625180823.GV179@brightrain.aerifal.cx> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1403721064 24530 80.91.229.3 (25 Jun 2014 18:31:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 25 Jun 2014 18:31:04 +0000 (UTC) Cc: emacs-devel@gnu.org To: Rich Felker Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 25 20:30:58 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WzryC-0001DD-Of for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 20:30:56 +0200 Original-Received: from localhost ([::1]:40389 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzryC-0008Bb-BW for ged-emacs-devel@m.gmane.org; Wed, 25 Jun 2014 14:30:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzry2-0008Ao-QW for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:30:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wzrxv-0001jz-6B for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:30:46 -0400 Original-Received: from forward6l.mail.yandex.net ([84.201.143.139]:57658) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wzrxu-0001jh-Ue for emacs-devel@gnu.org; Wed, 25 Jun 2014 14:30:39 -0400 Original-Received: from smtp14.mail.yandex.net (smtp14.mail.yandex.net [95.108.131.192]) by forward6l.mail.yandex.net (Yandex) with ESMTP id B96DC14E0E21; Wed, 25 Jun 2014 22:30:23 +0400 (MSK) Original-Received: from smtp14.mail.yandex.net (localhost [127.0.0.1]) by smtp14.mail.yandex.net (Yandex) with ESMTP id 622891B61245; Wed, 25 Jun 2014 22:30:23 +0400 (MSK) Original-Received: from unknown (unknown [37.139.80.10]) by smtp14.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 7HMSp6P0gs-UM4O7Rpi; Wed, 25 Jun 2014 22:30:22 +0400 (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client certificate not present) X-Yandex-Uniq: 583fa9b0-5f9d-438e-a9c1-083e3cb8faa4 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1403721022; bh=EyjlO65K/fYWimwn/qDxVf4kwBeGJY0t5OcCuUFJlng=; h=Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dfr6Pnn1bWUivMpl0hvu6gKg5ev5BSoiZ4i87VEJWQVuJ74C8BiIAYkbip4gXfiom V+Haa5sETlgqizajtx/NREVZ8BdAMio0I59/wDA3+JT0nsRFNVjZXNYizVNlclfu22 iI3/1tF/UH85VvFlOsJnlh5YytKZ2BwiRGL7jwwY= Authentication-Results: smtp14.mail.yandex.net; dkim=pass header.i=@yandex.ru User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 In-Reply-To: <20140625180823.GV179@brightrain.aerifal.cx> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 84.201.143.139 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172714 Archived-At: On 06/25/2014 10:08 PM, Rich Felker wrote: > Are there such objects that need to be preserved across dumping? I don't know, and the worst thing is that we can't control over this. With my debug build, 'ldd src/temacs | wc -l' shows 112 external libraries. What if just one of these libraries uses malloc() to allocate an internal object in __attribute__((constructor)) function? There is no way to handle this except intercepting all malloc() calls. This way we move to our own heap management, which will have the same heap parsability issues like system's malloc(), etc. Dmitry