ObjectDisposedException within a while loop?

Trapper Hell

I have this method that accepts a ZipFile as a parameter and does some work etc, but after looping within a while loop, the parameter (ZipFile) is disposed... I will show a quick example instead of the original code because it would be unnecessarily complex.

private byte[] GetImage(ZipFile originalZipFile, string pass)
{
while(true) // Here is a condition that loops for some time, according to a specified number
{
ZipFile zipFile = originalZipFile // <- Exception occurs here, after the 2nd loop (originalZipFile is somehow disposed)
foreach(ZipEntry zEntry in zipFile)
{
if(true) // If the condition is met, the object is returned
return new byte[];
}
}
}

I have attempted to keep the example simple enough.. So, zipFile is closed and set to null within the while loop, even before the return (else an exception occurs, since the ZipFile is using a FileStream which is later needed). However, originalZipFile is for some reason being disposed without any calling directly accessing it :mad: (that is why originalZipFile is copied into zipFile) What can I do in order to keep originalZipFile from being disposed? Or what am I doing wrong? Thanks! (As far as I am concerned, ZipFile is a class not a struct, so there shouldn't be any problems, with multiple references to the same 'object' on the stack).

Gideon Engelberth

If ZipFile is a class and not a struct, then you are not making a copy of originalZipFile when you assign it to zipFile, only a copy of the reference. So anything you do to zipFile is done to originalZipFile since they both reference the same object. If you intended to make a copy of originalZipFile, you will have to make and use a method that will create the copy.

Luc Pattyn

Hi, there is no Dispose() and no using construct in what you have shown, so nothing is getting disposed of as far as we can see. If things go wrong, chances are you didn't understand how something works, hence it is quite possible that by simplifying the code to show it here, you also have hidden the problem. Show exact code, omitting only the parts that are really irrelevant; but do show everything that happens to originalZipFile and any copies thereof. :)

Luc Pattyn [Forum Guidelines] [My Articles]

The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.

Trapper Hell

First of all I would like to thank you for taking the time to reply :) You really seem like you want to help ;) So, I totally agree with you that by simplifying the code I might also be hiding the problem. The program functions as follows. At every specified interval, the application extracts an image from a ZIP file according to "liked shoots" since this is based on a group of photographers each having their own shoots submitting, and so on... The code in demand is a follows:

private byte[] GetShootImage(ZipFile originalZipFile, string pass, string shootName)
{
while (fm.LikedShoots.Count > 0) // fm is a class containing the "liked shoots" - by names
{
ZipFile shootZipFile = originalZipFile; // <-- ERROR OCCURS HERE!!
ZipEntry zipEntry = shootZipFile.GetEntry(fm.LikedShoots[0]);

if (zipEntry != null)
{
    TempSaveStream(shootZipFile.GetInputStream(zipEntry), zipEntry.Size, true); // Saves the an entry of the ZipFile (which is yet another ZipFile to a temporary file (C:\\WINDOWS\\Temp)

    zipEntry = null;

    shootZipFile.Close();
    shootZipFile = null;

    shootZipFile = new ZipFile("C:\\\\WINDOWS\\\\Temp\\\\TpTmp\\\\temp.tmp");
    shootZipFile.Password = pass;

    // For each photo in the Shoot...
    foreach (ZipEntry entry in shootZipFile)
    {
        // If Image is not generated
        if (!fm.ImageGenerated(fm.LikedShoots\[0\] + "\\\\" + entry.Name))
        {
            // List the Image in the GeneratedPhotos list
            fm.GeneratedPhotos.Add(fm.LikedShoots\[0\] + "\\\\" + entry.Name);

            // Get the Image in a byte\[\] (instead of saving it)
            buffer = TempSaveStream(shootZipFile.GetInputStream(entry), entry.Size, false);

            shootZipFile.Close();
            shootZipFile = null;

            return buffer;
        }
    }
}

// Add the Shoot to the ExhaustedShoot list
fm.ExhaustedShoots.Add(fm.LikedShoots\[0\]);
// Remove the Shoot from the LikedShoots list
fm.LikedShoots.RemoveAt(0);

}
}

On the 2nd loop, the marked line of code throws an ObjectDisposedException within the originalZipFile object. However, as you can see, originalZipFile is not set to null or anything. Can the GC have collected it or what? In the mean, I would like to thank you so much for taking the time to reply.

Luc Pattyn

Hi, I haven't grasped the structure of your code yet; anyway this code too could use some cleaning up: 1. parameter shootName isn't used. 2. several xxx=null; don't make any sense. 3. as TempSaveStream() causes problems, one should look at its code. Please make sure you have proper error/exception handling, as explained in our other conversation. :)

Luc Pattyn [Forum Guidelines] [My Articles]

The quality and detail of your question reflects on the effectiveness of the help you are likely to get. Show formatted code inside PRE tags, and give clear symptoms when describing a problem.

Trapper Hell

I'm posting just to let you know of a few 'updates'. I haven't changed the code yet, but I will soon enough, and I'll inform you then. At the moment: 1. 'shootName' is used but not in that code extract. It's in the same method, but it's set in a if...else situation, which is irrelevant :) 2. I'm not sure if this is my misconception or anything, but I had rather thought that if an object is set to null, this makes GC more likely/quickly to occur on that object, to release the resources occupied by it? If this is my mistake, than I'm glad to know :) 3. I'll check TempSaveStream() again to ensure that it's not causing the problem. Furthermore, I WILL ;) check the exception handling, due to the embarrassing exception handling I've implemented in the other conversation we've had ;P Besides, I will check certain properties in the ZipFile class, since, for instance, there is a particular property that once the child's finished, it also closes the parent zip. So it may be something along those lines :-O Thanks for taking the time :) I'll keep you informed