[erlang-questions] How to view the content of memory using gdb

[Eckard Brauer]

Hi,

stack frames 6..4 seem to point to a OOM condition:

#4  0x000000000043c4c1 in erts_alc_fatal_error (error=error@REDACTED=1, func=<optimized out>, func@REDACTED=0, n=n@REDACTED=155) at beam/erl_alloc.c:1875
#5  0x000000000043c507 in erts_alloc_n_enomem (n=n@REDACTED=155, size=size@REDACTED=4723591984) at beam/erl_alloc.c:1900
#6  0x0000000000529023 in erts_alloc (size=4723591984, type=19862) at beam/erl_alloc.h:228

as first memory seems to be requested by erts_alloc() in #6, then it's
detected that no more memory is available and erts_alloc_n_enomem() is
called because of that (#5; still at C level) what is turned into a
fatal error at Erlang level too in #4, erts_alc_fatal_error().

For viewing memory content, it's good to know both the currently executed
code and the involved C structs before, to be able to jump along that IIRC.
Look at gdb's "print" command ("help print"). If the binary/binaries is/are
not stripped, you can also use symbolic names, what makes things much
easier, and you can examine source code with "list" (help list). For the
rest, "disassemble" and some knowledge of the machine's/processor's
assembly language is helpful. That only for short, it's a while since, and
I'd have to try it on a "living body" again to clearer describe...

Indeed, best would be to have the correct Erlang log.

Cheers,
Eckard


Am Tue, 21 May 2019 08:50:16 +0200
schrieb Marc Worrell <marc@REDACTED>:

> Do you have some other logs?
> Preferably the one where the message below is printed.
> 
> > On 21 May 2019, at 05:39, Monk Boy <boyofmonk@REDACTED> wrote:
> > 
> > #2  0x000000000045806e in erl_exit_vv (n=1,
> > flush_async=flush_async@REDACTED=0, fmt=fmt@REDACTED=0x5fbce8 "%s: Cannot
> > %s %lu bytes of memory (of type \"%s\", thread %d).\n",
> > args1=args1@REDACTED=0x7fda361ba830, args2=args2@REDACTED=0x7fda361ba848)
> > at beam/erl_init.c:2123
> 
> This could be out of memory, but also something else “Cannot %s” …
> 
> If it is OOM then you can easily check the memory usage of beam.smp
> whilst it is running. That would give enough hints.
> 
> Also check your running server with ‘etop’. 
> 
> Cowboy has configurations max request content length, it will refuse
> the request with a 4xx error. Afaik it defaults to 64K for urlencoded
> bodies and 8M for other bodies.
> 
> - Marc
> 



-- 
:)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: Digitale Signatur von OpenPGP
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20190521/e6f4d11d/attachment.bin>