RE: Core dump during CVS Commit

[Smruti]

Hi Dreek,

Thanks for the mail.
Could you update me how shall I take stack trace from core?

Thanks 
Smruti


-Original Message-
From: Derek Price [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 16, 2005 5:55 PM
To: Smruti
Cc: bug-cvs@gnu.org
Subject: Re: Core dump during CVS Commit


Smruti wrote:

Hi,

I have insttaled CVS 1.11.19 on Solaris 5.8 and have created repository.
CVS is running as Password Auth server and have made necessary changes in
inetd.conf to include follwoing
cvspserver  stream  tcp nowait  cvs /usr/local/bin/cvs
oot -f  --allow-root=/usr/local/cvsroot pserver
and changed /etc/services to include cvspserver  entry.

Now whenever I try to import anything in CVS to create the project, it
always gives me Segementation Fault or cvs import aborted due to abort
signal

FYI:  CVSROOT is set to =/export/home/smruti/temp/cvs
$ cvs -tn import test_cvs test start
 - main loop with CVSROOT=/export/home/smruti/temp/cvs
cvs [import aborted]: received abort signal
 - Lock_Cleanup()

Can anyone help me? Let me know if any other info is required.
  


Can you provide a stack trace from the core?

Derek


*
Disclaimer:
The contents of this E-mail (including the contents of the enclosure(s) or 
attachment(s) if any) are privileged and confidential material of MBT and 
should not be disclosed to, used by or copied in any manner by anyone other 
than the intended addressee(s).   In case you are not the desired addressee, 
you should delete this message and/or re-direct it to the sender.  The views 
expressed in this E-mail message (including the enclosure(s) or attachment(s) 
if any) are those of the individual sender, except where the sender expressly, 
and with authority, states them to be the views of MBT.

This e-mail message including attachment/(s), if any, is believed to be free of 
any virus.  However, it is the responsibility of the recipient to ensure that 
it is virus free and MBT is not responsible for any loss or damage arising in 
any way from its use
  



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: OpenBSD 3.6 sparc64 Build Failure on TRUNK

[Alexander Taler]

  Derek One of the things it does is verify that the requested executable
  Derek exists and that it is a GNU application.  This is what caught us - the
  Derek script was assuming that any GNU program is good and therefore that
  Derek its failure meant a real failure.  I added a new bison wrapper based
  Derek on missing to handle the version check.  Let me know if it doesn't
  Derek work for you.

Should I let you know if it does?  Because it does.
Thanks.

Alex
-- 
https://savannah.gnu.org/projects/libcvs-specAccess CVS through a library.
PGP:  ID: 0x23DC453B  FPR: 42D0 66C2 9FF8 553A 373A  B819 4C34 93BA 23DC 453B
convince your customer that pserver access to a CVS server is, if not
*actually* the work of the devil, then pretty similar -- Derek Price


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: Core dump during CVS Commit

[Derek Price]

Smruti wrote:

Hi Dreek,

Thanks for the mail.
Could you update me how shall I take stack trace from core?
  


Using the GNU debugger (gdb), the command is `bt' (for backtrace). 
Thus, assuming that you were using /usr/bin/cvs and that your core dump
created a file named core.1234 (where 1234 couild be any process id):

$ gdb /usr/bin/cvs core.1234
...assorted gdb bootup output...
(gdb) bt
...SEND THIS OUTPUT...
(gdb)


The commands may be slightly different if you need to use the Solaris
debugger.

The core dump file should have been created in whatever directory you
ran the offending CVS command from.  If it wasn't, you might have to run
the command `ulimit -c unlimited' to enable core dumps.  At least,
that's the command on Linux - I'm not sure that is the same on Solaris
either.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs