http://crash-stats.mozilla.com/report/index/3f730415-6d0e-4964-a233-f38512090908 and http://crash-stats.mozilla.com/report/index/c99aeb6e-4bcb-4013-b7f3-9426f2090908 both have stacks that have been truncated and it's the useful information that's lost. Perhaps we can change the trimmer to take the top 100 frames and the bottom 10? It seems like the top of the stack is typically more useful.
sam, your input on this configuration change request would be helpful. The frame truncation routines do keep the top 100 frames and the bottom 10 frames: both of the examples show that. These settings are configurable to whatever is desired. Is this a request to reverse the ratio? Or would it be more helpful to make the ratio 100:100 ? That settings pair may be more likely to let you see the point where the recursion starts.
Jeff: It's not clear to me what you're actually asking for? Based on what I've seen, we already do 100:10. Do you want us to extend that? I don't think it hurts anything to extend it to 100:100 or even 200:200, as long as we're not showing 17,000 lines for some section of crash reports...
I think Jeff is mixing terminology here, and would prefer the ratios to be reversed. As his example demonstrates, the top 100 frames are likely to be the infinite recursion bits, and the bottom frames are likely to have the useful information.
Ah, alright. Well, let's err cautiously and make it 100:100 for now. Lars, can you work that up?
I've submitted Bug 515276 to IT for this configuration change
lars in comment #5 > I've submitted Bug 515276 to IT for this configuration change so this is fixed?