in reply to Re^2: rmtree() is failing after some time
in thread rmtree() is failing after some time

See strace/truss. It's a runtime call monitor for Perl, to find out where the problem is.

failed to fetch initial working directory

Is this the exact error message you get? I have a feeling that it's an issue with threading (you didn't mention in your post you use threads). Maybe you should post more code so we can take a look at it.

  • Comment on Re^3: rmtree() is failing after some time

Replies are listed 'Best First'.
Re^4: rmtree() is failing after some time
by KristinaBurden (Initiate) on Apr 23, 2009 at 13:34 UTC
    I am calling rmtree() in DESTROY() method of a class. Here is the exact error message Thu Apr 23 18:08:24 2009 - WARN: cannot fetch initial working directory: No such file or directory at Basecamp/Setup.pm line 265 thread 6 Code is scattered in different files so I am not able to post more code.
[reply]

      Code is scattered in different files so I am not able to post more code

      Sure you can, or is it secret code;)

      Without code it's a bit hard/impossible to diagnose the problem correctly. My guess right now is that in some thread some piece of code tries to access a directory which has just been deleted by the rmtree in another thread?!

[reply]
Re^4: rmtree() is failing after some time
by KristinaBurden (Initiate) on Apr 23, 2009 at 13:51 UTC
    Thu Apr 23 18:02:04 2009 - WARN: cannot fetch initial working directory: No such file or directory at Basecamp/Setup.pm line 265 thread 8
    This is the exact error message that I get.

    Actually my code is scattered in many files, so I am not able to post more code.
    I am calling rmtree() in DESTROY() method of a class.
[reply]
      I am calling rmtree() in DESTROY() method of a class

      The error is due to the fact that the code is unable to stat the directory in question. Is the path canonical or relative? If it's relative, is your code's working directory where you think it is? Can you prove it (print getcwd)?

      How are you generating your temp names? Could two threads create the same name?

      In general, putting resource teardown code beyond closing a socket or the like in a DESTROY handler is a bit weird. I think you'll need to solve this with another a level of indirection. You have to go up a level and ask some parent code to clean up afterwards.

      • another intruder with the mooring in the heart of the Perl

[reply]
        In general, putting resource teardown code beyond closing a socket or the like in a DESTROY handler is a bit weird.

        I have to disagree. If I have resource creation in new or other constructor, I often put cleanup of that resource in DESTROY. If the resource is managed by the object, shouldn't the object do the cleanup?

        I guess my C++ background shows here. I see putting the cleanup code in DESTROY as serving to hide those implementation details from the caller of my object. It also tends to reduce the need for cleanup code to be repeated everywhere the object is used (DRY principle).

        G. Wade
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom