Application in wrong cwd after exec

[cross-cisco]

It appears #247 isn't my problem, as I have that fix in my system. However, I have a perl script that is a front-end to a java application. The java application needs to have the right working directory, but when running the perl starter with Devel::Cover with a -dir, it starts in the argument given to -dir.

I see a chdir in _report, but that looks like it chdir's back at the end, so I'm not sure where to look. One thing I do note when strace'ing the script, is that it will chdir($Dir), then later the execve() happens without another chdir(). Shortly before the execve, I do see

16:15:40.855644 openat(AT_FDCWD, "$Dir/cover_db/structure/0780fcdf457e353fae14a633608eb9f9.lock", O_RDWR|O_CREAT|O_APPEND|O_CLOEXEC, 0666) = -1 EACCES (Permission denied)
16:15:41.116324 rt_sigaction(SIGFPE, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f78584db3b0}, {sa_handler=SIG_IGN, sa_mask=[FPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f78584db3b0}, 8) = 0
16:15:41.116457 execve("/bin/sh", ["sh", "-c", "/var/thing/vms/jre/bin"...], 0x5643f675d030 /* 18 vars */) = 0

I'm wondering if the permission error on the lock file there may be preventing the chdir() back to the right cwd?

[cross-cisco]

Additional question that might be helpful, how are the md5's (or whatever) generated? Another problem I fear is that we're missing coverage data because of conflicts like the above. @pjcj is there docs on that, or a pointer to where in the code? If they're random, then we could try again if we hit a conflict.

[grooverdan]

It looks like $Dir shoudl have been string expanded before it hit the IO functions.

[cross-cisco]

Thank you for looking, @grooverdan, but I'm not sure how to interpret that. $Dir is only used once in _report in the chdir. If you can explain what might correct the problem, I can test it in my reproduction.

[grooverdan]

I looked closer, and its beyond my simple perl knowledge.

[cross-cisco]

Thanks for looking. I'm not sure if @pjcj is active any more.