From timprepscius@hotmail.com Mon Sep 15 11:33:05 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from hotmail.com (bay2-dav41.bay2.hotmail.com [65.54.246.98]) by mail.gnome.org (Postfix) with ESMTP id 272641867B for ; Mon, 15 Sep 2003 11:33:05 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 08:33:14 -0700 Received: from 128.186.229.30 by bay2-dav41.bay2.hotmail.com with DAV; Mon, 15 Sep 2003 15:33:14 +0000 X-Originating-IP: [128.186.229.30] X-Originating-Email: [timprepscius@hotmail.com] From: "Timothy Prepscius" To: Subject: memprof without X Date: Mon, 15 Sep 2003 11:35:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C37B7D.6B5A14E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: X-OriginalArrivalTime: 15 Sep 2003 15:33:14.0573 (UTC) FILETIME=[ADB2C7D0:01C37B9E] Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been messing with memprof trying to remove the GUI and have it run = when no X display is available, printing out information every X = seconds. I have successfully been able to get it to run without a gui. However = when it initializes the gnome/gtk? libraries it uses for pipes/sockets, = I guess it also continues to try to connect to a display even when there = is no need for one. Has anyone done this before? Is it appropriate to post a code archive set to this mailing group? thanks, tim ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've been messing with memprof trying = to remove the=20 GUI and have it run when no X display is available, printing out = information=20 every X seconds.
 
I have successfully been able to get it = to run=20 without a gui.  However when it initializes the gnome/gtk? = libraries it=20 uses for pipes/sockets, I guess it also continues to try to connect = to a=20 display even when there is no need for one.
 
Has anyone done this = before?
 
Is it appropriate to post a code = archive set to=20 this mailing group?
 
thanks,
 
