Finding where the method was called from

You cannot duplicate the functionality of the debugger, dtrace, and / or other tools that do exactly this kind of thing without much effort. This is remarkably architecture dependent and is common in special cases and situations that do not work.

You would certainly never want to do this in production code. For debugging, there are enough tools that do it in a sufficient context that there is no need to do it.

What are you trying to do?

Basically I use KVO, and if the KVO method is started from another method, which is IBAction, I don’t what it will do as usual otherwise it will go into a loop (related to my previous question).

Down this path is madness. It breaks encapsulation entirely to have a method whose execution is affected by the caller without being some kind of explicit argument or implicit configuration to indicate that the behavior should change.

If you end up in an endless loop, I suggest revisiting the overall architecture.

In particular, when a KVO notification is triggered, it should almost never trigger a KVO notification of the same property directly or indirectly. In the extremely rare case where this is unavoidable, you should make sure that you fire your KVO triggers manually using -willChangeValueForKey:

and -didChangeValueForKey:

conditionally.

Basically, just for the sake of explanation, I am respecting the main data property and the method that gets called when the property change calls another method (IBAction), but in this IBAction it adds Core Data objects that trigger the KVO method that triggers the IBAction, etc. ... This is why I was trying to figure out where the method was called, so I could stop this infinite loop

In other words, you have a model layer change that then calls a method on the interface between the presentation layer and the control layer (IBAction method), which, unsurprisingly, causes another model layer change, which is then disconnected from the rails ....

Once your observer fires and you need to make changes to the model as a result, you must keep all of the change logic within the model layer. At the end of the day, this is your model and must have the knack for applying changes appropriately.

What should never happen is that the control layer or presentation layer triggers model changes in response to the model change. Changes to the model - to the data - from the control / view layer should only occur in response to user action or some external event (timer, perhaps).