Trust only the device. That's what your user will use to run your application.
Don't trust the simulator.
As a demonstration of this, I just intentionally added a leak to a project. The leak was not detected while in the simulator, but showed up as expected on the device.
The simulator is just that: a simulator. It can be useful to work faster, but is never a replacement of the device.
Once Instruments showed you a leaked object, you can double click on it. It will show the part of your code responsible for the leak. This works for the simulator and the device.
When you compile for the device, make sure you are in debug mode (and that the settings for this mode kept all your symbols).
Some more tip that you might find useful:
For a more fluid session, disable the "Automatic Leaks Checking", and manually press the "Check for Leaks Now" button when appropriate.
The "Build and Analyse" command will do a fantastic job to help you find leaks. It's not (totally) magical, so it won't find all leaks. For example, iVars leaked won't be identified. But for the scope of a method, it's just awesome.
I highly recommend to activate the "Run Static Analyser" flag in your build settings (or only for the Release mode if you have a slow to compile machine).
If you want more info about how to use Instruments to find leaks, read this Apple doc: Instruments User Guide: Built-in Instruments and Instruments User Guide: Viewing and Analysing Trace Data > Looking for Memory Leaks
You can also watch the video of the WWDC related sessions.
If you still don't understand where your leak come from, it's time to (re)read the Memory Management Programming Guide.
Thank you for wanting to ship a leak-free application. With iOS 4, it's now more important than ever.