From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2224 invoked by alias); 1 Oct 2009 11:03:06 -0000 Received: (qmail 866 invoked by uid 48); 1 Oct 2009 11:02:51 -0000 Date: Thu, 01 Oct 2009 11:03:00 -0000 From: "zecke at selfish dot org" To: glibc-bugs@sources.redhat.com Message-ID: <20091001110250.10717.zecke@selfish.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/10717] New: memusagestat SIGFPE and other observations X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2009-10/txt/msg00003.txt.bz2 This applie to memusagestat.c of the latest git version. I'm not sure if the usage of memusagestat.c is supported and if I'm seeing a bug and if patches are welcome. Using the -T option on a memusage "trace" from an application that was halted and didn't write out the header entry results in a SIGFPE due "maxsize_total" being 0. If a patch is welcome I would change the "repair" logic to update maxsize total header entry as well, write the whole headent structure to disk. And i would move the repair above assigning the maxsize_* variables. I can upload the data file, my simple test application and a gdb backtrace if that is required/wanted/wished. The other observation is that the -t option is not doing anything, from looking at the trace (this is not from glibc git... but the distro version) is that the time sometimes jump backwards. Does this classify as opening a new bug? -- Summary: memusagestat SIGFPE and other observations Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: zecke at selfish dot org CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=10717 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.