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?
-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
