Compiled script crashes with latest version compiled only

[Phil Pendlebury]

This is since compiling with version 10.1.20

The script itself may not be perfect but it worked perfectly until compiling with the latest version.

If it is run from within MS it runs fine.

If it is run from compiled version it hangs and must be closed manually THEN if run again it works fine.

The crash happens when hitting the TRASH 'EM! button. (Which basically deletes temporary files from two main temp folders).

My system is Vista 64.

Please check before I have to reinstall older version to compile.

Here is the script:

Code: Select all

APP_TITLE=Trash 'em!
Let>MSG_STAYONTOP=1
Let>MSG_CENTERED=1
Let>MSG_WIDTH=350
Let>MSG_HEIGHT=220
Let>WF_TYPE=1
Let>VAREXPLICIT=0
// start
Let>GFL_TYPE=1
GetFileList>%TEMP_DIR%\*.*,tufolders
GetFileList>%WIN_DIR%\Temp\*.*,twfolders
Let>GFL_TYPE=0
GetFileList>%TEMP_DIR%\*.*,tufiles
GetFileList>%WIN_DIR%\Temp\*.*,twfiles

Seperate>tufolders,;,tufoldernames
Seperate>twfolders,;,twfoldernames
Seperate>tufiles,;,tufilenames
Seperate>twfiles,;,twfilenames

Dialog>dialog1
   Caption=Trash 'em!
   Width=370
   Height=240
   Top=CENTER
   Left=CENTER
   Max=0
   Min=0
   Close=0
   Resize=0
   Label=Trash Em! by Phil Pendlebury.,8,8,true
   Button=QUIT,8,168,105,33,1,,Do nothing
   Button=TRASH 'EM!,248,168,107,33,2,,Delete all temporary files and folders
   Label=%TEMP_DIR%*.*,64,40,true
   Label=%WIN_DIR%\Temp\*.*,64,104,true
   Label=%tufilenames_count% files,64,72,true
   Label=%tufoldernames_count% folders,64,56,true
   Label=%twfilenames_count% files,64,136,true
   Label=%twfoldernames_count% folders,64,120,true
   Button=View,8,40,49,49,7,,View this folder
   Button=View,8,104,49,49,8,,View this folder
   Button=MEAP Web,128,168,105,33,10,,Go to MEAP web site
EndDialog>dialog1

Show dialog1

Label>Dloop
GetDialogAction>dialog1,but
IF>but=1,End
IF>but=2,Delete
IF>but=7,ViewTemp
IF>but=8,ViewWin
IF>but=10,MEAPwww
GOTO>Dloop

Label>Delete
Let>tuf=0
Let>tud=0
Let>twf=0
Let>twd=0

IF>tufilenames_count>0
  Repeat>tuf
  Let>tuf=tuf+1
  DeleteFile>tufilenames_%tuf%
  until>tuf=tufilenames_count
ENDIF

IF>tufoldernames_count>0
  Repeat>tud
  Let>tud=tud+1
  DeleteFile>tufoldernames_%tud%
  until>tud=tufoldernames_count
ENDIF

IF>twfilenames_count>0
  Repeat>twf
  Let>twf=twf+1
  DeleteFile>twfilenames_%twf%
  until>twf=twfilenames_count
ENDIF

IF>twfoldernames_count>0
  Repeat>twd
  Let>twd=twd+1
  DeleteFile>twfoldernames_%twd%
  until>twd=twfoldernames_count
ENDIF

GOTO>End

SRT>ViewTemp
  ExecuteFile>%TEMP_DIR%
  rda>dialog1
END>ViewTemp

SRT>ViewWin
  ExecuteFile>%WIN_DIR%\Temp\
  rda>dialog1
END>ViewWin

SRT>MEAPwww
  ExecuteFile>http://www.meap.biz/
  rda>dialog1
END>MEAPwww

Label>End

Can anyone confirm or suggest why?

Thank you.

[Marcus Tettmar]

I just compiled that with 10.1.20 and it worked fine. No crash or hang. Deleted the files and then exited.

Only thing I'd note is that you do have some very tight loop there, which may give the appearance of a hang. If you have lots of files to delete the script will be very busy as it processes each delete loop. I'd add a tiny wait of say 0.05 seconds inside each Repeat/Until loop.

[Phil Pendlebury]

Hi Marcus,

The things are.

1. It only started happening since compiling with latest version.
2. If I close it manually (task manager) and then start again it runs fine.
3. If I run non-compiled version it runs fine.

