Hi Dennis, I would hazard to say that ExceptionReporter/get_traceback_html() is not public API (it's not listed anywhere in documentation) - and as such it would be the user implementation of this which is the bug, not the get_traceback_html method itself (i.e. you'd need to prevent this condition from happening prior to get_traceback_html being called). I could be wrong on this though!
On a related side note, I don't believe django-crashlog is a sane approach to use, not only is it going to fill up your database with huge blobs of data, but what happens if the INSERT fails or the database is unreachable? I'd recommend switching to something like ReportBug() ( http://djangosnippets.org/snippets/2214/ ) - which is mail based, New Relic (http://www.newrelic.com) or using a better approach to store the tracebacks (maybe serialize to disk, use MongoDB etc). Also remember, that when storing tracebacks, you need to make sure you implement DoS protection into the Middleware, otherwise bad people can do bad things very easily :) Any further discussion on that subject though should be moved over to django-users. Cal On Thu, Nov 17, 2011 at 5:50 PM, dlukeparker <[email protected]>wrote: > Hi all, > > I would like to know if the behavior I am seeing is to be expected, or > should be reported as a bug. > > I made a modification to the crash log middleware > http://code.google.com/p/django-crashlog/ > to get it to save the lovely html error report that is available when > settings.DEBUG == True. > > Sometimes, if settings.DEBUG is set to true and an exception happens > my debug server process goes into a loop until memory is exhausted and > it crashes. I have debugged the problem to the piece of code that > loops-till-dead. My modified crashlog code collects the html traceback > and persists it as expected, then the exception processing continues, > eventually bubbling up to the point where the debug view is processed. > > In the get_traceback_html method of the ExceptionReporter class in > django/views/debug.py the following lines are the location of the > (presumably) infinite loop that occurs when the method is called for > the second time for the same exception stack: > > frames = self.get_traceback_frames() > for i, frame in enumerate(frames): > if 'vars' in frame: > frame['vars'] = [(k, force_escape(pprint(v))) for k, v > in frame['vars']] > frames[i] = frame > > I can and will eliminate the problem by omitting the debug html call > if settings.DEBUG is true, but I would like to know, am I breaking > some design constraint by causing this to be called twice, or should I > report it as a bug? > > Thanks, > > dlp > > -- > You received this message because you are subscribed to the Google Groups > "Django developers" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/django-developers?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