tim
------=_NextPart_000_0012_01C37B7D.6B5A14E0-- From otaylor@redhat.com Mon Sep 15 11:51:22 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 05B8818516 for ; Mon, 15 Sep 2003 11:51:22 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8FFpTk27965; Mon, 15 Sep 2003 11:51:29 -0400 Subject: Re: memprof without X From: Owen Taylor To: Timothy Prepscius Cc: memprof-list@gnome.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1063641089.18549.54.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Mon, 15 Sep 2003 11:51:29 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Mon, 2003-09-15 at 14:35, Timothy Prepscius wrote: > I've been messing with memprof trying to remove the GUI and have it > run when no X display is available, printing out information every X > seconds. > > I have successfully been able to get it to run without a gui. However > when it initializes the gnome/gtk? libraries it uses for > pipes/sockets, I guess it also continues to try to connect to a > display even when there is no need for one. > > Has anyone done this before? The very first version of memprof was a non-GUI perl script (though it still used Perl/GTK+ for the mainloop.) gtk_init_check() can be used to check for whether a display is available. However, the use of GNOME libraries inside memprof may make using this harder. You probably can call gtk_init_check() first, and then call gnome_program_init() later if that succeeds... it isn't really "proper" but should work fine except for some unlikely command line combinations. The pipes/socket handling code in memprof shouldn't require any sort of display connection. > Is it appropriate to post a code archive set to this mailing group? Patches against the current code are appropriate here, and better than an entire archive. Regards, Owen From hal@sfc.keio.ac.jp Sat Sep 20 00:33:48 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from dns11.mail.yahoo.co.jp (dns11.mail.yahoo.co.jp [210.81.151.144]) by mail.gnome.org (Postfix) with SMTP id 3B8341843A for ; Sat, 20 Sep 2003 00:33:47 -0400 (EDT) Received: from unknown (HELO YahooBB219017052196.bbtec.net) (tokyohal@219.17.52.196 with plain) by dns11.mail.yahoo.co.jp with SMTP; 20 Sep 2003 04:33:55 -0000 X-Apparently-From: Subject: Profile disappears when process ends From: Harry Tily To: memprof-list@gnome.org Content-Type: text/plain Message-Id: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 20 Sep 2003 13:33:19 +0900 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: Hi I'm trying to figure out how to use memprof (isn't there anyone on this list who can use it and has time to write a very brief manual?) I've managed to get my process running and generate its profile and leak information, but as soon as the process ends, all that data vanishes again. This only gives me a few seconds to look at the output and try to work out what's happening. How do I keep the information on screen? Thanks! Harry From otaylor@redhat.com Sat Sep 20 08:56:07 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4BADD1837A for ; Sat, 20 Sep 2003 08:56:07 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KCuEk26257; Sat, 20 Sep 2003 08:56:14 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Content-Type: text/plain Message-Id: <1064062522.12135.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 08:55:23 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > Hi > > I'm trying to figure out how to use memprof (isn't there anyone on this > list who can use it and has time to write a very brief manual?) I've > managed to get my process running and generate its profile and leak > information, but as soon as the process ends, all that data vanishes > again. This only gives me a few seconds to look at the output and try to > work out what's happening. How do I keep the information on screen? With recent versions of glibc, the code in memprof to keep the child from exiting stopped working. I haven't tracked the problem down ... what you can do is simply put a sleep(3600) at the end of your main routine. Regards, Owen From otaylor@redhat.com Sat Sep 20 10:55:42 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1043B189D8 for ; Sat, 20 Sep 2003 10:55:42 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KEtmk04440; Sat, 20 Sep 2003 10:55:49 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064062522.12135.0.camel@localhost.localdomain> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> <1064062522.12135.0.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-X18BTMzPM8gs3oH5OM6c" Message-Id: <1064069696.12135.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 10:54:56 -0400 Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: --=-X18BTMzPM8gs3oH5OM6c Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2003-09-20 at 08:55, Owen Taylor wrote: > On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > > Hi > > > > I'm trying to figure out how to use memprof (isn't there anyone on this > > list who can use it and has time to write a very brief manual?) I've > > managed to get my process running and generate its profile and leak > > information, but as soon as the process ends, all that data vanishes > > again. This only gives me a few seconds to look at the output and try to > > work out what's happening. How do I keep the information on screen? > > With recent versions of glibc, the code in memprof to keep the child > from exiting stopped working. I haven't tracked the problem down ... > what you can do is simply put a sleep(3600) at the end of your > main routine. Just put a fix/workaround for this into CVS: Sat Sep 20 10:52:06 2003 Owen Taylor * intercept.c): Switch to atexit() as the primary means of intercepting exiting. It isn't as good as interposing _exit, but interposing _exit doesn't work with newer versions of GNU libc. Regards, Owen --=-X18BTMzPM8gs3oH5OM6c Content-Disposition: attachment; filename=exit.patch Content-Type: text/x-patch; name=exit.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: intercept.c =================================================================== RCS file: /cvs/gnome/memprof/intercept.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- intercept.c 5 Sep 2002 19:16:38 -0000 1.1 +++ intercept.c 20 Sep 2003 14:54:16 -0000 1.2 @@ -55,6 +55,7 @@ typedef struct { static void new_process (ThreadInfo *thread, pid_t old_pid, MIOperation operation); +static void atexit_trap (void); static int (*old_execve) (const char *filename, char *const argv[], @@ -76,7 +77,7 @@ static ThreadInfo threads[MAX_THREADS]; static char *socket_path = NULL; static unsigned int seqno = 0; -#undef ENABLE_DEBUG +#define ENABLE_DEBUG #ifdef ENABLE_DEBUG #define MI_DEBUG(arg) mi_debug arg @@ -170,6 +171,8 @@ initialize () old_clone = dlsym(RTLD_NEXT, "__clone"); old__exit = dlsym(RTLD_NEXT, "_exit"); + atexit (atexit_trap); + mi_init (); initialized = 1; } @@ -470,42 +473,64 @@ int clone (int (*fn) (void *arg), return __clone (fn, child_stack, flags, arg); } +static void +exit_wait (void) +{ + MIInfo info; + ThreadInfo *thread; + int count; + char response; + info.any.operation = MI_EXIT; + info.any.seqno = seqno++; + info.any.pid = getpid(); + + mi_stop (); + + thread = find_thread (info.any.pid); + + if (mi_write (thread->outfd, &info, sizeof (MIInfo))) + /* Wait for a response before really exiting + */ + while (1) { + count = read (thread->outfd, &response, 1); + if (count >= 0 || errno != EINTR) + break; + } + + close (thread->outfd); + thread->pid = 0; + release_thread (thread); +} + +/* Because _exit() isn't interposable in recent versions of + * GNU libc, we can't depend on this, and instead use the less-good + * atexit_trap() below. But we leave this here just in case we + * are using an old version of libc where _exit() is interposable, + * so we can trap a wider range of exit conditions + */ void _exit (int status) { if (initialized <= 0) - abort_unitialized ("exit"); + abort_unitialized ("_exit"); - MI_DEBUG (("Exiting\n")); + MI_DEBUG (("_Exiting\n")); if (tracing) { - MIInfo info; - ThreadInfo *thread; - int count; - char response; - info.any.operation = MI_EXIT; - info.any.seqno = seqno++; - info.any.pid = getpid(); - - mi_stop (); - - thread = find_thread (info.any.pid); - - if (mi_write (thread->outfd, &info, sizeof (MIInfo))) - /* Wait for a response before really exiting - */ - while (1) { - count = read (thread->outfd, &response, 1); - if (count >= 0 || errno != EINTR) - break; - } - - close (thread->outfd); - thread->pid = 0; - release_thread (thread); + exit_wait (); + tracing = 0; } (*old__exit) (status); +} + +static void +atexit_trap (void) +{ + if (tracing) { + exit_wait (); + tracing = 0; + } } static void construct () __attribute__ ((constructor)); --=-X18BTMzPM8gs3oH5OM6c-- From timprepscius@hotmail.com Mon Sep 15 11:33:05 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from hotmail.com (bay2-dav41.bay2.hotmail.com [65.54.246.98]) by mail.gnome.org (Postfix) with ESMTP id 272641867B for ; Mon, 15 Sep 2003 11:33:05 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 08:33:14 -0700 Received: from 128.186.229.30 by bay2-dav41.bay2.hotmail.com with DAV; Mon, 15 Sep 2003 15:33:14 +0000 X-Originating-IP: [128.186.229.30] X-Originating-Email: [timprepscius@hotmail.com] From: "Timothy Prepscius" To: Subject: memprof without X Date: Mon, 15 Sep 2003 11:35:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C37B7D.6B5A14E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: X-OriginalArrivalTime: 15 Sep 2003 15:33:14.0573 (UTC) FILETIME=[ADB2C7D0:01C37B9E] Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been messing with memprof trying to remove the GUI and have it run = when no X display is available, printing out information every X = seconds. I have successfully been able to get it to run without a gui. However = when it initializes the gnome/gtk? libraries it uses for pipes/sockets, = I guess it also continues to try to connect to a display even when there = is no need for one. Has anyone done this before? Is it appropriate to post a code archive set to this mailing group? thanks, tim ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've been messing with memprof trying = to remove the=20 GUI and have it run when no X display is available, printing out = information=20 every X seconds.
 
I have successfully been able to get it = to run=20 without a gui.  However when it initializes the gnome/gtk? = libraries it=20 uses for pipes/sockets, I guess it also continues to try to connect = to a=20 display even when there is no need for one.
 
Has anyone done this = before?
 
Is it appropriate to post a code = archive set to=20 this mailing group?
 
thanks,
 
tim
------=_NextPart_000_0012_01C37B7D.6B5A14E0-- From otaylor@redhat.com Mon Sep 15 11:51:22 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 05B8818516 for ; Mon, 15 Sep 2003 11:51:22 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8FFpTk27965; Mon, 15 Sep 2003 11:51:29 -0400 Subject: Re: memprof without X From: Owen Taylor To: Timothy Prepscius Cc: memprof-list@gnome.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1063641089.18549.54.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Mon, 15 Sep 2003 11:51:29 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Mon, 2003-09-15 at 14:35, Timothy Prepscius wrote: > I've been messing with memprof trying to remove the GUI and have it > run when no X display is available, printing out information every X > seconds. > > I have successfully been able to get it to run without a gui. However > when it initializes the gnome/gtk? libraries it uses for > pipes/sockets, I guess it also continues to try to connect to a > display even when there is no need for one. > > Has anyone done this before? The very first version of memprof was a non-GUI perl script (though it still used Perl/GTK+ for the mainloop.) gtk_init_check() can be used to check for whether a display is available. However, the use of GNOME libraries inside memprof may make using this harder. You probably can call gtk_init_check() first, and then call gnome_program_init() later if that succeeds... it isn't really "proper" but should work fine except for some unlikely command line combinations. The pipes/socket handling code in memprof shouldn't require any sort of display connection. > Is it appropriate to post a code archive set to this mailing group? Patches against the current code are appropriate here, and better than an entire archive. Regards, Owen From hal@sfc.keio.ac.jp Sat Sep 20 00:33:48 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from dns11.mail.yahoo.co.jp (dns11.mail.yahoo.co.jp [210.81.151.144]) by mail.gnome.org (Postfix) with SMTP id 3B8341843A for ; Sat, 20 Sep 2003 00:33:47 -0400 (EDT) Received: from unknown (HELO YahooBB219017052196.bbtec.net) (tokyohal@219.17.52.196 with plain) by dns11.mail.yahoo.co.jp with SMTP; 20 Sep 2003 04:33:55 -0000 X-Apparently-From: Subject: Profile disappears when process ends From: Harry Tily To: memprof-list@gnome.org Content-Type: text/plain Message-Id: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 20 Sep 2003 13:33:19 +0900 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: Hi I'm trying to figure out how to use memprof (isn't there anyone on this list who can use it and has time to write a very brief manual?) I've managed to get my process running and generate its profile and leak information, but as soon as the process ends, all that data vanishes again. This only gives me a few seconds to look at the output and try to work out what's happening. How do I keep the information on screen? Thanks! Harry From otaylor@redhat.com Sat Sep 20 08:56:07 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4BADD1837A for ; Sat, 20 Sep 2003 08:56:07 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KCuEk26257; Sat, 20 Sep 2003 08:56:14 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Content-Type: text/plain Message-Id: <1064062522.12135.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 08:55:23 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > Hi > > I'm trying to figure out how to use memprof (isn't there anyone on this > list who can use it and has time to write a very brief manual?) I've > managed to get my process running and generate its profile and leak > information, but as soon as the process ends, all that data vanishes > again. This only gives me a few seconds to look at the output and try to > work out what's happening. How do I keep the information on screen? With recent versions of glibc, the code in memprof to keep the child from exiting stopped working. I haven't tracked the problem down ... what you can do is simply put a sleep(3600) at the end of your main routine. Regards, Owen From otaylor@redhat.com Sat Sep 20 10:55:42 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1043B189D8 for ; Sat, 20 Sep 2003 10:55:42 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KEtmk04440; Sat, 20 Sep 2003 10:55:49 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064062522.12135.0.camel@localhost.localdomain> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> <1064062522.12135.0.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-X18BTMzPM8gs3oH5OM6c" Message-Id: <1064069696.12135.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 10:54:56 -0400 Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: --=-X18BTMzPM8gs3oH5OM6c Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2003-09-20 at 08:55, Owen Taylor wrote: > On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > > Hi > > > > I'm trying to figure out how to use memprof (isn't there anyone on this > > list who can use it and has time to write a very brief manual?) I've > > managed to get my process running and generate its profile and leak > > information, but as soon as the process ends, all that data vanishes > > again. This only gives me a few seconds to look at the output and try to > > work out what's happening. How do I keep the information on screen? > > With recent versions of glibc, the code in memprof to keep the child > from exiting stopped working. I haven't tracked the problem down ... > what you can do is simply put a sleep(3600) at the end of your > main routine. Just put a fix/workaround for this into CVS: Sat Sep 20 10:52:06 2003 Owen Taylor * intercept.c): Switch to atexit() as the primary means of intercepting exiting. It isn't as good as interposing _exit, but interposing _exit doesn't work with newer versions of GNU libc. Regards, Owen --=-X18BTMzPM8gs3oH5OM6c Content-Disposition: attachment; filename=exit.patch Content-Type: text/x-patch; name=exit.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: intercept.c =================================================================== RCS file: /cvs/gnome/memprof/intercept.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- intercept.c 5 Sep 2002 19:16:38 -0000 1.1 +++ intercept.c 20 Sep 2003 14:54:16 -0000 1.2 @@ -55,6 +55,7 @@ typedef struct { static void new_process (ThreadInfo *thread, pid_t old_pid, MIOperation operation); +static void atexit_trap (void); static int (*old_execve) (const char *filename, char *const argv[], @@ -76,7 +77,7 @@ static ThreadInfo threads[MAX_THREADS]; static char *socket_path = NULL; static unsigned int seqno = 0; -#undef ENABLE_DEBUG +#define ENABLE_DEBUG #ifdef ENABLE_DEBUG #define MI_DEBUG(arg) mi_debug arg @@ -170,6 +171,8 @@ initialize () old_clone = dlsym(RTLD_NEXT, "__clone"); old__exit = dlsym(RTLD_NEXT, "_exit"); + atexit (atexit_trap); + mi_init (); initialized = 1; } @@ -470,42 +473,64 @@ int clone (int (*fn) (void *arg), return __clone (fn, child_stack, flags, arg); } +static void +exit_wait (void) +{ + MIInfo info; + ThreadInfo *thread; + int count; + char response; + info.any.operation = MI_EXIT; + info.any.seqno = seqno++; + info.any.pid = getpid(); + + mi_stop (); + + thread = find_thread (info.any.pid); + + if (mi_write (thread->outfd, &info, sizeof (MIInfo))) + /* Wait for a response before really exiting + */ + while (1) { + count = read (thread->outfd, &response, 1); + if (count >= 0 || errno != EINTR) + break; + } + + close (thread->outfd); + thread->pid = 0; + release_thread (thread); +} + +/* Because _exit() isn't interposable in recent versions of + * GNU libc, we can't depend on this, and instead use the less-good + * atexit_trap() below. But we leave this here just in case we + * are using an old version of libc where _exit() is interposable, + * so we can trap a wider range of exit conditions + */ void _exit (int status) { if (initialized <= 0) - abort_unitialized ("exit"); + abort_unitialized ("_exit"); - MI_DEBUG (("Exiting\n")); + MI_DEBUG (("_Exiting\n")); if (tracing) { - MIInfo info; - ThreadInfo *thread; - int count; - char response; - info.any.operation = MI_EXIT; - info.any.seqno = seqno++; - info.any.pid = getpid(); - - mi_stop (); - - thread = find_thread (info.any.pid); - - if (mi_write (thread->outfd, &info, sizeof (MIInfo))) - /* Wait for a response before really exiting - */ - while (1) { - count = read (thread->outfd, &response, 1); - if (count >= 0 || errno != EINTR) - break; - } - - close (thread->outfd); - thread->pid = 0; - release_thread (thread); + exit_wait (); + tracing = 0; } (*old__exit) (status); +} + +static void +atexit_trap (void) +{ + if (tracing) { + exit_wait (); + tracing = 0; + } } static void construct () __attribute__ ((constructor)); --=-X18BTMzPM8gs3oH5OM6c-- From timprepscius@hotmail.com Mon Sep 15 11:33:05 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from hotmail.com (bay2-dav41.bay2.hotmail.com [65.54.246.98]) by mail.gnome.org (Postfix) with ESMTP id 272641867B for ; Mon, 15 Sep 2003 11:33:05 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 08:33:14 -0700 Received: from 128.186.229.30 by bay2-dav41.bay2.hotmail.com with DAV; Mon, 15 Sep 2003 15:33:14 +0000 X-Originating-IP: [128.186.229.30] X-Originating-Email: [timprepscius@hotmail.com] From: "Timothy Prepscius" To: Subject: memprof without X Date: Mon, 15 Sep 2003 11:35:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C37B7D.6B5A14E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: X-OriginalArrivalTime: 15 Sep 2003 15:33:14.0573 (UTC) FILETIME=[ADB2C7D0:01C37B9E] Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been messing with memprof trying to remove the GUI and have it run = when no X display is available, printing out information every X = seconds. I have successfully been able to get it to run without a gui. However = when it initializes the gnome/gtk? libraries it uses for pipes/sockets, = I guess it also continues to try to connect to a display even when there = is no need for one. Has anyone done this before? Is it appropriate to post a code archive set to this mailing group? thanks, tim ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've been messing with memprof trying = to remove the=20 GUI and have it run when no X display is available, printing out = information=20 every X seconds.
 
I have successfully been able to get it = to run=20 without a gui.  However when it initializes the gnome/gtk? = libraries it=20 uses for pipes/sockets, I guess it also continues to try to connect = to a=20 display even when there is no need for one.
 
Has anyone done this = before?
 
Is it appropriate to post a code = archive set to=20 this mailing group?
 
thanks,
 
tim
------=_NextPart_000_0012_01C37B7D.6B5A14E0-- From otaylor@redhat.com Mon Sep 15 11:51:22 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 05B8818516 for ; Mon, 15 Sep 2003 11:51:22 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8FFpTk27965; Mon, 15 Sep 2003 11:51:29 -0400 Subject: Re: memprof without X From: Owen Taylor To: Timothy Prepscius Cc: memprof-list@gnome.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1063641089.18549.54.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Mon, 15 Sep 2003 11:51:29 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Mon, 2003-09-15 at 14:35, Timothy Prepscius wrote: > I've been messing with memprof trying to remove the GUI and have it > run when no X display is available, printing out information every X > seconds. > > I have successfully been able to get it to run without a gui. However > when it initializes the gnome/gtk? libraries it uses for > pipes/sockets, I guess it also continues to try to connect to a > display even when there is no need for one. > > Has anyone done this before? The very first version of memprof was a non-GUI perl script (though it still used Perl/GTK+ for the mainloop.) gtk_init_check() can be used to check for whether a display is available. However, the use of GNOME libraries inside memprof may make using this harder. You probably can call gtk_init_check() first, and then call gnome_program_init() later if that succeeds... it isn't really "proper" but should work fine except for some unlikely command line combinations. The pipes/socket handling code in memprof shouldn't require any sort of display connection. > Is it appropriate to post a code archive set to this mailing group? Patches against the current code are appropriate here, and better than an entire archive. Regards, Owen From hal@sfc.keio.ac.jp Sat Sep 20 00:33:48 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from dns11.mail.yahoo.co.jp (dns11.mail.yahoo.co.jp [210.81.151.144]) by mail.gnome.org (Postfix) with SMTP id 3B8341843A for ; Sat, 20 Sep 2003 00:33:47 -0400 (EDT) Received: from unknown (HELO YahooBB219017052196.bbtec.net) (tokyohal@219.17.52.196 with plain) by dns11.mail.yahoo.co.jp with SMTP; 20 Sep 2003 04:33:55 -0000 X-Apparently-From: Subject: Profile disappears when process ends From: Harry Tily To: memprof-list@gnome.org Content-Type: text/plain Message-Id: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 20 Sep 2003 13:33:19 +0900 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: Hi I'm trying to figure out how to use memprof (isn't there anyone on this list who can use it and has time to write a very brief manual?) I've managed to get my process running and generate its profile and leak information, but as soon as the process ends, all that data vanishes again. This only gives me a few seconds to look at the output and try to work out what's happening. How do I keep the information on screen? Thanks! Harry From otaylor@redhat.com Sat Sep 20 08:56:07 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4BADD1837A for ; Sat, 20 Sep 2003 08:56:07 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KCuEk26257; Sat, 20 Sep 2003 08:56:14 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Content-Type: text/plain Message-Id: <1064062522.12135.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 08:55:23 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > Hi > > I'm trying to figure out how to use memprof (isn't there anyone on this > list who can use it and has time to write a very brief manual?) I've > managed to get my process running and generate its profile and leak > information, but as soon as the process ends, all that data vanishes > again. This only gives me a few seconds to look at the output and try to > work out what's happening. How do I keep the information on screen? With recent versions of glibc, the code in memprof to keep the child from exiting stopped working. I haven't tracked the problem down ... what you can do is simply put a sleep(3600) at the end of your main routine. Regards, Owen From otaylor@redhat.com Sat Sep 20 10:55:42 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1043B189D8 for ; Sat, 20 Sep 2003 10:55:42 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KEtmk04440; Sat, 20 Sep 2003 10:55:49 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064062522.12135.0.camel@localhost.localdomain> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> <1064062522.12135.0.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-X18BTMzPM8gs3oH5OM6c" Message-Id: <1064069696.12135.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 10:54:56 -0400 Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: --=-X18BTMzPM8gs3oH5OM6c Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2003-09-20 at 08:55, Owen Taylor wrote: > On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > > Hi > > > > I'm trying to figure out how to use memprof (isn't there anyone on this > > list who can use it and has time to write a very brief manual?) I've > > managed to get my process running and generate its profile and leak > > information, but as soon as the process ends, all that data vanishes > > again. This only gives me a few seconds to look at the output and try to > > work out what's happening. How do I keep the information on screen? > > With recent versions of glibc, the code in memprof to keep the child > from exiting stopped working. I haven't tracked the problem down ... > what you can do is simply put a sleep(3600) at the end of your > main routine. Just put a fix/workaround for this into CVS: Sat Sep 20 10:52:06 2003 Owen Taylor * intercept.c): Switch to atexit() as the primary means of intercepting exiting. It isn't as good as interposing _exit, but interposing _exit doesn't work with newer versions of GNU libc. Regards, Owen --=-X18BTMzPM8gs3oH5OM6c Content-Disposition: attachment; filename=exit.patch Content-Type: text/x-patch; name=exit.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: intercept.c =================================================================== RCS file: /cvs/gnome/memprof/intercept.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- intercept.c 5 Sep 2002 19:16:38 -0000 1.1 +++ intercept.c 20 Sep 2003 14:54:16 -0000 1.2 @@ -55,6 +55,7 @@ typedef struct { static void new_process (ThreadInfo *thread, pid_t old_pid, MIOperation operation); +static void atexit_trap (void); static int (*old_execve) (const char *filename, char *const argv[], @@ -76,7 +77,7 @@ static ThreadInfo threads[MAX_THREADS]; static char *socket_path = NULL; static unsigned int seqno = 0; -#undef ENABLE_DEBUG +#define ENABLE_DEBUG #ifdef ENABLE_DEBUG #define MI_DEBUG(arg) mi_debug arg @@ -170,6 +171,8 @@ initialize () old_clone = dlsym(RTLD_NEXT, "__clone"); old__exit = dlsym(RTLD_NEXT, "_exit"); + atexit (atexit_trap); + mi_init (); initialized = 1; } @@ -470,42 +473,64 @@ int clone (int (*fn) (void *arg), return __clone (fn, child_stack, flags, arg); } +static void +exit_wait (void) +{ + MIInfo info; + ThreadInfo *thread; + int count; + char response; + info.any.operation = MI_EXIT; + info.any.seqno = seqno++; + info.any.pid = getpid(); + + mi_stop (); + + thread = find_thread (info.any.pid); + + if (mi_write (thread->outfd, &info, sizeof (MIInfo))) + /* Wait for a response before really exiting + */ + while (1) { + count = read (thread->outfd, &response, 1); + if (count >= 0 || errno != EINTR) + break; + } + + close (thread->outfd); + thread->pid = 0; + release_thread (thread); +} + +/* Because _exit() isn't interposable in recent versions of + * GNU libc, we can't depend on this, and instead use the less-good + * atexit_trap() below. But we leave this here just in case we + * are using an old version of libc where _exit() is interposable, + * so we can trap a wider range of exit conditions + */ void _exit (int status) { if (initialized <= 0) - abort_unitialized ("exit"); + abort_unitialized ("_exit"); - MI_DEBUG (("Exiting\n")); + MI_DEBUG (("_Exiting\n")); if (tracing) { - MIInfo info; - ThreadInfo *thread; - int count; - char response; - info.any.operation = MI_EXIT; - info.any.seqno = seqno++; - info.any.pid = getpid(); - - mi_stop (); - - thread = find_thread (info.any.pid); - - if (mi_write (thread->outfd, &info, sizeof (MIInfo))) - /* Wait for a response before really exiting - */ - while (1) { - count = read (thread->outfd, &response, 1); - if (count >= 0 || errno != EINTR) - break; - } - - close (thread->outfd); - thread->pid = 0; - release_thread (thread); + exit_wait (); + tracing = 0; } (*old__exit) (status); +} + +static void +atexit_trap (void) +{ + if (tracing) { + exit_wait (); + tracing = 0; + } } static void construct () __attribute__ ((constructor)); --=-X18BTMzPM8gs3oH5OM6c-- From timprepscius@hotmail.com Mon Sep 15 11:33:05 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from hotmail.com (bay2-dav41.bay2.hotmail.com [65.54.246.98]) by mail.gnome.org (Postfix) with ESMTP id 272641867B for ; Mon, 15 Sep 2003 11:33:05 -0400 (EDT) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 15 Sep 2003 08:33:14 -0700 Received: from 128.186.229.30 by bay2-dav41.bay2.hotmail.com with DAV; Mon, 15 Sep 2003 15:33:14 +0000 X-Originating-IP: [128.186.229.30] X-Originating-Email: [timprepscius@hotmail.com] From: "Timothy Prepscius" To: Subject: memprof without X Date: Mon, 15 Sep 2003 11:35:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01C37B7D.6B5A14E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4922.1500 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Message-ID: X-OriginalArrivalTime: 15 Sep 2003 15:33:14.0573 (UTC) FILETIME=[ADB2C7D0:01C37B9E] Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: This is a multi-part message in MIME format. ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've been messing with memprof trying to remove the GUI and have it run = when no X display is available, printing out information every X = seconds. I have successfully been able to get it to run without a gui. However = when it initializes the gnome/gtk? libraries it uses for pipes/sockets, = I guess it also continues to try to connect to a display even when there = is no need for one. Has anyone done this before? Is it appropriate to post a code archive set to this mailing group? thanks, tim ------=_NextPart_000_0012_01C37B7D.6B5A14E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I've been messing with memprof trying = to remove the=20 GUI and have it run when no X display is available, printing out = information=20 every X seconds.
 
I have successfully been able to get it = to run=20 without a gui.  However when it initializes the gnome/gtk? = libraries it=20 uses for pipes/sockets, I guess it also continues to try to connect = to a=20 display even when there is no need for one.
 
Has anyone done this = before?
 
Is it appropriate to post a code = archive set to=20 this mailing group?
 
thanks,
 
tim
------=_NextPart_000_0012_01C37B7D.6B5A14E0-- From otaylor@redhat.com Mon Sep 15 11:51:22 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 05B8818516 for ; Mon, 15 Sep 2003 11:51:22 -0400 (EDT) Received: from poincare.devel.redhat.com (poincare.devel.redhat.com [172.16.58.30]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8FFpTk27965; Mon, 15 Sep 2003 11:51:29 -0400 Subject: Re: memprof without X From: Owen Taylor To: Timothy Prepscius Cc: memprof-list@gnome.org In-Reply-To: References: Content-Type: text/plain Message-Id: <1063641089.18549.54.camel@poincare.devel.redhat.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Mon, 15 Sep 2003 11:51:29 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Mon, 2003-09-15 at 14:35, Timothy Prepscius wrote: > I've been messing with memprof trying to remove the GUI and have it > run when no X display is available, printing out information every X > seconds. > > I have successfully been able to get it to run without a gui. However > when it initializes the gnome/gtk? libraries it uses for > pipes/sockets, I guess it also continues to try to connect to a > display even when there is no need for one. > > Has anyone done this before? The very first version of memprof was a non-GUI perl script (though it still used Perl/GTK+ for the mainloop.) gtk_init_check() can be used to check for whether a display is available. However, the use of GNOME libraries inside memprof may make using this harder. You probably can call gtk_init_check() first, and then call gnome_program_init() later if that succeeds... it isn't really "proper" but should work fine except for some unlikely command line combinations. The pipes/socket handling code in memprof shouldn't require any sort of display connection. > Is it appropriate to post a code archive set to this mailing group? Patches against the current code are appropriate here, and better than an entire archive. Regards, Owen From hal@sfc.keio.ac.jp Sat Sep 20 00:33:48 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from dns11.mail.yahoo.co.jp (dns11.mail.yahoo.co.jp [210.81.151.144]) by mail.gnome.org (Postfix) with SMTP id 3B8341843A for ; Sat, 20 Sep 2003 00:33:47 -0400 (EDT) Received: from unknown (HELO YahooBB219017052196.bbtec.net) (tokyohal@219.17.52.196 with plain) by dns11.mail.yahoo.co.jp with SMTP; 20 Sep 2003 04:33:55 -0000 X-Apparently-From: Subject: Profile disappears when process ends From: Harry Tily To: memprof-list@gnome.org Content-Type: text/plain Message-Id: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 Date: Sat, 20 Sep 2003 13:33:19 +0900 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: Hi I'm trying to figure out how to use memprof (isn't there anyone on this list who can use it and has time to write a very brief manual?) I've managed to get my process running and generate its profile and leak information, but as soon as the process ends, all that data vanishes again. This only gives me a few seconds to look at the output and try to work out what's happening. How do I keep the information on screen? Thanks! Harry From otaylor@redhat.com Sat Sep 20 08:56:07 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 4BADD1837A for ; Sat, 20 Sep 2003 08:56:07 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KCuEk26257; Sat, 20 Sep 2003 08:56:14 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> Content-Type: text/plain Message-Id: <1064062522.12135.0.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 08:55:23 -0400 Content-Transfer-Encoding: 7bit Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > Hi > > I'm trying to figure out how to use memprof (isn't there anyone on this > list who can use it and has time to write a very brief manual?) I've > managed to get my process running and generate its profile and leak > information, but as soon as the process ends, all that data vanishes > again. This only gives me a few seconds to look at the output and try to > work out what's happening. How do I keep the information on screen? With recent versions of glibc, the code in memprof to keep the child from exiting stopped working. I haven't tracked the problem down ... what you can do is simply put a sleep(3600) at the end of your main routine. Regards, Owen From otaylor@redhat.com Sat Sep 20 10:55:42 2003 Return-Path: Delivered-To: memprof-list@gnome.org Received: from lacrosse.corp.redhat.com (pix-525-pool.redhat.com [66.187.233.200]) by mail.gnome.org (Postfix) with ESMTP id 1043B189D8 for ; Sat, 20 Sep 2003 10:55:42 -0400 (EDT) Received: from vpn50-13.rdu.redhat.com (vpn50-13.rdu.redhat.com [172.16.50.13]) by lacrosse.corp.redhat.com (8.11.6/8.9.3) with ESMTP id h8KEtmk04440; Sat, 20 Sep 2003 10:55:49 -0400 Subject: Re: Profile disappears when process ends From: Owen Taylor To: Harry Tily Cc: memprof-list@gnome.org In-Reply-To: <1064062522.12135.0.camel@localhost.localdomain> References: <1064032396.1125.7.camel@yahoobb219017052196.bbtec.net> <1064062522.12135.0.camel@localhost.localdomain> Content-Type: multipart/mixed; boundary="=-X18BTMzPM8gs3oH5OM6c" Message-Id: <1064069696.12135.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.4 (1.4.4-3) Date: Sat, 20 Sep 2003 10:54:56 -0400 Sender: memprof-list-admin@gnome.org Errors-To: memprof-list-admin@gnome.org X-BeenThere: memprof-list@gnome.org X-Loop: memprof-list@gnome.org X-Mailman-Version: 2.0.12 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: the MemProf memory profiling tool List-Unsubscribe: , List-Archive: --=-X18BTMzPM8gs3oH5OM6c Content-Type: text/plain Content-Transfer-Encoding: 7bit On Sat, 2003-09-20 at 08:55, Owen Taylor wrote: > On Sat, 2003-09-20 at 00:33, Harry Tily wrote: > > Hi > > > > I'm trying to figure out how to use memprof (isn't there anyone on this > > list who can use it and has time to write a very brief manual?) I've > > managed to get my process running and generate its profile and leak > > information, but as soon as the process ends, all that data vanishes > > again. This only gives me a few seconds to look at the output and try to > > work out what's happening. How do I keep the information on screen? > > With recent versions of glibc, the code in memprof to keep the child > from exiting stopped working. I haven't tracked the problem down ... > what you can do is simply put a sleep(3600) at the end of your > main routine. Just put a fix/workaround for this into CVS: Sat Sep 20 10:52:06 2003 Owen Taylor * intercept.c): Switch to atexit() as the primary means of intercepting exiting. It isn't as good as interposing _exit, but interposing _exit doesn't work with newer versions of GNU libc. Regards, Owen --=-X18BTMzPM8gs3oH5OM6c Content-Disposition: attachment; filename=exit.patch Content-Type: text/x-patch; name=exit.patch; charset=UTF-8 Content-Transfer-Encoding: 7bit Index: intercept.c =================================================================== RCS file: /cvs/gnome/memprof/intercept.c,v retrieving revision 1.1 retrieving revision 1.2 diff -u -p -r1.1 -r1.2 --- intercept.c 5 Sep 2002 19:16:38 -0000 1.1 +++ intercept.c 20 Sep 2003 14:54:16 -0000 1.2 @@ -55,6 +55,7 @@ typedef struct { static void new_process (ThreadInfo *thread, pid_t old_pid, MIOperation operation); +static void atexit_trap (void); static int (*old_execve) (const char *filename, char *const argv[], @@ -76,7 +77,7 @@ static ThreadInfo threads[MAX_THREADS]; static char *socket_path = NULL; static unsigned int seqno = 0; -#undef ENABLE_DEBUG +#define ENABLE_DEBUG #ifdef ENABLE_DEBUG #define MI_DEBUG(arg) mi_debug arg @@ -170,6 +171,8 @@ initialize () old_clone = dlsym(RTLD_NEXT, "__clone"); old__exit = dlsym(RTLD_NEXT, "_exit"); + atexit (atexit_trap); + mi_init (); initialized = 1; } @@ -470,42 +473,64 @@ int clone (int (*fn) (void *arg), return __clone (fn, child_stack, flags, arg); } +static void +exit_wait (void) +{ + MIInfo info; + ThreadInfo *thread; + int count; + char response; + info.any.operation = MI_EXIT; + info.any.seqno = seqno++; + info.any.pid = getpid(); + + mi_stop (); + + thread = find_thread (info.any.pid); + + if (mi_write (thread->outfd, &info, sizeof (MIInfo))) + /* Wait for a response before really exiting + */ + while (1) { + count = read (thread->outfd, &response, 1); + if (count >= 0 || errno != EINTR) + break; + } + + close (thread->outfd); + thread->pid = 0; + release_thread (thread); +} + +/* Because _exit() isn't interposable in recent versions of + * GNU libc, we can't depend on this, and instead use the less-good + * atexit_trap() below. But we leave this here just in case we + * are using an old version of libc where _exit() is interposable, + * so we can trap a wider range of exit conditions + */ void _exit (int status) { if (initialized <= 0) - abort_unitialized ("exit"); + abort_unitialized ("_exit"); - MI_DEBUG (("Exiting\n")); + MI_DEBUG (("_Exiting\n")); if (tracing) { - MIInfo info; - ThreadInfo *thread; - int count; - char response; - info.any.operation = MI_EXIT; - info.any.seqno = seqno++; - info.any.pid = getpid(); - - mi_stop (); - - thread = find_thread (info.any.pid); - - if (mi_write (thread->outfd, &info, sizeof (MIInfo))) - /* Wait for a response before really exiting - */ - while (1) { - count = read (thread->outfd, &response, 1); - if (count >= 0 || errno != EINTR) - break; - } - - close (thread->outfd); - thread->pid = 0; - release_thread (thread); + exit_wait (); + tracing = 0; } (*old__exit) (status); +} + +static void +atexit_trap (void) +{ + if (tracing) { + exit_wait (); + tracing = 0; + } } static void construct () __attribute__ ((constructor)); --=-X18BTMzPM8gs3oH5OM6c--