> From: Branko Čibej [mailto:[email protected]] > > On 02.07.2010 14:14, Daniel Shahaf wrote: > > Edward Ned Harvey wrote on Fri, 2 Jul 2010 at 07:42 -0400: > > > >> We first experienced the problem in production. Clients connecting > via > >> svn:// to svnserver. > >> > >> Since I'm debugging, I'm able to reproduce it on the command line > with svn, > >> using svn:// so there is no server. > >> > >> > > Okay. > > Um, not OK? Either there's a typo in the quoted text above and you're > actually testing with a file:// URL, or you're indeed testing with a > svn:// URL, which explains why you only get a client trace from gprof -
Read the quoted text again. We *first* experienced the problem in production. Using svn:// connecting to a server. Since I'm debugging now, I have been able to reproduce it on the command line with svn, via file:/// (no server.) So while I'm debugging, there is only one executable running. "svn" is using a working copy on local disk and accessing a repository on local disk. So the -pg debugging options and gprof *should* work on this. > I'd also suggest you try a static build, i.e., by passing > --disable-shared --enable-static and CFLAGS=-pg to configure. That > should generate a statically-linked svn binary (except for non-svn > libraries), then make sure you create a new repository and use a > file:// > URL to test your data set. If gprof/oprofile still doesn't trace into > the libraries, then it's time to begin the head-scratching. :) This is where we are today. Please join us in head scratching.
