[erlang-patches] format_status analog for error_info

[Steve Vinoski]

On Wed, Feb 24, 2010 at 11:53 AM, Andrew Thompson <andrew@REDACTED>wrote:

> So, with the release of R13B4 I was excited about the new format_status
> callback for gen_server and gen_fsm. Unfortunately I guess I
> misunderstood the intent of the patch (and foolishly didn't look at the
> implementation) and so the functionality is not what I'd hoped.
>

That patch works solely with sys:get_status, and puts back together two
things that at some point in the past were taken apart. I have no idea when
the division between get_status and format_status took place or why, so in
creating the patch I merely put them back together as best as I could.

What I was hoping for was to be able to use that callback to also modify
> the State information fed into error_info so that the problem of a
> process with massive internal state wasting vast amounts of memory
> sending its internal state to the SASL error_logger could be avoided if
> you used that callback to trim out the large and useless data (I don't
> care to see the giant binary my code was working on 90% of the time).
>

I don't believe format_status is called any other time except as a result of
a sys:get_status call.

Any thoughts on the best way to do this. Right now I see 3 options:
>
> * Piggyback on the terminate() callback. If the return value is of a
>  special form (maybe just {ok, State}) then don't ignore the result and
>        use the new State as the argument passed to error_info()
> * Add another new callback called something like format_error that gets
>  called (if exported) before error_info and can modify the state data.
> * Use format_status (maybe passing 'terminate' as the Opt, instead of
> * 'normal')  and look for the [{data, [{"State", State}]}] part
>  of the output (or something else?).
>
> I know that lots of people struggle with error_logger getting swamped by
> large crash messages when procesesses with large state die (facebook
> even put it in one of their slide decks), so I do intend to fix this -
> I'm just not sure of the better way (and the way that maximises the
> chances of a patch being accepted).


I think since format_status is already an optional export, reusing it for
the purposes you mention would make sense. Probably not much point in
inventing another mechanism to do something similar, and overloading
existing functions (like terminate) has a chance of breaking something.
Since format_status is new (again! :-) ) the chance of breaking anything by
reusing it for this is pretty much nil.

--steve