Random Exceptions while Zipping

[ECDL]

I had reported this bug before, but after upgrading to 3.03b7, I'm still getting it, so I thought I bring it up again.

When creating a new zip archive with a list of files, I occasionally get the following exception: "Access violation at address 02FC1015. Write of address 77D44D3B". Although I realize that this information is just about useless from a debugging standpoint.

My environment is a bit unique (a Delphi application that runs Java scripts via Windows Scripting Host; the script in turn instantiates a COM object that is internal to the host Delphi application, which actually contains the VclZip code)--however...a) all of the 3 dozen other such COM objects work fine, and b) the COM object that contains VclZip works fine 99% of the time.

I have tried everything I know how to try an identify anything this is unique about the times when the exception occurs, but I can not find anything (the same Java script, zipping the same kind of files from the same place--sometimes it just fails; also, the number of files in the zip list is meaningless: 3 files or 3000, the results are the same).

So my question is, does VclZip support any kind of internal debug trace or undocumented callback that would help me isolate the exception? Since my app essentially turns over control to VclZip once "Zip" is called, I have no visibility into what's happening internally. Debugging in the traditional way is useless in this case, since the exception happens so rarely. But having a text file that is written each time Zip is called that logged the internal steps of VclZip could prove useful. If this isn't currently supported, would you consider adding it? If not, can you think of a way I could add this functionality without getting deep into your source code? (I'm generally against modifying source code of a "live and evolving" package--once I do that, I essentially have a bastard child that I have to maintain thereafter).

Tnx!

[Kevin]

I'm not sure, would one of VCLZip's events work for you? Like OnBeginZipInfo or something like that? Could you put your code to write out information from the OnBeginZipInfo, OnStartZip, OnEndZip, and OnZipComplete event methods?

Kevin

[ECDL]

I considered those events, but I'm afraid that they would only tell me what file VclZip was working on when the exception occurred. Based on the results I've seen to-date, it's not file related. So I think for it to be meaningful, I would need a more detailed level of trace. At a minimum, what internal function/procedure or major code block VclZip was executing.

[ECDL]

Here's the code (very simply) that I use to create the zip archive. Do you see anything strange? Or any properties that I should be setting that I'm not? (TVCLZip is created dynamically, so anything I'm not setting here remains at its default).

with Zip1 do begin
ClearZip;

ZipAction := zaReplace;
Recurse := False;
Dispose := False;
StorePaths := False;
StoreVolumes := False;

ZipName := szWorkFile;
TempPath := ExtractFilePath(szWorkDir);
Password := szPassword;
PackLevel := iFactor;

ZipComment := szComment;

NoCompressList.Clear;
NoCompressList.AddStrings(gslNoCompressList);

FilesList.Clear;
FilesList.AddStrings(slFileList);

OnFilePercentDone := pCallback;

iCount := Zip;
end;

[Kevin]

Off hand I do not see anything strange about your code. I guess it is probably correct if it works 99% of the time.

What sort of things do you put in the FilesList? Are they wildcards or straight filenames?

Are the drives all network drives? UNC paths?

What version of Delphi/BCB are you using?

Any chance you might every once in awhile running into a reentrant code problem? A single instance of VCLZip can't be performing two zip operations at once. It's ok for multiple instances of VCLZip, just not the same instance.

Anything else you can think of that might be relevant?

[Kevin]

Oh, one other thing to consider. Adding code to those events might at least tell you if it is always happening at any certain point in the zip process. Just a thought.

How often does this happen? I mean daily, weekly, monthly?

[ECDL]

Answers:
1) Straight filenames

2) UNC paths

3) Delphi 5

4) Should not be possible; each script runs in its own thread and each thread has its own instance of the components it uses (including VclZip)

5) Each time the script runs, it creates a new instance of the COM object that contains VclZip (which in turn creates a new instance of TVCLZip); when it fails, the script terminates, which destroys the COM object and the TVCLZip instance; next time the script runs, it usually works fine; I have not tried (nor can I easily) to run a second Zip operation on the same TVCLZip instance to see if it fails consistently after the first failure. I use VclZip in two other programs, and neither of them have ever exhibited this behavior; neither of them use VclZip in a COM object, but for the life of me, I can't figure out why that would make any difference. The only other difference is that both of the other programs instantiate TVclZip on the main form and run it from the main thread, while the COM program instantiates it dynamically and runs it in a separate thread.

6) It happens every few days (the script in question runs about 28 times a day every day, so I'd say it fails once in 50 to 60 runs, but this is certainly not consistent)

[Kevin]

I don't THINK it would have anything to do with being created dynamically. I know that is done all the time so I would be surprised but anything is possible.

A few more questions for more information...

1) What are you putting into the NoCompressList?
2) Is the tempdir on the same disk as the archive being created/added to?
3) Is this always a case of adding to an existing zip file, or creating a new zip file, or what?
4) I assume two instances of VCLZip can't be adding to the same zip file at the same time? - just throwing out any ideas here :-)

[ECDL]

Answers:
1) NoCompressList contains:
Add('*.AVI');
Add('*.GIF');
Add('*.JPG');
Add('*.MP3');
Add('*.RA');
Add('*.TIF');
Add('*.VAP');
Add('*.VOX');
Add('*.WAV');
Add('*.ZIP');
However, the files that this script is zipping are always ".PDF" files.

2) Yes; same folder. The folder is unique and created fresh each time the script runs. And unless VclZip uses the same algorithm that I do to create unique 16-character filenames, a collision is very unlikely...

3) Always creating a new zip file. The name of the zip file is unique (a 16-character time-based name that is guaranteed to be unique on the system that created it).

4) No; two reasons: 1) the script is guaranteed to never run two instances at once; and 2) even if it did, the name of the zip file would be unique (see #3).

[MikeM]

I get exceptions of same nature, but also get "seek error","Stream read error" and the event log on the client where Zip is running indicates lost delayed writes - basically the file server is under stress. To overcome am attempting to make the next passes correct by finishing off the work of Zipping.

[Kevin]

>> To overcome am attempting to make the next passes correct by finishing off the work of Zipping.

I'm not sure I know what you mean by this, can you elaborate?

Thanks,

Kevin