At any time, your application will have a (huge) amount of live objects, even after receiving a memory warning (and subsequent memory recovery by the operating system). Thus, quite often you will also see many of those mallocs that you see.
They themselves are not a sign that something is wrong with the allocation of memory, but it is possible only because your program is running.
Also look at SO to learn more about the object selection tool .
In addition, there are many best practices that can be used to detect memory allocation problems. Here you can find a great tutorial that will allow you to go beyond what the Leaks tool allows.
EDIT:
As for the exact meaning of these mallocs, you should think that you can distinguish two broad classes of objects (roughly): Objective-C objects created through the Obj-C runtime system, and "normal" C that are allocated through malloc.
Many objects of the second class are allocated (without a direct call to malloc) by the system libraries and the C compiler library (think, for example, sockets or file descriptors, whatever). Those (C) objects do not have type information associated with them, so the tools simply show the size of the allocated memory block without any additional information.
Many times, malloc objects are created by higher-level classes, so when recovering memory associated with their instances, memory allocated through malloc is also freed.
You do not have to worry about them specifically unless you see that their total size "grows unlimited" in the execution of the program. In this case, you first need to investigate how to allocate / free objects of a higher level and understand where something is stuck in your code.