On 17 Sep 2004 at 21:22, Jesse Schoch wrote: > As I said, it's very difficult to reproduce, I think the problems stems from > the server crashing, the client(par exe) trying to reconnect via LWP > UserAgent, and then the exe being killed, or having a reboot taking place. > I fixed it by renaming the inc dir in the cache dir, but I had a user have > the problem, and the par would run out of the startup folder, but hang. > Deleting the cache files/rebooting did not fix the problem! I've not been > able to manualy reproduce the problem so it's very difficult to tell what > happened. Is there no verbose flag for the bootstrapping of a par exe?
There is: set PAR_GLOBAL_DEBUG=1 your_app.exe for the par.pl portion, but nothing for the binary frontend. If deleting the cache and re-booting doesn't clear the problem, I really doubt that it's a PAR problem! Some "thing/status" in XP is left over after the crash somewhere. > > -jess > > -----Original Message----- > From: Alan Stewart [mailto:[EMAIL PROTECTED] > Sent: Friday, September 17, 2004 9:11 PM > To: Jesse Schoch; [EMAIL PROTECTED] > Subject: Re: Par locking, death, and purgatory > > On 17 Sep 2004 at 12:31, Jesse Schoch wrote: > > > I've had some strangness in my app for quite a while, the problem was > > seemingly random, and the only way to fix was to reinstall, or install > > a different version of my app. I finaly figured out what is causing > > the problem, and I fear it may be par related. > > > > 1. System reboots, or app hangs/gets killed. > > 2. App tries to start, looks for cache. > > 3. inc directory (win XP) is loocked, par freaks out loops forever. > > > > What I need to do to fix it is to either change the binary (and cache > > folder), or move the inc dir. Windows woln't let me delete it because > > it is locked. Then the app starts up fine. > > > > Any ideas why this is? It is very difficult for me to simulate. Any > > ideas on debugging in a par built exe's early bootstrap stages? > > > > -jess > > > What are you doing when it crashes in the first place? Are you saying that > the system reboots because of the PAR app or something else is unstable? > > PAR doesn't "lock" anything. If XP doesn't let you delete the directory, > it's probably because some DLL is still loaded in memory and has a file in > the cache open, so XP says the dir is in use. A DLL can have a file open > even if the program appears to have gone away / been killed. I have a viewer > that does that to me all the time. I presume that a re-boot after the hang > allows to you delete the cache. > > My guess is that the open file is opened exclusive and that blocks the app > somehow on the second try. You could try deleting the files in the cache one > by one till you get an access denied. Which specific file may give you a > hint to what's got it still open, and may tell us why it would hang a PAR > app. I am also guessing that the hang is not in the PAR binary frontend, but > par.pl or your app code. Try putting a print statement in a BEGIN block at > the front of your app to see if your code actually starts or not. We need to > determine if it's PAR or one of your DLLs that is hanging. You may need to > run without "-g" to see the print. > > Does this happen often enough that you can try these things soon? What are > the "heavy" > Perl modules that you are using in this app? > > Alan Stewart > >
