*** malloc: vm_allocate(size=3362816) failed (error code=3)

Scripting Forums AppleScript Studio & Xcode
,
#1

I am working on a project in which the user can drop a folder with images. It puts the contents in a table view and from that table view the user can select a file from which the image is displayed in a second window.
This works fine with one folder. However, when I keep dropping folders to display the contents, eventually something goes wrong with the display of the images at a certain time.
On the ‘set image of image view…’ statement It logs this error:

*** malloc: vm_allocate(size=3362816) failed (error code=3)
*** malloc[4526]: error: Can’t allocate region
*** malloc: vm_allocate(size=3362816) failed (error code=3)
*** malloc[4526]: error: Can’t allocate region
*** malloc: vm_allocate(size=3362816) failed (error code=3)
*** malloc[4526]: error: Can’t allocate region
(always three times)

From that moment the program does not display images anymore only the error above.
I tried to make a new image view to continue with that but it makes no difference. Only blank pictures.

The ‘set image of image view…’ is already in a try block but the it does not result in a real error,
just the mysterious “*** malloc:…”
Does anyone know what this error means and how to deal with it.

Since it appears only after multiple drops, could it be some kind of overflow?
It has nothing to do with any damaged images.

Thanks in advance,

John

#2

John,

malloc is the all purpose memory allocator, I don’t know what the error code 3 is but it probably means that you failed to allocate the required memory to display the images.

malloc is calling the low level memory allocator vm_allocate, where vm stands for virtual memory, and you are trying to allocate 3.3 MBytes of memory in one go. There are 2 reasons why this could fail. You have used up all 4GBytes of your memory address space, the second possibility is you are getting short of disk space on your boot volume where your virtual memory files live. If you have less than 1GByte left that is a possibility as the last vm file I think is 1GByte in size.

If your digital images are from a 4MegaPixel camera you would only be able to display about 240 of them with no memory allocation for anything else (ie a theoretical max, not a real world maximum) at a time.

Why the three times, the operating system might try to move memory arround each time to try and see if it can get a memory block large enough.

Kevin

#3

It must be this reason because the other is not possible.
Is there any way to clear this, so I can go on without having to quit the program?
It does not matter what I have to do. Clear all my workspace. Anything but quitting.

Thanks

John

#4

If you are trying to display even small versions of every image then I think the best thing is to actually create small versions of your images and load those.

If however you are replacing the contents of an image view with a new image then you will have to dispose of the old image.

See thread “Drawers won’t work in os 10.3.3”, July 20 2004 (near end). Which shows how to obtain the oldImage to delete it before setting the image of the image view to the new image.

Kevin

#5

Thank you for pointing me in the right direction.
I have adjusted the code as below:

set oldImage to image of image view "image" of window showWindow
set image of image view "image" of window showWindow to load image posixPath
try
	delete oldImage
end try

I am sorry to say that the program still aborts with the same error after some time.
about the same time as it was before.
I double checked if the image space could have increased in other places. but that’s not the case.

Thanks

John

#6

I am puzzled.

The following questions are more kind of clutching at straws in the hope that something reveals itself.

Are you dragging the images into the image view from Finder?

Does your handler for processing the files do tell application “Finder” when handling the file?

If that is the case then it might be a problem where Finder really gets itself tied up in knots if you are asking it to do some AppleScript processing while it is waiting to hear back about from the drag and drop handler. That has been discussed in this forum before?

If that is not the case and you are dropping the image files into the image view and then displaying the images in another image view you might want to try deleteing the image in the image view where it has been dropped after the file has been processed.

These are only thoughts and ideas.

Kevin

#7

I think you need to apply a tool like /Developer/Application/Performance Tools/ObjectAlloc to see exactly which objects are using up all your memory.

#8

Thank you for your help.

Some addional notes:
I do no not drop image-files one by one but I drag a folder with images to a dropArea. The images are stored in a data source.
One can select a file from the table view to display an image (This is the moment where the Malloc-error always occurs)
In the ‘selection changed’ handler I do various request to the Finder like if the file is locked or if it has any comment.
The Drop-handler has exited long before the ‘selection changed’ handler is called.

