3

In our code, at some point we do

73: if(someObj.SomeExternalId__c.equals(activeContract.SomeExternalId__c))
74:     someObj2.activeContract__r = activeContract;
75: }

But it fails with "Maximum stack depth reached: 12". The debug logs contain this as its last part

15:46:41.322 (6322126573)|SYSTEM_METHOD_ENTRY|[73]|String.equals(Object)
15:46:41.322 (6322139791)|SYSTEM_METHOD_EXIT|[73]|String.equals(Object)
15:46:41.322 (6322145253)|STATEMENT_EXECUTE|[74]
15:46:41.327 (6327980176)|HEAP_ALLOCATE|[74]|Bytes:35
15:46:41.328 (6328096089)|SYSTEM_MODE_EXIT|false
15:46:41.328 (6328249333)|FATAL_ERROR|System.LimitException: Maximum stack depth reached: 12

We have been pulling hairs about possible loops, but we can't find anything for weeks now. It seems as if it fails at line 74 when it allocates memory for the variable assignment, but that should never trigger a stack depth error, right?

Does anybody have a clue?

Improve this question
11
  • There are multiple "stacks" in the system, such as the trigger context stack, the function call stack, the regular expression stack (I just found this one by googling, actually), and probably others. My guess is that there's some maximum number of references you can traverse in one object's memory graph, and you managed to break it.
    – sfdcfox ♦
    Commented Sep 30, 2015 at 16:04
  • 2
    FWIW, I can't duplicate "stack depth exceeded: 12"; I know about other limits, like 17 and 1001, but I wrote several different trivial types of code to try and find what limit you've run into, and I can't seem to find anything at all. You might need a closer look at your code.
    – sfdcfox ♦
    Commented Sep 30, 2015 at 16:16
  • Hey @sfdcfox thanks so much for the effort! Salesforce support is stuck on it for 14 days as well, and they assumed that it had to do with some null assignment, which sounds unlikely. Even more because we've just found that it only occurs for one specific user (an Admin) and not for the other users (also Admins). This makes the issue even less predictable. I'll leave the question open for others that might have possibly had the same issue...
    – Willem Mulder
    Commented Sep 30, 2015 at 20:08
  • @sfdcfox it's only happening when debugging is on (via debug flag or if developer console is open) and that's really annoying because that means that running code or tests via the developer console is impossible because we always get the Stack Depth error. SF support has given up I think, so we're still in the dark.
    – Willem Mulder
    Commented Nov 4, 2015 at 22:11
  • 1
    I just asked Pat Patterson if he might be able to shed some light on this. He's an internal salesforce.com guy that's pretty awesome, so he might be able to help.
    – sfdcfox ♦
    Commented Nov 4, 2015 at 23:17

2 Answers 2

Reset to default
1

Periodically this type occurs for us on the cs11 sandbox. Today is one such example. In the past I found if I refactor code, it will change which line the occurs and what depth it is reporting the error, but there is simply no way to resolve it. I think in our case it is related to some sort of bug when you call static methods to prepare values for a constructors super() call. It is only one set of classes where the error occurs. So far it has only been running test methods. If I report it to salesforce, by the time they get around into looking into it, the problem is gone. I have not seen this error on any other sandbox, even ones with the exact same code...

Improve this answer
1
  • We've narrowed it down to the fact that the Stack Depth Error only occurs when 'debugging' is switched on. That means that if a debug flag is active OR if the developer console is open, the error will occur. Is that also happening on your side?
    – Willem Mulder
    Commented Nov 4, 2015 at 22:09
0

I had the same problem. After reading answers/comments in this thread, I removed the Debug Logs that were requested by me, and this problem was solved.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .