Thanks Paul! (1) Yes, we do send SIGKILL (9) to kill the parent process even the child processes are still running and our purpose is to have a clean kill from "root", so, do you think send SIGKILL (2) will be better? or, we could consider to send SIGKILL (2) to kill all the child processes before send SIGKILL (2) to kill parent process, do you think this may help?
(2) "Maybe you could send it something a little nicer which might allow to process to clean up.", any more detail suggestion and example will be appreciated! (3) We might also consider to give some sleep time before destroy the test object, which causes process killing and cleaning up, but, is there a way we can know Devel::Cover has doen its work to write data? (4) "Devel::Cover does its work in the very last END block.", does this mean that Devel::Cover will not write data until the main test process run to its end? For example, a perl test script loads the perl module that is under testing and excise the functions in that module, sometime the test script needs use "system" to call some other perl scripts (that also is under testing), Devel::Cover will not write data until the main test script reach its end point or exit? (5) Is there a way we can tell which data files (under structure folder?) have been corrupted? We are trying to integrate Devel::Cover into our regular test driven development process, to make Devel::Cover, the amazing code coverage tool in Perl world, work correctly with our test to improve the data accuracy is very critial for us to move forward with the code coverage tool. Thanks a lot for your kind helps! Scott --- Paul Johnson <[EMAIL PROTECTED]> wrote: > On Fri, Jul 07, 2006 at 10:26:13AM -0700, Scott Wang > wrote: > > > Hi Paul, > > > > Even, currently, there is no any zero size data > file > > in structure folder in my regression code coverage > run > > (lots of suites), I still got lots of messages > like > > below: > > ----------- > > Corrupted storable file (binary v2.7) at > > ../../lib/Storable.pm (autosplit into > > ../../lib/auto/Storable/_retrieve.al) line 331, at > > /xxxxxxxx/Devel/Cover/DB/Structure.pm line 269 > > END failed--call queue aborted. > > ------------- > > Seems some data files got corrupted somehow. > > > > The process killing (kill parent process before > > killing child process and make chid process be > > terminated abnormally) is one possibility, I also > > noticed that useing system or other folk method to > > execute command could also cause this problem. > > > > Any clue about above issue "Corrupted storable > file > > (binary v2.7) at ..." and does anybody also > experience > > this issue and know how to deal with it? > > > > Also, does anybody have similar experience on > killing > > process and folking process cause "Magic number > ..." > > issue and "orrupted storable file ..." issue? > > In lieu of discussing either licences or alligators, > let me try to > answer this. > > Killing the process sounds like the most likely > cause of this problem. > If you manage to kill the process while it is > writing out a storable file > the file will very probably be corrupted. > > How are you killing the process? Are you sending it > SIGKILL (9) for > example? Maybe you could send it something a little > nicer which might > allow to process to clean up. > > Devel::Cover does its work in the very last END > block. You really need > to let it run to completion. > > -- > Paul Johnson - [EMAIL PROTECTED] > http://www.pjcj.net > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
