RE: cvs2svn: coredump

you are right! Running python ... import anydbm ...
===> produces the same core dump as cvs2svn


Unfortunately I can't run the run-tests as you indicated
(svbowil.flur.zuerich.ch:cvs) $ pwd
/usr/local/lib/python2.6/site-packages/cvs2svn_rcsparse
(svbowil.flur.zuerich.ch:xroot#) ./run-tests.py
ksh: ./run-tests.py: cannot execute
(svbowil.flur.zuerich.ch:xroot#) ls -alF
total 144
drwxr-xr-x   2 bin      bin          512 Jul  9 12:58 ./
drwxr-xr-x   4 bin      bin          512 Jul  9 12:45 ../
-rw-r--r--   1 bin      bin          704 Jul 17  2011 __init__.py
-rw-r--r--   1 root     dba          668 Jul  9 12:58 __init__.pyc
-rw-r--r--   1 bin      bin         8220 Jul 17  2011 common.py
-rw-r--r--   1 root     dba        10417 Jul  9 12:58 common.pyc
-rw-r--r--   1 bin      bin         3273 Jul 17  2011 debug.py
-rw-r--r--   1 bin      bin         5963 Jul 17  2011 debug.pyc
-rw-r--r--   1 bin      bin         4608 Jul 17  2011 default.py
-rw-r--r--   1 root     dba         3508 Jul  9 12:58 default.pyc
-rw-r--r--   1 bin      bin         2246 Jul 17  2011 parse_rcs_file.py
-rw-r--r--   1 bin      bin         2559 Jul 17  2011 parse_rcs_file.pyc
-rw-r--r--   1 bin      bin         2216 Jul 17  2011 run-tests.py
-rw-r--r--   1 bin      bin         1483 Jul 17  2011 run-tests.pyc
-rw-r--r--   1 bin      bin        10488 Jul 17  2011 texttools.py
-rw-r--r--   1 root     dba         6775 Jul  9 12:58 texttools.pyc

running "perl run-tests.py" does just return the prompt without any output
===> would be happy to run these tests


running cvs2svn with the --use-cvs option works for a small amount of data
I have to do further testing

running cvs2svn with the --use-rcs option seems not to be installed
(svbowil.flur.zuerich.ch:cvs) $ cvs2svn --use-rcs ...
ERROR: error executing co: [Errno 2] No such file or directory
Please check that co is installed and in your PATH
(it is a part of the RCS software).


Can you please explain me the secrets of the database modules.
Which SW brings them in the system?
How can they be configured and tested?

Hope to get some additional input. Thank you.

Brigitte


-----Original Message-----
From: Michael Haggerty [mailto:[email protected]]
Sent: Montag, 9. Juli 2012 14:01
To: Widmer, Brigitte
Cc: [email protected]
Subject: 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/



UBS reserves the right to retain all messages. Messages are protected and accessed only in legally justified cases.
Deutsch/Francais/Italiano: http://www.ubs.com/1/e/index/legalinfo2/privacy.html.

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

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