From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/1333 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: sabotage linux X86_64 image with LXDE desktop released Date: Sat, 21 Jul 2012 19:05:23 -0400 Message-ID: <20120721230522.GC544@brightrain.aerifal.cx> References: <500B181F.7080406@barfooze.de> <20120721205055.GA544@brightrain.aerifal.cx> <500B3703.5030607@barfooze.de> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1342911953 6664 80.91.229.3 (21 Jul 2012 23:05:53 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 21 Jul 2012 23:05:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-1334-gllmg-musl=m.gmane.org@lists.openwall.com Sun Jul 22 01:05:54 2012 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1SsikD-0002ir-IR for gllmg-musl@plane.gmane.org; Sun, 22 Jul 2012 01:05:53 +0200 Original-Received: (qmail 23857 invoked by uid 550); 21 Jul 2012 23:05:52 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 23843 invoked from network); 21 Jul 2012 23:05:52 -0000 Content-Disposition: inline In-Reply-To: <500B3703.5030607@barfooze.de> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:1333 Archived-At: On Sun, Jul 22, 2012 at 01:10:59AM +0200, John Spencer wrote: > >>here is a screenshot: http://i.imgur.com/Lz7Ov.png > >Something seems very wrong with those task manager vm sizes... > >Is this indicative of a bug on musl's side? > > here's what it's doing (note that PAGE_SIZE was originally an > external variable which got once filled with sc_sysconf values, > i needed to patch it away because of the conflict with the macro of > the same name) That shouldn't break anything.. > void get_task_details(gint pid,struct task *task) > { > task->size=0; > > sprintf(line,"/proc/%d/statm",pid); > fd=open(line,O_RDONLY); > if(fd==-1) return; > read(fd,line,256); > sscanf(line,"%d %d",&task->size,&task->rss); > close(fd); > if(!task->size) return; > task->size*=PAGE_SIZE; > task->rss*=PAGE_SIZE; > > struct task > { > // ... > gint size; > gint rss; > }; gint is not large enough to store memory sizes on 64-bit machines (though I doubt you're overflowing it here...) and %d may not be the right scanf conversion for gint unless gint is defined as int... Otherwise, I don't see what's wrong... Rich