Re: cvs2svn: coredump

On 07/09/2012 11:13 AM, [email protected] wrote:
> I'm trying to migrate from cvs to svn using cvs2svn on a
> Solaris-platform. Software used is:
> cvs 1.12.13
> cvs2svn 2.3.0
> python 2.6.2
> PYTHONPATH contains /usr/local/lib:/usr/local/lib/python2.6
> LD_LIBRARYPATH contains /usr/local/lib
> command and options used:
> *cvs2svn* --dumpfile cvsRMITdmp --tmpdir /oracle_backup/cvs --encoding
> ISO-8859-1 --trunk=trunk --branches=branches
> --tags=tags /app/ELA/dyn/pg/cvs-repository/ubs_Sol10/DB_UPS_RW/ctpdbmnt/olu
> After starting succesfully, we get a *coredump* in "pass 16"
> ----- pass 15 (IndexSymbolsPass) -----
> Determining offsets for all symbolic names...
> Done.
> Time for pass15 (IndexSymbolsPass): 0.017 seconds.
> ----- pass 16 (OutputPass) -----
> Starting Subversion Dumpfile.
> Bus Error(coredump)
> At the end of this mail you find a truss of the last steps of the above
> cvs2svn command.
> *QUESTIONS*
> What could be the reason for the coredump?
> Are there any log files I could check to find errors reported?
> Are there any basic checks to verify the correct setup of Python, Python
> with cvs2svn?

It seems like something in your Python setup is screwed up.  I find it 
strange that Python seems to be trying to overwrite 
"/usr/local/lib/python2.6/whichdb.pyc", as if the corresponding 
whichdb.py is newer.  The overwriting fails because of lack of 
permissions.  I would hope that Python is smart enough to deal with this 
situation, but this might be an indication of a problem in the Python 
install.

Then presumably the whichdb module is being used to deduce what kind of 
database was used to store the checkout of the cvs revisions.  whichdb 
uses some heuristics to figure out which database module to use.  I can 
imagine that one of the database modules that it tries is not installed 
correctly--maybe even a different database module than the one that was 
actually used to create the database.  So it might help to make sure 
that the database module that you are *using* is installed correctly, 
and/or that database modules that you are *not using* are deinstalled.

There's a good chance that you will observe the same core dump if you try

     $ python
     >>> import anydbm
     >>> db = anydbm.open('/oracle_backup/cvs/cvs-checkout.db', 'n')

Perhaps this will allow you to conduct your tests more quickly.

You can also run the cvs2svn test suite by running "./run-tests.py" in 
the main cvs2svn directory.

You can also get around using the database at all by using the --use-cvs 
or --use-rcs options instead of the default --use-internal-co.  However, 
the conversion will be slower with either of these options.

Let us know what you find out.

Michael

> [...]
> unlink("/usr/local/lib/python2.6/whichdb.pyc")  Err#13 EACCES
> [file_dac_write]
> open64("/usr/local/lib/python2.6/whichdb.pyc",
> O_WRONLY|O_CREAT|O_TRUNC|O_EXCL, 0100644) Err#17 EEXIST
> llseek(14, 0, SEEK_CUR)                         = 3353
> close(14)                                       = 0
> open64("/oracle_backup/cvs/cvs-checkout.db.pag", O_RDONLY) Err#2 ENOENT
> open64("/oracle_backup/cvs/cvs-checkout.db.db", O_RDONLY) Err#2 ENOENT
> stat64("/oracle_backup/cvs/cvs-checkout.db.dat", 0xFFBFDE10) Err#2 ENOENT
> open64("/oracle_backup/cvs/cvs-checkout.db", O_RDONLY) Err#2 ENOENT
> getpid()                                        = 10417 [10416]
> sysconfig(_CONFIG_NPROC_ONLN)                   = 4
> open64("./DB_CONFIG", O_RDONLY)                 Err#2 ENOENT
> stat64("/var/tmp", 0xFFBFD0C0)                  = 0
> time()                                          = 1341578802
> clock_gettime(4, 0xFFBFD970)                    = 0
> sysconfig(_CONFIG_NPROC_ONLN)                   = 4
>      Incurred fault #5, FLTACCESS  %pc = 0xFEB1C1D4
>        siginfo: SIGBUS BUS_ADRALN addr=0x00598F64
>      Received signal #10, SIGBUS [default]
>        siginfo: SIGBUS BUS_ADRALN addr=0x00598F64


-- 
Michael Haggerty
[email protected]
http://softwareswirl.blogspot.com/

------------------------------------------------------
http://cvs2svn.tigris.org/ds/viewMessage.do?dsForumId=1670&dsMessageId=2980957

To unsubscribe from this discussion, e-mail: [[email protected]].