I used the ObjectAlloc utility. but I don’t not really know how to read this.
But I will try. I assume that the pink line is the time line and the red line the memory usage.
Suppose this is true then the results:
General block -5971968: peak: 1791504 total increases by ca. 24.000 for every display of an image. There is always a short peak all the way to the end for every image display.
Other memory consuming categories:
CFString (immutable)
CFArray(store-deque)
CFString(immutable-variable)
CFArray (immutable)
Unfortunately the ObjectAlloc utility always crashes long before the ‘Malloc error’ occurs.

I really don’t know anymore. This is the final step to take before the application is ready.
I worked on this for months. I can’t give an application with a note that it might crash sometimes.
I have been trough the program again to see if there is any place I could have overlooked.

John

#9

I’m sorry John I dont have any further (useful) suggestions.

The object alloc utility is not very helpful, I have just been playing with it, and it didn’t really help me understand very well what was happening.

From what you say there is definitely a memory leak.

Does the error message occur after a certain amount of time, or after you have added a certain number of images, or after you have displayed a certain number of images? Is it always the same (time or number)?

Whichever, after how long, or after how many images have been added or how many images have been displayed? How big are the images (width, height)?

From what you say it seems to be the number of displayed images that seems to be the problem, which means delete image isn’t doing its job properly.

Kevin

#10

The error appears completely random. There is never anything wrong with the images itself.
The last time I logged it was image# 1399, 147KB. The cumulative image-size so far was 246MB.
Most of the time the program does not abort but displays only empty image-windows from that moment. Sometimes the program aborts or becomes unpredictable.

There is something strange about this log, for example between two errors messages it logs “verder”
This is theoretical impossible. If it was true then the handler would have been called two times for the same image.

*** malloc: vm_allocate(size=4718592) failed (error code=3)
*** malloc[1605]: error: Can’t allocate region
2005-03-13 15:56:59.165 Novice Organizer 1.0[1605] “verder”
*** malloc: vm_allocate(size=4718592) failed (error code=3)
*** malloc[1605]: error: Can’t allocate region

Thanks for all the help

John

#11

Hey guys. I don’t really have any solutions to present, but I thought I would jump in and add my 2 cents to this discussion.

I’m not sure that this is necessarily a problem with your code, but perhaps in the combination in which you’re doing certain things… and also in problems which may be inherent in ASStudio itself. I think that ASS is fundamentally limited in it’s ability to do certain things which are very memory intensive. I, and I assume many others, regularly make assumptions about it’s abilities and do not take into consideration it’s limitations. Memory management is one of the most talked-about goblins in efficient cocoa programming. Because of it’s relationship with cocoa, applescript studio ultimately must live with this burden as well. Although you’ve tried the delete command to try to manually ‘release’ the images, I agree with ktam, that this may not be doing everything you need it to. I’m no expert on memory, but I could see that a weak implementation of the delete command or a bug in ASS’s automatic memory deallocation may not be releasing all of the memory you try to allocate. Perhaps it is deleting it’s connection to the memory, but not actually freeing the memory from disk?

I searched around a bit and found that malloc errors are generally common for people trying to load large amounts of data… not just in image form, either. I even found one post where some guys were forcing the OS to incrementally load increasingly large files to find the memory allocation limit… which eventually lead the whole machine to crash. :shock:

I’m guessing that one or two things are happening. You could be slowly adding memory to shared memory until you reach your available limit… and/or you’ve found a limitation of applescript studio. Have you been able to determine a finite limit to the memory you are able to load? Obviously there’s not much we can do to help without a copy to test ourselves, and like ktam, I don’t have much more input to give. I would try a scientific approach, such as doing some baseline tests on the cause of the problem. I’d try restarting the machine, launching your app, and doing some structured tests. Try loading the same file(or files) in the same order in generally the same conditions (time, frequency,interval, etc.). Do this a few times to see if starting from scratch leads to some regular results. Perhaps if you could establish some patterns, by adding up the time taken or total size of the combined files, you might see that there actually was one problem that could be reproduced… and ultimately solved.

I assume you are using some sort of memory monitor to watch as you test the app, to see what is happening at the exact moment the error occurs. Sometimes seeing the memory spike at a certain moment can lead to a more precise evaluation of the cause. Also, is the error occurring when you reference the item from the data source, or when you try to load the image using the path found in the data source? Just to clarify, you said “The images are stored in a data source.”, but you mean that a list of paths to those images is stored in the data source, right? Can’t imagine how you’d do it otherwise, but I had to ask… a few works can make all the difference, no? :wink:

Good luck, and let us know what you find…
j