tunefish
tunefish

Reputation: 75

StackOverFlowException - but oviously NO recursion/endless loop

I'm now blocked by this problem the entire day, read thousands of google results, but nothing seems to reflect my problem or even come near to it... i hope any of you has a push into the right direction for me.

I wrote a client-server-application (so more like 2 applications) - the client collects data about his system, as well as a screenshot, serializes all this into a XML stream (the picture as a byte[]-array]) and sends this to the server in regular intervals. The server receives the stream (via tcp), deserializes the xml to an information-object and shows the information on a windows form. This process is running stable for about 20-25 minutes at a submission interval of 3 seconds. When observing the memory usage there's nothing significant to see, also kinda stable. But after these 20-25 mins the server throws a StackOverflowException at the point where it deserializes the tcp-stream, especially when setting the Image property from the byte[]-array.

I thoroughly searched for recursive or endless loops, and regarding the fact that it occurs after thousands of sucessfull intervals, i could hardly imagine that.

    public byte[] ImageBase
    {
        get
        {
            MemoryStream ms = new MemoryStream();
            _screen.Save(ms, System.Drawing.Imaging.ImageFormat.Jpeg);
            return ms.GetBuffer();
        }
        set
        {
            if (_screen != null) _screen.Dispose(); //preventing well-known image memory leak
            MemoryStream ms = new MemoryStream(value);
            try
            {
                _screen = Image.FromStream(ms); //<< EXCEPTION THROWING HERE
            }
            catch (StackOverflowException ex) //thx to new CLR management this wont work anymore -.-
            {
                Console.WriteLine(ex.Message + Environment.NewLine + ex.StackTrace);
            }
            ms.Dispose();
            ms = null;
        }
    }

I hope that more code would be unnecessary, or it could get very complex...

Please help, i have no clue at all anymore

thx Chris

Upvotes: 1

Views: 1245

Answers (3)

Aaron Carlson
Aaron Carlson

Reputation: 5762

I'm not sure if it's relevant but the MSDN documentation for Image.FromStream states that You must keep the stream open for the lifetime of the Image.

Upvotes: 1

Andrew T Finnell
Andrew T Finnell

Reputation: 13628

You might want to read this. Loading an image from a stream without keeping the stream open

It seem possible that streams are being maintained on the stack or some other object that is eventually blowing the stack.

My suggestion would be to then just hold onto the byte[] and wait until the last possible moment to decode it and draw it. then dispose of the Image immediately. Your get/set would just then set/get the byte[]. You would then implement a custom drawing routine that would decode the current byte[] and draw it making sure not to hold onto any more resources than necessary.

Update

If there is a way you can get us a full stack trace we might be able to help further. I'm beginning to think it isn't the problem like I described. I created a sample program that created 10,000 images just like you do in your setter and there wasn't a problem. If you send an image every 3 seconds, that's 30 images a minute times 20 minutes which is only 600 images.

I'm very interested in the solution to this. I'll come back to it later.

There are a few possibilities, however, remote.

  • Image.FromStream is trying to process an invalid/corrupt byte[] and that method somehow uses recursion to decode a bitmap. Highly unlikely.
  • The exception isn't being thrown where you think it is. A full stack trace, if possible would be very helpful. As you stated you cannot catch a StackOverflowException. I believe there are provisions for this if you are running it through the debugger though.

Upvotes: 3

Jacob
Jacob

Reputation: 78840

I suspect that it's not the code you posted but the code that reads from the TCP stream that's growing the stack. The fact that the straw breaking the camel's back happens during Image.FromStream is probably irrelevant. I've oftentimes seen people write socket processing code containing self-calling code (sometimes indirectly, like A -> B -> A -> B). You should inspect that code and post it here for us to look at.

Upvotes: 3

Related Questions