Re: memprof problem (backtrace)
I think I've tracked down where the hang is occurring, using memprof
with glibc 2.3.5 on Linux 2.6.13.4 (though I don't undestand _why_
it's occurring).
The do_malloc function in memprof's libmemintercept calls
mi_call_with_backtrace(), which in turns calls the glibc function
backtrace(), and backtrace is not returning.
Below is a commented version of the code, in stack-frame.c: does
this suggest anything?
void
mi_call_with_backtrace (int to_skip,
void callback (int, void **, void *),
void *data)
{
int bufsiz = 128, count;
size_t sz = bufsiz * sizeof (void *);
void **buf;
again:
buf = alloca (sz);
fprintf(stderr, mi_call_with_backtrace:
alloca(%d) called, buf = %p\n,
(int) sz, (void *) buf);
/* the line above produces sensible-looking results */
fprintf(stderr, calling backtrace on buf\n);
/* the line above is printing OK */
count = backtrace (buf, bufsiz);
fprintf(stderr, count = %d\n, count);
/* ... but we never get to here! */
if (count == bufsiz)
{
bufsiz = bufsiz * 2;
goto again;
}
callback (count - to_skip, buf + to_skip, data);
}
Allin Cottrell
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memprof problem
Allin Cottrell wrote: I've successfully used memprof for leak-checking my app in the past, but on trying it recently something odd happens: memprof starts up OK, and it also starts up the target program, but the target program is not visible (doesn't appear on screen) and memprof records no memory usage. I'm not sure if memprof is still actively maintained. A good alternative is 'valgrind'. regards, Olivier ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memprof problem
On Tue, 25 Oct 2005, Olivier Sessink wrote: Allin Cottrell wrote: I've successfully used memprof for leak-checking my app in the past, but on trying it recently something odd happens: memprof starts up OK, and it also starts up the target program, but the target program is not visible (doesn't appear on screen) and memprof records no memory usage. I'm not sure if memprof is still actively maintained. A good alternative is 'valgrind'. Valgrind is excellent, but I liked memprof for checking gui programs in real time. It was nice and easy to open and close a window, say, and get immediate feedback on whether that operation leaked memory. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
memprof problem
I've successfully used memprof for leak-checking my app in the past, but on trying it recently something odd happens: memprof starts up OK, and it also starts up the target program, but the target program is not visible (doesn't appear on screen) and memprof records no memory usage. I tried this with various standard gnome apps as well as my own program, with the same (non-) result. I then tried rebuilding memprof (0.5.1) with the current Debian patches for compilation against current binutils (GNU binutils 2.16.1). Still nothing. Any ideas what could be happening here? Thanks. (All I see on stderr is memintercept (449): _MEMPROF_SOCKET = /tmp/memprof.uTNjuX memintercept (449): New process, operation = NEW, old_pid = 0 ) -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memprof problem
Allin Cottrell wrote: I've successfully used memprof for leak-checking my app in the past, but on trying it recently something odd happens: memprof starts up OK, and it also starts up the target program, but the target program is not visible (doesn't appear on screen) and memprof records no memory usage. I tried this with various standard gnome apps as well as my own program, with the same (non-) result. I then tried rebuilding memprof (0.5.1) with the current Debian patches for compilation against current binutils (GNU binutils 2.16.1). Still nothing. Any ideas what could be happening here? Thanks. (All I see on stderr is memintercept (449): _MEMPROF_SOCKET = /tmp/memprof.uTNjuX memintercept (449): New process, operation = NEW, old_pid = 0 ) Any chance this could be either a) some sort of incompatibility by standard system components, like libc b) a problem of insufficient execution permissions? Try as root. You could also try to utilize strace to get an idea whether any stupid and unreported ENOFILE error (or similar) cumbers memproof execution. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: memprof problem
On Mon, 24 Oct 2005, Gus Koppel wrote: Allin Cottrell wrote: I've successfully used memprof for leak-checking my app in the past, but on trying it recently something odd happens: memprof starts up OK, and it also starts up the target program, but the target program is not visible (doesn't appear on screen) and memprof records no memory usage. Any chance this could be either a) some sort of incompatibility by standard system components, like libc Could be -- it's quite a while since I ran memprof successfully and I may have updated libc since then (I'm using glibc 2.3.5). b) a problem of insufficient execution permissions? Try as root. I just tried that and it made no difference. You could also try to utilize strace to get an idea whether any stupid and unreported ENOFILE error (or similar) cumbers memproof execution. Tried that too: I couldn't see any obvious error conditions. The trace ends with a lot of poll and gettimeofday calls. The strange thing is that the target app appears to be running OK when started via memprof (I can see its PID with ps): it's just not visible, as if its execution has somehow got hung up. -- Allin Cottrell Department of Economics Wake Forest University, NC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
