"Out of Memeory" error

I'm working with the GDI+ and when I go to load an image it gives me the error
http://63.169.162.2/admin/forumpics/memoryerror.jpg
I have tried declaring tImage different types (i.e. Bitmap) and still nothing. What's really interesting about this is that if I step through the program line by line, it works just fine. What gives?

Here's my code:

VB Code:

Imports System.IO
Imports System.Windows.Forms
Imports System.Drawing
Imports System.Drawing.Imaging
 
...
 
Private tImage As Image
 
Private Sub LoadImage(ByVal ImagePath as String)
 
            tImage = Image.FromFile(ImagePath)
 
End Sub

Alright, well so far it has to do with the size of the picture? It crashes when loading 1.5MB pictures, but 29KB pics work just fine (I don't have to step through the program for it to load the picture).

bump. anyone?!

No idea. Could u zip some code and the image and post it here ?

Cheers,
NTG

A little more code might be helpful, especially the function/sub that calls the load image

I've bolded where I get the error.

VB Code:

Imports System.Drawing
Imports System.Drawing.Imaging
 
Module mdlEditImage
    Public Class clsWorkingImage
 
        Public imgWorking As Image 'The original image instance
        Private strWorkingPath As String 'The path of the original image before processing a.k.a "The Drop Folder"
        Public strOrgImagePath As String 'The path to where the Original image will be placed after processing
        Public strProcImagePath As String 'The path to where the Processed image will be placed after processing
 
        Public Sub New(ByVal strImagePath As String)
            Try
                strWorkingPath = strImagePath
                [B]imgWorking = Image.FromFile(strWorkingPath)[/B]
                strOrgImagePath = Dir(strWorkingPath) & "\Original\"
                strProcImagePath = Dir(strWorkingPath) & "\Processed\"
            Catch er As Exception
                Throw er
            End Try
        End Sub
    End Class
End Module
------------------------------------------------------------------
Imports System.IO
Imports System.Windows.Forms
Imports System.Drawing
Imports System.Drawing.Imaging
 
Public Class frmMain
    Inherits System.Windows.Forms.Form
 
WINDOWS FORM DESIGNER GENERATED CODE
 
    Private WithEvents fsw As New FileSystemWatcher
    Private tImage As Image
 
    Private Sub HandleChangedCreatedDeleted(ByVal sender As Object, ByVal e As System.IO.FileSystemEventArgs) Handles fsw.Changed, fsw.Created, fsw.Deleted
 
        If System.IO.Path.GetExtension(e.FullPath) = ".jpg" Then
 
            If e.ChangeType = WatcherChangeTypes.Created Then
 
                'Initialize picture || tWI = tmp Working Image
                Dim tWI As New clsWorkingImage(e.FullPath)
            End If
 
        End If
    End Sub
End Class

Nothing wrong with that code...could you upload the image somewhere ?

Hopefully, this isn't the GDI+ overflow bug...you're patched aren't you ?

Quote:

---

you're patched aren't you ?

---

I have
VB.Net Version 7.1.3088 (2003)
.Net Framework 1.1 Version 1.1.4322 SP1

That's all I know. Besides, isn't the overflow virus related?

Unfortunately, I cannot show you the picture, but it's a jpg w/ a resolution of 1997x4260 @ 240 dpi.

just a reminder.. it does work with much smaller pictures.

By "patched" I was refering to Windows patches. Anyway, if you can't post the picture somewhere for someone to see it might be difficult to get a grasp of the problem.

Cheers,
NTG

The actual picture that's being used? It's not just one picture, it's all of them. Here is an example: 999B.jpg

Your clsWorkingImage class works fine for me.

Just spotted something else though...could u ammend clsWorkingImage as follows:

VB Code:

Public Class clsWorkingImage
 
        Shared NumCount As Integer = 0
        Public imgWorking As Image 'The original image instance
        Private strWorkingPath As String 'The path of the original image before processing a.k.a "The Drop Folder"
        Public strOrgImagePath As String 'The path to where the Original image will be placed after processing
        Public strProcImagePath As String 'The path to where the Processed image will be placed after processing
 
        Public Sub New(ByVal strImagePath As String)
            Try
                NumCount += 1
                Debug.WriteLine("Called " + NumCount.ToString + " times")
                strWorkingPath = strImagePath
                imgWorking = Image.FromFile(strWorkingPath)
                strOrgImagePath = Dir(strWorkingPath) & "\Original\"
                strProcImagePath = Dir(strWorkingPath) & "\Processed\"
            Catch er As Exception
                Throw er
            End Try
        End Sub
    End Class

and see how many times the class objects load an image ? I have a feeling that the file system watcher may throw several events for each file, so loading several times a large image may give you an out of memory exception. If that is the case, this would also happen with smaller images but it would take more time for the error to occur.

Cheers,
NTG

I sure am curious to know what happened, did that help or not jsun9 ? :confused:

Cheers,
NTG

ntg, that was a great theory. But, I checked it out and it only calls the sub once. I know fsw will in some cases call it multiple times. however, the HandleChangedCreatedDeleted Sub that I use to set my program in motion is only called once upon the creation of a file.

but get this, if i drop a second file.. it crashes.

:confused: Well, you got me jsun9. If it's called only once I'm fresh out of any ideas - it's still runing fine on my box. :confused:

Ehm...ok, it may be running fine on my box because I have lots of RAM. Do you do a imgWorking.Dispose() and imgWorking=Nothing at some point ?

I only set the class instance to nothing. I don't set imgWorking to nothing because there's no real place to do it. Do you think GDI+ doesn't support this file? The MSDN states it'll throw a memory error if the picture is unsported. But it's a jpg? Also, I have 1.5GB of RAM so I doubt it's really running out of memory.

If I set it up manually (take it out of the filesystemwatch event) it doesn't error. no idea why.

:mad: :mad: :mad: Now I'm pizzed off :mad: :mad: :mad:

First of all, you really need to do a .Dispose() since GC doesn't really do a good job with Images plus the image file itself stays locked for some time if you don't .Dispose().

Now...I too got the error when I pasted several large images at once. I made a small change:

VB Code:

Threading.Thread.CurrentThread.Sleep(100)
Dim tWI As New clsWorkingImage(e.FullPath)

and I never got the error after that. Also, if you add:

VB Code:

Debug.WriteLine(e.ChangeType.ToString + "> " + e.Name)

at the beginning of the file system watcher event code, you'll see that when you copy a new file there is a single created event and some changed events. Most of the time, these happen at the same millisecond, but every now and then they do occur some milliseconds apart. Best guess ('cause that's what it is, really) is that when the created event is fired the file is not yet completely copied and when you try to read it through Image.FromFile, GDI is missing some data and in some way it throws an out of memory exception :sick: I understand that this is completely unscientific and unsupported by any fact, it ain't even informed guessing but I can't think of anything else right now. If someone has some explanation, I'd love to hear it. I'll play with it some more and post anything that comes to mind.

Cheers,
NTG

yup. i think that explains it all. that's why it works with small files: by the time the fsw triggers the event and the image class is made, the file is already copied in its entirety.

the sleep event works for now.. but what happens when you have a really huge file that takes 3 seconds to transfer? you could have a timer watch the file until it was completed, but that's just messy. but then again.. I bet if I drop multiple files at a time, it will only catch the first one if that.. a time may be my only option?! :mad:

the created event is pretty weak.. there should be a finished_creating or final_change event to let the program know it's not going to be touched anymore.

Yeah, something like finished_creating would help. I think that you'd need to use some kind of queue where newly created items would be inserted, then a background thread would check the queue and would then open a stream reader that checks the file size reported by the dir properties against the file size reported by stream reader - only when they're equal should you continue with opening the image. Or maybe a file open with exclusive read/write lock - that would fail unless file copy is done so again you can flag the file as being ok to open.

This is pretty messy indeed, I wonder if there really isn't a better alternative...

Edit: I'm missing the obvious again, when System.IO.File.GetLastWriteTime() stops changing the file must be complete.

Cheers,
NTG

yeah.. the queue is probably the safest. i'll give it a try and post the results. I appreciate your help ntg.. it was pleasant working with someone sincerely interested in finding out the results.

:blush:

So about that finished_creating feature we were wishing we had...well, it's called WatcherChangeTypes.Created :bigyello: It works perfectly like a queue.

I call it like this (the 3000 tells it to wait 3000 ms after last change before moving on.

VB Code:

fsw.WaitForChanged(WatcherChangeTypes.Changed, 3000)

Geez, I didn't know that. Thanks for posting :thumb:

Cheers,
NTG