<div dir="ltr"><div><div><div><div>Hi David,<br><br></div>one thing to be aware of when using sasl and error_logger is that process crashes get logged by sasl with the complete state of the process that just died, and error_logger tries to pretty print that state; this can take huge amounts of memory if the crashed process state is large.<br>
</div><br></div>I would recommend monitoring processes with high memory usage and figuring out the usage patterns. In general it is a good idea to try and limit the amount of state a process holds. But this is obviously application dependent.<br>
<br></div>Hope this helps point in the right direction,<br>Robby<br><br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 3 July 2014 14:22, David Welton <span dir="ltr"><<a href="mailto:davidnwelton@gmail.com" target="_blank">davidnwelton@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The kind people in #erlang have given me some suggestions, but I'm<br>
going to write here to appeal to a wider audience.  I've got a huge<br>
erl_crash.dump, that's larger than 2 gigs, and I'm trying to figure<br>
out anything I can about the crash, which came out of the blue.<br>
<br>
Slogan: eheap_alloc: Cannot allocate 1080371408 bytes of memory (of<br>
type "heap_frag").<br>
System version: Erlang R16B03-1 (erts-5.10.4) [source] [64-bit]<br>
[smp:4:4] [async-threads:10] [kernel-poll:true]<br>
Compiled: Sun Mar 16 05:25:57 2014<br>
Taints: crypto<br>
<br>
Digging further, I found this:<br>
<br>
=proc:<0.6.0><br>
State: Running<br>
Name: error_logger<br>
Spawned as: proc_lib:init_p/5<br>
Last scheduled in for: gen_event:handle_msg/5<br>
Spawned by: <0.2.0><br>
Started: Wed Jul  2 11:45:41 2014<br>
Message queue length: 1<br>
Number of heap fragments: 0<br>
Heap fragment data: 0<br>
Link list: [<0.0.0>, <0.98.0>, <0.32.0>]<br>
Reductions: 19480050<br>
Stack+heap: 137319567<br>
OldHeap: 28690<br>
Heap unused: 2273119<br>
OldHeap unused: 2581<br>
Memory: 1098789880<br>
Program counter: 0x00007f1e51f3ed70 (gen_event:handle_msg/5 + 8)<br>
CP: 0x0000000000000000 (invalid)<br>
<br>
So that's what actually blew things up.  But how did it get all that memory?<br>
<br>
=proc_dictionary:<0.6.0><br>
H7F1E4D062F68<br>
H7F1E4D062F80<br>
=proc_stack:<0.6.0><br>
0x00007f1dccc223a0:SReturn addr 0x5204B398 (gen_server:do_cast/2 + 128)<br>
y0:H7F1DCBACA990<br>
y1:AF:lager_crash_log<br>
y2:SCatch 0x5204D188 (gen_server:do_send/2 + 112)<br>
0x00007f1dccc223c0:SReturn addr 0x4F2936C8<br>
(error_logger_lager_h:log_event/2 + 10328)<br>
0x00007f1dccc223c8:SReturn addr 0x51F422F0 (gen_event:server_update/4 + 272)<br>
y0:N<br>
y1:N<br>
y2:N<br>
y3:N<br>
y4:A8:emulator<br>
y5:H7F1DCBACA8C8<br>
y6:H7F1DCBACA888<br>
y7:H7F1DCBACA930<br>
0x00007f1dccc22410:SReturn addr 0x51F41ED0 (gen_event:server_notify/4 + 136)<br>
y0:AC:error_logger<br>
y1:H7F1DCBACA8F8<br>
y2:H7F1D8B478038<br>
y3:H7F1D8B478068<br>
y4:A14:error_logger_lager_h<br>
y5:SCatch 0x51F422F0 (gen_event:server_update/4 + 272)<br>
0x00007f1dccc22448:SReturn addr 0x51F3EE68 (gen_event:handle_msg/5 + 256)<br>
y0:AC:error_logger<br>
y1:AC:handle_event<br>
y2:H7F1DCBACA8F8<br>
y3:N<br>
0x00007f1dccc22470:SReturn addr 0x51F359B0 (proc_lib:init_p_do_apply/3 + 56)<br>
y0:N<br>
y1:AC:error_logger<br>
y2:P<0.2.0><br>
0x00007f1dccc22490:SReturn addr 0x842688 (<terminate process normally>)<br>
y0:SCatch 0x51F359D0 (proc_lib:init_p_do_apply/3 + 88)<br>
<br>
The strack trace seems to indicate that it's trying to log something;<br>
perhaps someone sent it a very  large message?  But I wonder where it<br>
came from in the first place...<br>
<br>
I tried using crashdump_viewer, but it chokes when I click on the<br>
process and it tries to load up the enormous =proc_heap section:<br>
<br>
=proc_heap:<0.6.0><br>
7F1DCBACA990:t2:A9:$gen_cast,H7F1DCBACA978<br>
7F1DCBACA978:t2:A3:log,H7F1DCBACA8F8<br>
7F1DCBACA8F8:t3:A5:error,A6:noproc,H7F1DCBACA8D8<br>
7F1DCBACA8D8:t3:A8:emulator,H7F1DCBACA8C8,H7F1DCBACA888<br>
7F1DCBACA888:lH7F1DCBACA878|N<br>
7F1DCBACA878:lI39|H7F1DCBACA868<br>
7F1DCBACA868:lI103|H7F1DCBACA858<br>
7F1DCBACA858:lI115|H7F1DCBACA848<br>
7F1DCBACA848:lI100|H7F1DCBACA838<br>
7F1DCBACA838:lI95|H7F1DCBACA828<br>
7F1DCBACA828:lI119|H7F1DCBACA818<br>
7F1DCBACA818:lI101|H7F1DCBACA808<br>
7F1DCBACA808:lI98|H7F1DCBACA7F8<br>
7F1DCBACA7F8:lI64|H7F1DCBACA7E8<br>
7F1DCBACA7E8:lI108|H7F1DCBACA7D8<br>
7F1DCBACA7D8:lI111|H7F1DCBACA7C8<br>
7F1DCBACA7C8:lI99|H7F1DCBACA7B8<br>
7F1DCBACA7B8:lI97|H7F1DCBACA7A8<br>
... and on and on for thousands of lines ...<br>
<br>
davidw@shuffle:~$ grep -n '^=proc_heap' erl_crash.dump<br>
15835:=proc_heap:<0.0.0><br>
16133:=proc_heap:<0.3.0><br>
17424:=proc_heap:<0.6.0><br>
67540816:=proc_heap:<0.7.0><br>
<br>
<br>
Incidentally,  what *are* all those lines like<br>
<br>
7F1DCBACA7F8:lI64|H7F1DCBACA7E8<br>
<br>
anyway?<br>
<br>
Is there any way to hack something up that will process those 67<br>
million lines to tell me something useful about what's going on?<br>
<br>
Other ideas about how to extract something meaningful about who<br>
plopped this massive message in the logger?<br>
<br>
Thank you<br>
<span class="HOEnZb"><font color="#888888">--<br>
David N. Welton<br>
<br>
<a href="http://www.welton.it/davidw/" target="_blank">http://www.welton.it/davidw/</a><br>
<br>
<a href="http://www.dedasys.com/" target="_blank">http://www.dedasys.com/</a><br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</font></span></blockquote></div><br></div>