[pgriffin]

Phil,

It is not uncommon that a compiled script runs slightly faster than the uncompiled version, so the fact that it only crashes when compiled is not surprising and the suggestion to add very small wait> times makes sense.

Have you tried the wait>.05 suggested and, if so, what are the results?

[Phil Pendlebury]

Hi guys thanks for your suggestions, however I don't think everyone is reading my point properly:

Let me remind you of the two other factors other than compilation:

2. If I close it manually (task manager) and then start again it runs fine.
3. If I run non-compiled version it runs fine.

never mind anyway, it;s not that important, I just thought it may show there is something different or problematic about the behaviour of .20 compared to .19. but if everyone is determined that the problem is with my code then fair enough.

Cheers

[Marcus Tettmar]

Phil,

I don't see a problem with your code - in fact it works fine for me. But I did offer a suggestion as to how to make the script more responsive and less likely to appear locked (you said it was hanging) and since this affects processor usage it COULD be related to your issue. Of course it may NOT have anything to do with it either. But unless you try it how can we know either way?

I don't doubt you're having a problem. But I was unable to replicate. We obviously need more information. In the absence of being able to replicate or any other plausible explanation I am left with looking at possibilities and making suggestions for things to try in a process of elimination, even if they are only small improvements to the code. So far you haven't said whether you have tried my suggestion or not.

There were zero changes to the compiler between 019 and 020. The only change between those two versions was to the UI element - to the Macro Scheduler front end. The fix in 020 was to the hotkey/schedule handling code which does not exist in the compiler. I've just done a diff report between the compiler code of 019 and 020 and it reports zero changes.

So, I don't believe the issue is with 020 specifically. The version number itself must be a red herring.

Are you getting an error message when t hangs? Or is it just becoming unresponsive (it could just be stuck in a very long loop - hence my suggestion to make the loop yield more)? In either case what does a log file reveal? I.e. run the compiled macro with a log file on the command line. When it hangs/crashes, grab the log file and see what line was last executed.

Just trying to help.

[Phil Pendlebury]

Roger that Marcus, will do some more detailed tests and post back. Including adding the suggestions you mentioned.

Thank you for your reply, much appreciated.

[Phil Pendlebury]

Hi again,

Added the delays as suggested.

Very odd. Behaviour is exactly the same.

When running the app for the first time it appears to lock up. In fact it hasn't completely crashed but it takes about 4 minutes to delete 1 folder with about 13 temp files in it.

Throughout this time there seems to be excessive HD activity.

If the app is then run again (after placing more file in temp folder to test), it seems to run fine.

I suppose I must presume this is something peculiar to my system then.

[Rain]

Could it be possible that your spyware, anti virus, firewall or any other app you installed is causing the problem? I've noticed that some of my compiled scripts run better when I add them to the exclusion list. Might be worth trying.

[Phil Pendlebury]

Could it be possible that your spyware, anti virus, firewall or any other app you installed is causing the problem? I've noticed that some of my compiled scripts run better when I add them to the exclusion list. Might be worth trying.

Thanks Rain I will give that a try.

[jpuziano]

Hi Phil,

So you're saying that the exact same code compiled with version 10.1.20 shows the problem, but compiled with version 10.1.19 has no problem... is that right?

Marcus tells us there was very little change between the two versions...

There were zero changes to the compiler between 019 and 020. The only change between those two versions was to the UI element - to the Macro Scheduler front end. The fix in 020 was to the hotkey/schedule handling code which does not exist in the compiler. I've just done a diff report between the compiler code of 019 and 020 and it reports zero changes.

If the compiler itself is identical in versions 19 and 20, then in theory... the generated exe files should also be identical. What I would do is:

• - Compile the exact same code with both 10.1.20 and 10.1.19
  
  - Verify that the problem does exist using one exe but not the other.
  
  - (I take it you've already done the above)
  
  - Test the two exe's on a different computer, same results?
  
  - Do a binary compare on the two executables to see if they are identical.
  
  - If the exe's are *exactly* the same then the only thing that might be different between the two is the filename you've given the exe's... so follow that lead perhaps along Rain's suggestions.
  
  - If the twp exe's are not identical, perhaps the version number is embedded in the exe so that could be why a binary compare finds them not identical. If that's the case, compare with a tool like WinMerge that will point out and highlight the difference between the two. Is the only difference the embedded version number? If so that lets the exe off the hook. If not, well then I'd be asking Marcus what the other differences are for...
  
  - I just compiled a script using 10.1.20, made a copy of it using a different filename, compared the two with WinMerge and of course, it says they are identical. I then searched for "10.1.20" and didn't find it. I searched for "ver" and found a few matches but they're not the version number we're talking about.
  
  - If I had version 10.1.19 here, I compile the same code and compare to the 10.1.20 version... I am curious what differences if any would show up.

Just my two cents... finding odd bugs is interesting... you just never know what you might discover. It may be only specific to your PC so not a big deal or... it may be something that may end up helping us all. I hope you pursue it and get to the bottom of it.

Good luck and take care

[Me_again]

Not addressing the 20 vs 19 issue, but if I had a file delete routine crashing or stalling I would wonder about what happens and how it handles the error when the routine hits a file that's opened or locked by another application (especially running under super picky vista).

[Phil Pendlebury]

Not addressing the 20 vs 19 issue, but if I had a file delete routine crashing or stalling I would wonder about what happens and how it handles the error when the routine hits a file that's opened or locked by another application (especially running under super picky vista).

It was never a problem before. It is not a problem if the program is run once and restarted.

The two files (on my system) that are locked, are simply not deleted. (I did kind of explain above that this app has been running perfectly until I posted - there are always an odd locked file in temp folders - they are impossible to delete).

If it was related to locked files - Why would it differ when runnning a compiled vs non-compiled app?

I have also tried disabling AV btw. No change.

Guys I know my system very, very well. I don't post here a whole lot as I am no expert but I am also not a complete fool. I am reluctant to reinstall an older version at the moment though so I guess you'll have to mark this is unresolved for the time being.

Check my posts. You'll note that I had a similar thread to this a while ago which finally resulted in a bug being found. You'll also note that I posted some stuff which was completely my own mistakes.

[jpuziano]

Hi Phil,

So you're saying that the exact same code compiled with version 10.1.20 shows the problem, but compiled with version 10.1.19 has no problem... is that right?

Marcus tells us there was very little change between the two versions...

There were zero changes to the compiler between 019 and 020. The only change between those two versions was to the UI element - to the Macro Scheduler front end. The fix in 020 was to the hotkey/schedule handling code which does not exist in the compiler. I've just done a diff report between the compiler code of 019 and 020 and it reports zero changes.

If the compiler itself is identical in versions 19 and 20, then in theory... the generated exe files should also be identical.

I don't have Vista, but I was still curious... would the generated exe's be identical or not? These tests were done on XP SP2 but perhaps they will still help. Here's what I did:

• - My home PC was at Macro Scheduler version 10.1.18 so I updated it to 10.1.19
  
  - I compiled Phil's script using 10.1.19 and saved the exe
  
  - I then updated to 10.1.20 and compiled the same script again and saved the exe
  
  - Comparing with WinMerge showed the two exe's were not identical but beyond that it wasn't helpful.
  
  - I updated my copy of UltraCompare Professional to the latest version 6.0 and did a binary fast compare on the two exe's and here are the results:

Code: Select all

First file name: E:\Phil's Script compiled under 10.1.19.exe
Second file name: E:\Phil's Script compiled under 10.1.20.exe

Summary:
```````````````````
379 : 379 Byte(s) diff   661018 Byte(s) match   661397 : 661397 Byte(s) total

Those 379 differing bytes are not all in one area but are peppered in several areas. I was able to produce a difference report which shows the differences. The report is 7.6 Mb of text (I can email it to you if you like) and the bulk of it shows the byte values of lines of the two exe's matching identically... and every once in a while a difference, here's the first two differences for example:

• [ 1 ] E:\Phil's Script compiled under 10.1.19.exe 9/13/2008, 4:41:08 pm
  [ 2 ] E:\Phil's Script compiled under 10.1.20.exe 9/13/2008, 4:44:44 pm
  
  000003e0 [ 1 ] * 55 50 58 21 0C 09 05 09 53 92 40 93 1A AF 86 4F UPX!....S’@“.¯†O
  000003e0 [ 2 ] * 55 50 58 21 0C 09 05 09 43 92 A9 0F 0D B0 60 09 UPX!....C’©..°`.
  
  000003f0 [ 1 ] * D0 47 1C 00 A5 29 09 00 95 9F 1B 00 26 38 00 53 Ã

[Marcus Tettmar]

No - I said a compare of the SOURCE showed no differences.