Re: 1.12.5 pserver core dump pid-11993

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Todd,

The core dump that Mark got was because repository == NULL, so his
strlen(NULL) was generating the core dump before it could calculate the
number o bytes needed by xmalloc().

My guess is that we are running into a condition where the lock->repository
is being set to NULL for some reason and then trying to get the lockname
again which is causing a problem.

There is a fairly significant change in the use of Promotable locks in
the 1.12.5 version of cvs, but I have not tracked down the code path
that could lead to Mark's problem. If anyone else has any spare cycles
to gaze upon the interaction of waiting for a lock and under some
conditions freeing the lock->free_repository which can also cause
lock->repository to be set to NULL, please look there and see if you
have any suggestions for what may be going wrong.

	Thanks,
	-- Mark

Todd Denniston <[email protected]> writes:

> Yep, your getting through. But it is a fun question you ask. 8)
> 
> Mark wrote:
> > 
> > I have tested this. It is repeatable on solaris 2.8. I setup two
> > workareas from the same repo/module and commited at the same time,
> > one proceeded one got the waiting on lock. Once the one waiting on
> > lock gets the lock, it core dumps.
> > 
> > Please take a look at this. Our integration with another tool
> > fails and the integration process is left in a uncertain state of
> > reliability.
> > 
> > cvs 1.12.5 non-root pserver, solaris 2.8, compiled with workshop
> > 6.1, MMAP commented out in config.h
> > 
> > Thanks,
> > 
> > Mark
> 
> From the debuger output showing the death at a (x)malloc, I think we may be
> back to Larry's call that you may be running out of virtual memory.
> 
> you might try your test and with both machines (assuming client is a different
> machine) run something like
> 
> while true;do df -h /tmp ;sleep 1;done
> 
> while at the same time running your test. If the machine drops to very little
> space that is probably the problem.
> 
> BTW, How big is 
> CE-cqtool.lock
> /tmp on your server
> the free space on /tmp on your server
> ram on your server
> free ram on your server
> /cvsroot/baseline/
> the free space on /cvsroot/baseline/
> the free space in the directory where you are doing the checkout.
> 
> 
> 
> > 
> > --- Mark <[email protected]> wrote:
> > >
> > > I have 4 other core files that trace back to the same line of
> > > code, 2 others can confirm happen during a commit that is
> > > waiting
> > > on a lock, to commit one file. No locks needed cleaning up......
> > >
> > > Mark
> > >
> > > --- Mark <[email protected]> wrote:
> > > >
> > > > cvs 1.12.5 non-root pserver, solaris 2.8, workshop 6.1
> > > >
> > > > We had a pserver core dump during a commit. The command and
> > > core
> > > > trace output is below.
> > > >
> > > > Thanks,
> > > >
> > > > Mark
> > > >
> > > >
> > > ================================================================
> > > >
> > > > > cvs commit -m "datarepolockhelp commit" CE-cqtool.lock
> > > > cvs commit: [18:13:07] waiting for cvspserv's lock in
> > > > /cvsroot/baseline/CarApp
> > > > Terminated with fatal signal 11
> > > > Core dumped; preserving /cvstmp/pserver/cvs-serv11993 on
> > > server.
> > > > CVS locks may need cleaning up.
> > > >
> > > >
> > >
> > =============================================================================
> > > >
> > >
> > =============================================================================
> > > > Workshop Stack Trace: (line with arrow marked below)
> > > >
> > >
> > =============================================================================
> > > >
> > >
> > =============================================================================
> > > >    main(argc = 1, argv = 0xffbef360)
> > > >    server(argc = 1, argv = 0xffbef360)
> > > >    serve_ci(arg = 0x1bb3ca "")
> <SNIP>
> > > >    Promotable_Lock(list = 0x1e2008)
> > > >    walklist(list = 0x1e2008, proc = 0x76de8 =
> > > > &`cvs`lock.c`set_promotablelock_proc(Node *p, void *closure),
> > > >  closure = (nil))
> > > >    set_promotablelock_proc(p = 0x1b2e80, closure = (nil))
> > > >    promotable_lock(lock = 0x1b87a8)
> > > >    set_lock(lock = 0x1b87a8, will_wait = 0)
> > > > (ARROW==>)  lock_name(repository = (nil), name = 0x1740f8
> > > > "#cvs.lock")
> > > >    strlen(0x0, 0x0, 0x0, 0x7efefeff, 0x81010100, 0xff1c2ac4)
> > =============================================================================
> > =============================================================================
> > > > Workshop dbx commands
> > > >
> > >
> > =============================================================================
> > > >
> > >
> > =============================================================================
> > > > (dbx) debug cvs /tmp/core
> > > > Reading cvs
> > > > core file header read successfully
> <SNIP>
> > > > program terminated by signal SEGV (no mapping at the fault
> > > > address)
> > > > Current function is lock_name
> > > > (dbx)
> > > >
> > > >
> > > >
> > >
> > =============================================================================
> > > >
> > >
> > =============================================================================
> > > > lock.c code section provided by workshop: (line with arrow
> > > > marked
> > > > below)
> > > >
> > >
> > =============================================================================
> > > >
> > >
> > =============================================================================
> > > > static char *
> > > > lock_name (const char *repository, const char *name)
> > > > {
> > > >     char *retval;
> > > >     const char *p;
> > > >     char *q;
> > > >     const char *short_repos;
> > > >     mode_t save_umask = 0000;
> > > >     int saved_umask = 0;
> > > >
> > > >     TRACE (TRACE_FLOW, "lock_name (%s, %s)", repository,
> > > name);
> > > >
> > > >     if (lock_dir == NULL)
> > > >     {
> > > >         /* This is the easy case.  Because the lock files go
> > > > directly
> > > >            in the repository, no need to create directories or
> > > > anything.  */
> > > > (ARROW==>)        retval = xmalloc (strlen (repository) +
> > > strlen
> > > > (name) + 10);
> > > >         (void) sprintf (retval, "%s/%s", repository, name);
> > > >     }
> > > >     else
> <SNIP>
> -- 
> Todd Denniston
> Crane Division, Naval Surface Warfare Center (NSWC Crane) 
> Harnessing the Power of Technology for the Warfighter
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFABBGw3x41pRYZE/gRAt5iAKCeOA2HG6PNyEzzav0tm/SYmMJaxwCgw6ln
LhpdOwWZTqTwSpnci7oSb6M=
=4Uqe
-----END PGP SIGNATURE-----