[erlang-bugs] BEAM crash from GTK

[Dan Gudmundsson]

Try running observer from another (erlang) node and connect to the node you
want to observe,
which you should do anyway to be sure that you don't crash the server node,
if something bad happens
as in your case.

This seems to be very early before you drawing anything, so I think this is
a possible gtk bug,
out of file descriptors maybe?

/Dan


On Mon, Apr 1, 2013 at 9:42 PM, Paul Rubin <paul@REDACTED> wrote:

> I have an application using the Ranch tcp pool that I'm trying to test at
> high concurrency.  The most trivial test for this just opens a bunch of
> idle connections and waits for the user to do something.  With 1000
> connections it works fine and I can start the observer application.  With
> 10000 connections, trying to start observer crashes the BEAM:
>
> 1> observer:start().
> *** buffer overflow detected ***:
> /usr/lib64/erlang/erts-5.9.3.1/bin/beam.smp terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(__fortify_fail+0x37)[0x31b830a697]
> /lib64/libc.so.6[0x31b8308810]
> /lib64/libc.so.6[0x31b830a607]
> /lib64/libglib-2.0.so.0(g_spawn_sync+0x1cc)[0x3e230873dc]
> /lib64/libglib-2.0.so.0(g_spawn_command_line_sync+0x78)[0x3e23087a98]
> /lib64/libgio-2.0.so.0[0x3e258af8af]
> /lib64/libgio-2.0.so.0(g_dbus_address_get_for_bus_sync+0x2ca)[0x3e258b11ca]
> /lib64/libgio-2.0.so.0[0x3e258ba0be]
> /lib64/libgio-2.0.so.0(g_bus_get+0x54)[0x3e258ba1b4]
> /lib64/libgio-2.0.so.0(g_bus_watch_name+0xe8)[0x3e258c7eb8]
> /usr/lib64/gtk-2.0/2.10.0/immodules/im-ibus.so(+0x4370)[0x7fd0b1714370]
> /lib64/libgobject-2.0.so.0(g_type_class_ref+0x4d6)[0x3e2382e0b6]
> /lib64/libgobject-2.0.so.0(g_object_newv+0x831)[0x3e238165a1]
> /lib64/libgobject-2.0.so.0(g_object_new+0xec)[0x3e23816b3c]
>
> /usr/lib64/gtk-2.0/2.10.0/immodules/im-ibus.so(ibus_im_context_new+0x12)[0x7fd0b1714ed2]
> /lib64/libgtk-x11-2.0.so.0[0x3e2a532b26]
> /lib64/libgtk-x11-2.0.so.0[0x3e2a533409]
> /lib64/libgtk-x11-2.0.so.0[0x3e2a5336a6]
>
> /lib64/libwx_gtk2u_core-2.8.so.0(_ZN8wxWindow12PostCreationEv+0x54)[0x7fd0b3c09c14]
>
> /lib64/libwx_gtk2u_core-2.8.so.0(_ZN19wxTopLevelWindowGTK6CreateEP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_+0x324)[0x7fd0b3c04754]
>
> /lib64/libwx_gtk2u_core-2.8.so.0(_ZN7wxFrame6CreateEP8wxWindowiRK8wxStringRK7wxPointRK6wxSizelS4_+0x20)[0x7fd0b3c453d0]
>
> /usr/lib64/erlang/lib/wx-0.99.2/priv/wxe_driver.so(_Z19create_dummy_windowv+0xa9)[0x7fd0b8f257c9]
>
> /usr/lib64/erlang/lib/wx-0.99.2/priv/wxe_driver.so(_ZN6WxeApp6OnInitEv+0x1d6)[0x7fd0b8f27126]
> /lib64/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x64)[0x7fd0b37418d4]
>
> /usr/lib64/erlang/lib/wx-0.99.2/priv/wxe_driver.so(_Z13wxe_main_loopPv+0x3f)[0x7fd0b8f2545f]
> /usr/lib64/erlang/erts-5.9.3.1/bin/beam.smp[0x594fe0]
> /lib64/libpthread.so.0[0x31b8607d15]
> /lib64/libc.so.6(clone+0x6d)[0x31b82f246d]
>
> I believe this is R15B but I'm not sure how to find out for certain.  The
> version number of the erts might be enough.  BEAM also dumps out a memory
> map
> that I can send if you need it.  Since there is a process (hmm, maybe 2
> processes)
> for each connection, my guess is that GTK or its wrapper layer is
> overflowing some
> internal table when trying to draw that many boxes on the screen.
>
> Regards
>
> --Paul
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20130402/9d734876/attachment.htm>