[erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

[Winston Smith]

On Mon, Apr 2, 2012 at 11:04 PM, Winston Smith
<smith.winston.101@REDACTED> wrote:
> I have run into the following issue with R15B cross compiled to an
> AVR32 (similar to ARM) system (no HiPE).
>
>
> (mynode@REDACTED)6> mnesia:stop().
> TYPE ASSERTION FAILED, file beam/erl_term.c, line 109: tag_val_def: 0x8e422b5c
> Aborted
>

Since R15B was out today, I built it for AVR32 in debug mode and ran
it again under the debugger, this time the behavior is a bit
different.  I'm guessing it's because it's a debug build, it's
catching the problem a bit earlier:


# ./erts-5.9.1/bin/erl
Eshell V5.9.1  (abort with ^G)
1> mnesia:start().
ok
2> mnesia:stop().
TYPE ASSERTION FAILED, file beam/utils.c, line 2380: !is_header(x)
Aborted (core dumped)


Running under a remote gdb session, I set a breakpoint at
beam/utils.c:2380 and when it stopped, I did a bit of poking around
and stepped through to the abort:


Breakpoint 1, cmp (a=1650811245, b=795177580) at beam/utils.c:2380
2380		if (is_not_list(b)) {
(gdb) bt
#0  cmp (a=1650811245, b=795177580) at beam/utils.c:2380
#1  0x00000000 in ?? ()
Backtrace stopped: frame did not save the PC
(gdb) print b
$1 = 795177580
(gdb) print b & 3
$2 = 0
(gdb) n
checked_is_not_list (x=795177580, file=0x78cb8 "beam/utils.c", line=2380)
    at beam/erl_term.c:130
130	ET_DEFINE_CHECKED(int,is_not_list,Eterm,!is_header);
(gdb) n
et_abort (expr=0x2f65726c <Address 0x2f65726c out of bounds>,
    file=0x78cb8 "beam/utils.c", line=2380) at beam/erl_term.c:31
31	{


I still have no backtrace, but indeed line 2380 of utils.c is in the
middle of the function "cmp" that I found previously.  I did
rebuilding the debug build with -fno-omit-frame-pointer, but it hasn't
improved the stack trace.

>From looking at the sources for ET_DEFINE_CHECKED(), it's expecting
that 'b' is not a list, but there is a precondition that 'b' is NOT a
header, which it seems to be (b & TAG_PRIMARY_MASK) ==
TAG_PRIMARY_HEADER, b & 3 == 0.

Does anyone know how to extract the erlang process backtrace/heap so I
can figure out where this is originating?

Thanks!


W.