<div dir="ltr">Try running observer from another (erlang) node and connect to the node you want to observe, <div>which you should do anyway to be sure that you don't crash the server node, if something bad happens</div>
<div style>as in your case.</div><div><br></div><div style>This seems to be very early before you drawing anything, so I think this is a possible gtk bug,</div><div style>out of file descriptors maybe?</div><div><br></div>
<div style>/Dan</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 1, 2013 at 9:42 PM, Paul Rubin <span dir="ltr"><<a href="mailto:paul@mongohq.com" target="_blank">paul@mongohq.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I have an application using the Ranch tcp pool that I'm trying to test at<br>high concurrency. The most trivial test for this just opens a bunch of<br>
idle connections and waits for the user to do something. With 1000<br>
connections it works fine and I can start the observer application. With<br>10000 connections, trying to start observer crashes the BEAM:<br><br>1> observer:start().<br>*** buffer overflow detected ***:<br>/usr/lib64/erlang/erts-5.9.3.1/bin/beam.smp terminated<br>
======= Backtrace: =========<br>/lib64/libc.so.6(__fortify_fail+0x37)[0x31b830a697]<br>/lib64/libc.so.6[0x31b8308810]<br>/lib64/libc.so.6[0x31b830a607]<br>/lib64/libglib-2.0.so.0(g_spawn_sync+0x1cc)[0x3e230873dc]<br>/lib64/libglib-2.0.so.0(g_spawn_command_line_sync+0x78)[0x3e23087a98]<br>
/lib64/libgio-2.0.so.0[0x3e258af8af]<br>/lib64/libgio-2.0.so.0(g_dbus_address_get_for_bus_sync+0x2ca)[0x3e258b11ca]<br>/lib64/libgio-2.0.so.0[0x3e258ba0be]<br>/lib64/libgio-2.0.so.0(g_bus_get+0x54)[0x3e258ba1b4]<br>/lib64/libgio-2.0.so.0(g_bus_watch_name+0xe8)[0x3e258c7eb8]<br>
/usr/lib64/gtk-2.0/2.10.0/immodules/im-ibus.so(+0x4370)[0x7fd0b1714370]<br>/lib64/libgobject-2.0.so.0(g_type_class_ref+0x4d6)[0x3e2382e0b6]<br>/lib64/libgobject-2.0.so.0(g_object_newv+0x831)[0x3e238165a1]<br>/lib64/libgobject-2.0.so.0(g_object_new+0xec)[0x3e23816b3c]<br>
/usr/lib64/gtk-2.0/2.10.0/immodules/im-ibus.so(ibus_im_context_new+0x12)[0x7fd0b1714ed2]<br>/lib64/libgtk-x11-2.0.so.0[0x3e2a532b26]<br>/lib64/libgtk-x11-2.0.so.0[0x3e2a533409]<br>/lib64/libgtk-x11-2.0.so.0[0x3e2a5336a6]<br>
/lib64/libwx_gtk2u_core-2.8.so.0(_ZN8wxWindow12PostCreationEv+0x54)[0x7fd0b3c09c14]<br>/lib64/libwx_gtk2u_core-2.8.so.0(_ZN19wxTopLevelWindowGTK6CreateEP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_+0x324)[0x7fd0b3c04754]<br>
/lib64/libwx_gtk2u_core-2.8.so.0(_ZN7wxFrame6CreateEP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_+0x20)[0x7fd0b3c453d0]<br>/usr/lib64/erlang/lib/wx-0.99.2/priv/wxe_driver.so(_Z19create_dummy_windowv+0xa9)[0x7fd0b8f257c9]<br>
/usr/lib64/erlang/lib/wx-0.99.2/priv/wxe_driver.so(_ZN6WxeApp6OnInitEv+0x1d6)[0x7fd0b8f27126]<br>/lib64/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x64)[0x7fd0b37418d4]<br>/usr/lib64/erlang/lib/wx-0.99.2/priv/wxe_driver.so(_Z13wxe_main_loopPv+0x3f)[0x7fd0b8f2545f]<br>
/usr/lib64/erlang/erts-5.9.3.1/bin/beam.smp[0x594fe0]<br>/lib64/libpthread.so.0[0x31b8607d15]<br>/lib64/libc.so.6(clone+0x6d)[0x31b82f246d]<br><br>I believe this is R15B but I'm not sure how to find out for certain. The<br>
version number of the erts might be enough. BEAM also dumps out a memory map<br>that I can send if you need it. Since there is a process (hmm, maybe 2 processes)<br>for each connection, my guess is that GTK or its wrapper layer is overflowing some <br>
internal table when trying to draw that many boxes on the screen.<br><br>Regards<span class="HOEnZb"><font color="#888888"><br><br>--Paul<br><br>
</font></span><br>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br></div>