Pierre Rouleau | 1 Apr 17:59 2012
Picon

Is there a public bug-tracker for Erlang?

Hi all,


aside from this (erlang-bugs) mailing list, is there a publicly accessible bug-tracker system where we can take a look at the status of the various bugs, read the discussions related to the bug and provide feedback?  Something like the Rondup bug tracker for Python (http://bugs.python.org/) ?

I looked around a little and all I could find were references to this mailing list and old articles stating that there is no public Erlang bug tracker.  Is this still the case?

Thanks

/Pierre
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Winston Smith | 3 Apr 05:04 2012
Picon

Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

I have run into the following issue with R15B cross compiled to an
AVR32 (similar to ARM) system (no HiPE).

(mynode <at> 127.0.0.1)6> mnesia:stop().
TYPE ASSERTION FAILED, file beam/erl_term.c, line 109: tag_val_def: 0x8e422b5c
Aborted

Interestingly, if I bring up a standalone erl, I don't get the assert,
it segfaults instead:

# erts-5.9/bin/erl
Eshell V5.9  (abort with ^G)
1> mnesia:create_schema([node()]).
ok
2> mnesia:start().
ok
3> mnesia:stop().
Segmentation fault

I wasn't able to get much from the core file (I'm using a cross
compiled version of gdb), I supposed I'd need to build a debug version
of OTP:

Program terminated with signal 11, Segmentation fault.
#0  0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xff7f0000 in ?? ()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Any thoughts on tracking this down?

It's possible it's a low memory problem, I am already restricting the
footprint to just stdlib, kernel, inets and mnesia (and my app which
is small).
    - is there any way to enable any kind of allocation tracing so I
can pinpoint this?
    - Does mnesia have a low-memory footprint mode that I can try to
see if that ameliorates the problem?

Thanks!

W.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Gustav Simonsson | 3 Apr 10:25 2012

Re: Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)


Hi Winston,

A few ideas which might be of some use:

Try starting your node with the mnesia "debug" or "trace" level debugging
(http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76624). That might show
at which part of the shutdown the crash occurs.

When you create a table, you can give the compressed option in the storage_properties
tuple, though I don't know of any low-memory options for mnesia itself.

If you want to look at what the Erlang allocators have allocated you can use
erlang:system_info({allocator, ets_alloc}). and then look at the blocks_size tuple
which is on the format {blocks_size, CurrentSize, MaxSizeSinceLastAllocation, MaxSizeSinceEmulatorStarted}.
The values are in bytes.

// Gustav Simonsson

Sent from my PC

----- Original Message -----
> From: "Winston Smith" <smith.winston.101 <at> gmail.com>
> To: "erlang-bugs" <erlang-bugs <at> erlang.org>
> Sent: Tuesday, 3 April, 2012 5:04:00 AM
> Subject: [erlang-bugs] Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)
> 
> I have run into the following issue with R15B cross compiled to an
> AVR32 (similar to ARM) system (no HiPE).
> 
> 
> (mynode <at> 127.0.0.1)6> mnesia:stop().
> TYPE ASSERTION FAILED, file beam/erl_term.c, line 109: tag_val_def:
> 0x8e422b5c
> Aborted
> 
> 
> Interestingly, if I bring up a standalone erl, I don't get the
> assert,
> it segfaults instead:
> 
> 
> # erts-5.9/bin/erl
> Eshell V5.9  (abort with ^G)
> 1> mnesia:create_schema([node()]).
> ok
> 2> mnesia:start().
> ok
> 3> mnesia:stop().
> Segmentation fault
> 
> 
> 
> I wasn't able to get much from the core file (I'm using a cross
> compiled version of gdb), I supposed I'd need to build a debug
> version
> of OTP:
> 
> 
> Program terminated with signal 11, Segmentation fault.
> #0  0x00000000 in ?? ()
> (gdb) bt
> #0  0x00000000 in ?? ()
> #1  0xff7f0000 in ?? ()
> Backtrace stopped: previous frame identical to this frame (corrupt
> stack?)
> 
> 
> Any thoughts on tracking this down?
> 
> It's possible it's a low memory problem, I am already restricting the
> footprint to just stdlib, kernel, inets and mnesia (and my app which
> is small).
>     - is there any way to enable any kind of allocation tracing so I
> can pinpoint this?
>     - Does mnesia have a low-memory footprint mode that I can try to
> see if that ameliorates the problem?
> 
> Thanks!
> 
> 
> W.
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs <at> erlang.org
> http://erlang.org/mailman/listinfo/erlang-bugs
> 
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Stavros Aronis | 3 Apr 11:35 2012
Picon

Re: Dialyzer bug related to contract checking

Hi!


I have confirmed this bug and I will submit a patch for it soon. Thanks for the report!

Stavros

On Sat, Mar 31, 2012 at 5:51 PM, Sebastian Egner <sebastian.egner <at> entelios.com> wrote:
Hello,

The two modules a and b below seem to crash the Dialyzer in OTP R15B:

       ./dialyzer --src a.erl b.erl

--> Error in process <0.29.0> with exit value: {{badmatch,{c,list,[any,any],nonempty}},[{erl_types,t_abstract_records,2,[{file,"erl_types.erl"},{line,3194}]},{erl_types,'-t_abstract_records/2-lc$^1/1-5-',2,[{file,"erl_types.erl"},{line,3204}]},{erl_types,'-t_abstract_records/2-lc$^1/1-5-'...

(Checking a.erl and b.erl individually is inconspicious.)

For a possible workaround, see below.

Sebastian


*Details*

Here is the reduced example:

% ---------------

-module(a).
-export([g/1]).

-export_type([a/0, t/0]).
-type a() :: integer().
-type t() :: a() | maybe_improper_list(t(), t()).

-spec g(t()) -> t().
g(X) -> X.

% ---

-module(b).
-export([f/1]).

-spec f(a:t()) -> a:t().
f(X) -> a:g(X).

% ---------------


*Workaround*

My understanding of the inner workings of Dialyzer is too limited to fix it at the quality needed to submit a patch directly through Github.

However, the following patch of t_abstract_records/2 in "otp_src_R15B/lib/hipe/cerl/erl_types.erl" corrects what is probably an "accidental match" against NewContents:

3194,3195c3194,3195
<         ?list(NewContents, NewTermination, _) = t_cons(NewContents, Other),
<         ?list(NewContents, NewTermination, Size)
---
>         ?list(NewContents2, NewTermination, _) = t_cons(NewContents, Other),
>         ?list(NewContents2, NewTermination, Size)

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Winston Smith | 3 Apr 16:19 2012
Picon

Re: Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

On Tue, Apr 3, 2012 at 4:25 AM, Gustav Simonsson
<gustav.simonsson <at> erlang-solutions.com> wrote:
> A few ideas which might be of some use:
>
> Try starting your node with the mnesia "debug" or "trace" level debugging
> (http://www.erlang.org/doc/apps/mnesia/Mnesia_chap5.html#id76624). That might show
> at which part of the shutdown the crash occurs.

I did try this earlier today, I can see mnesia startup, but as soon as
I issue mnesia:stop(), it crashes before *any* further trace output:

# erts-5.9/bin/erl -mnesia debug trace
Eshell V5.9  (abort with ^G)
1> mnesia:start().
Mnesia(nonode <at> nohost): mnesia_monitor starting: <0.39.0>
Mnesia(nonode <at> nohost): Version: "4.6"
Mnesia(nonode <at> nohost): Env access_module: mnesia
Mnesia(nonode <at> nohost): Env auto_repair: true
Mnesia(nonode <at> nohost): Env backup_module: mnesia_backup
Mnesia(nonode <at> nohost): Env debug: trace
Mnesia(nonode <at> nohost): Env dir: "/home/avr32/mynode/Mnesia.nonode <at> nohost"
Mnesia(nonode <at> nohost): Env dump_log_load_regulation: false
Mnesia(nonode <at> nohost): Env dump_log_time_threshold: 180000
Mnesia(nonode <at> nohost): Env dump_log_update_in_place: true
Mnesia(nonode <at> nohost): Env dump_log_write_threshold: 1000
Mnesia(nonode <at> nohost): Env embedded_mnemosyne: false
Mnesia(nonode <at> nohost): Env event_module: mnesia_event
Mnesia(nonode <at> nohost): Env extra_db_nodes: []
Mnesia(nonode <at> nohost): Env ignore_fallback_at_startup: false
Mnesia(nonode <at> nohost): Env fallback_error_function: {mnesia,lkill}
Mnesia(nonode <at> nohost): Env max_wait_for_decision: infinity
Mnesia(nonode <at> nohost): Env schema_location: opt_disc
Mnesia(nonode <at> nohost): Env core_dir: false
Mnesia(nonode <at> nohost): Env pid_sort_order: false
Mnesia(nonode <at> nohost): Env no_table_loaders: 2
Mnesia(nonode <at> nohost): Env dc_dump_limit: 4
Mnesia(nonode <at> nohost): Env send_compressed: 0
Mnesia(nonode <at> nohost): Mnesia debug level set to trace
Mnesia(nonode <at> nohost): mnesia_subscr starting: <0.40.0>
Mnesia(nonode <at> nohost): mnesia_locker starting: <0.41.0>
Mnesia(nonode <at> nohost): mnesia_recover starting: <0.42.0>
Mnesia(nonode <at> nohost): mnesia_tm starting: <0.43.0>
Mnesia(nonode <at> nohost): Schema initiated from: default
Mnesia(nonode <at> nohost): mnesia_controller starting: <0.47.0>
Mnesia(nonode <at> nohost): mnesia_late_loader starting: <0.48.0>
Mnesia(nonode <at> nohost): Intend to load tables: []
Mnesia(nonode <at> nohost): Mnesia started, 2 seconds
ok
2> mnesia:stop().
Segmentation fault

I also ran strace(1) against the beam process while doing the
mnesia:stop(), interestingly, I see a reference to /etc/TZ and a call
to gettimeofday() (perhaps to prepare a timestamp for a log?) just
before it faults:

...
epoll_wait(3, {{EPOLLIN, {u32=0, u64=256}}}, 256, 0) = 1
clock_gettime(CLOCK_MONOTONIC, {6650, 485055333}) = 0
read(0, "mnesia:stop().\n"..., 65536)   = 15
clock_gettime(CLOCK_MONOTONIC, {6650, 499541961}) = 0
clock_gettime(CLOCK_MONOTONIC, {6650, 502889961}) = 0
clock_gettime(CLOCK_MONOTONIC, {6650, 506291561}) = 0
time(NULL)                              = 1333462397
open("/etc/TZ", O_RDONLY)               = 6
read(6, "EST5EDT\n"..., 68)             = 8
close(6)                                = 0
time(NULL)                              = 1333462397
open("/etc/TZ", O_RDONLY)               = 6
read(6, "EST5EDT\n"..., 68)             = 8
close(6)                                = 0
epoll_wait(3, {}, 256, 0)               = 0
clock_gettime(CLOCK_MONOTONIC, {6650, 526816132}) = 0
gettimeofday({1333462397, 301868}, NULL) = 0
--- SIGSEGV (Segmentation fault)  <at>  0 (0) ---
Process 621 detached

NOTE: I'm starting erl here with +K true and +A 5, although omitting
them makes no difference.

> When you create a table, you can give the compressed option in the storage_properties
> tuple, though I don't know of any low-memory options for mnesia itself.
>
> If you want to look at what the Erlang allocators have allocated you can use
> erlang:system_info({allocator, ets_alloc}). and then look at the blocks_size tuple
> which is on the format {blocks_size, CurrentSize, MaxSizeSinceLastAllocation, MaxSizeSinceEmulatorStarted}.
> The values are in bytes.

The system I'm using only has 32MB of RAM and I had thought that this
was perhaps a problem with OTP running out of memory.  However it
seems that my Erlang node fits quite nicely into about 6MB, so I don't
actually seem to be running out of system memory (I'm monitoring via
the free(1) command).

I also added 16MB of swap just to ensure that this wasn't an
out-of-memory condition.

To summarize, I'm seeing two slightly different behaviors:
    1) When I am running my node, upon shutdown I get the TYPE_ASSERTION_FAILED
    2) When running just erl and doing an mnesia:start() immediately
followed by mnesia:stop(), I get a segfault

I'm not sure why there are differences between #1 and #2, I haven't
been able to pin that down yet.

In the case of #2, I see the following in the system log:

beam[539]: segfault at 00c0001c pc 00047aba sp 7fa36424 ecr 24

If I bring back the core file to my build box and fire up the cross
compiled gdb, the stack is trashed, but if I look at address 00047aba
(pc), I seem to be in the middle of a symbol called cmp:

0x00047ab8 <cmp+628>:	mov r5,lr
0x00047aba <cmp+630>:	ld.w r3,lr[0x0]                     <<<-------- SEGV here
0x00047abc <cmp+632>:	bfextu r10,r3,0x2,0x4

So it looks like it could be a bad pointer.  However, I can't find a
symbol called cmp anywhere in beam, or the libraries it is linked
with:

# ldd erts-5.9/bin/beam
	libutil.so.0 => /lib/libutil.so.0 (0x2aab2000)
	libdl.so.0 => /lib/libdl.so.0 (0x2aab4000)
	libm.so.0 => /lib/libm.so.0 (0x2aab7000)
	libncurses.so.5 => /usr/lib/libncurses.so.5 (0x2aac5000)
	librt.so.0 => /lib/librt.so.0 (0x2aae5000)
	libc.so.0 => /lib/libc.so.0 (0x2aae7000)
	ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaab000)

So I'm not 100% sure where gdb is getting this "cmp" symbol from.

Next step is to try to build a debug version of OTP, so hopefully I
can get some more useful information from gdb.

Thanks!

W.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

PAILLEAU Eric | 3 Apr 22:14 2012
Picon

Re: Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

Le 03/04/2012 16:19, Winston Smith a écrit :
> read(6, "EST5EDT\n"..., 68)             = 8

Hi,
by reading your strace, the /etc/TZ contents looks invalid for me.

should not be EST+5EDT or EST-5EDT ???

http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html

I can see a patch for uClibc handling correctly invalid formatted TZ and
fix a segfault, but I don't know if your lib is uptodate or not...

Hope it can help...

Regards.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Winston Smith | 4 Apr 03:39 2012
Picon

Re: Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

On Tue, Apr 3, 2012 at 4:14 PM, PAILLEAU Eric <eric.pailleau <at> wanadoo.fr> wrote:
> Le 03/04/2012 16:19, Winston Smith a écrit :
>> read(6, "EST5EDT\n"..., 68)             = 8
>
> by reading your strace, the /etc/TZ contents looks invalid for me.
>
> should not be EST+5EDT or EST-5EDT ???
>
> http://www.gnu.org/software/libc/manual/html_node/TZ-Variable.html
>
> I can see a patch for uClibc handling correctly invalid formatted TZ and
> fix a segfault, but I don't know if your lib is uptodate or not...

I did try changing /etc/TZ to EST+5EDT, but it didn't help!  It was
worth a try though.

I appreciate your help anyway!

W.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Winston Smith | 4 Apr 03:59 2012
Picon

Re: Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

On Mon, Apr 2, 2012 at 11:04 PM, Winston Smith
<smith.winston.101 <at> gmail.com> wrote:
> I have run into the following issue with R15B cross compiled to an
> AVR32 (similar to ARM) system (no HiPE).
>
>
> (mynode <at> 127.0.0.1)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.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Dave Cottlehuber | 4 Apr 16:44 2012
Picon

bus error & segfaults on OS X Lion 10.7.3 after repeated crypto:md5_init

Hi,

Using homebrewed Erlang/OTP R15B & R15B01 on Mac OS X Lion 10.7.3
(11D50b) only, I'm seeing bus errors or segfaults after
crypto:md5_init() after running this continually
https://gist.github.com/2219748

Eshell V5.9.1  (abort with ^G)
1> Erlang R15B01 (erts-5.9.1) [source] [64-bit] [smp:8:8]
[async-threads:0] [hipe] [kernel-poll:false]

[... many times .... ]

Eshell V5.9.1  (abort with ^G)
1> [1]    94307 segmentation fault  erl -run erlbork

In some cases it takes a couple of hours to trigger the failure.

lldb stacktrace for R15B01 http://friendpaste.com/sQklBG4PuaVl4lwwkGu49
lldb stacktrace for R15B     http://friendpaste.com/4wmvBSjatl3cemkRgSZlkp

The original error is apparent during running CouchDB make check.
Thanks to fdmanana, benoitc, davisp for helping with this on #couchdb as always.

Let me know if I can help further.

A+
Dave
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs

Winston Smith | 4 Apr 18:43 2012
Picon

Re: Mnesia/R15B: TYPE ASSERTION FAILED, erl_term.c line 109 (when stopping mnesia)

On Tue, Apr 3, 2012 at 9:59 PM, Winston Smith
<smith.winston.101 <at> gmail.com> wrote:
> On Mon, Apr 2, 2012 at 11:04 PM, Winston Smith
> <smith.winston.101 <at> gmail.com> wrote:
>> I have run into the following issue with R15B cross compiled to an
>> AVR32 (similar to ARM) system (no HiPE).
>>
[snip]
> 2> mnesia:stop().
> TYPE ASSERTION FAILED, file beam/utils.c, line 2380: !is_header(x)
> Aborted (core dumped)
[snip]
> 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.

Don't know what's up with bt/where not working in gdb, but with
-fno-omit-frame-pointer (and a bit of research into the AVR32 ABI), I
can trace the stack via the fp register R7; it points to the return
address followed by the previous value of R7 (like EBP on x86).

So I have been able to recreate the "C" stack manually:

    0 - cmp(a,b)  --  utils.c:2380
    1 - seqeq_2(l)  --  erl_bif_op.c:115
    2 - db_prog_match()  --  erl_db_util.c:1997
    3 - db_match_dbterm()  --  erl_db_util.c:5051
    4 - db_select_chunk_hash()  --  erl_db_hash.c:1485
    5 - db_select_hash()  --  erl_db_hash.c:1404
    6 - ets_select2()  --  erl_db.c:2376
    7 - ets_select2()  --  erl_db.c:2350
    8 - process_main()  --  beam_emu.c:2642
    9 - ?? (0x02)

Unfortunately, I have not yet figured out how to get to local
variables from the AVR32 ABI, I'd really like to see what's going on
at frame #2.  It's trying to process a matchCall2 where it puts the
arguments to seqeq_2 into the stack by accessing esp[-1] and esp[-2].

I have tried to recompile with -DHARDDEBUG to turn on more tracing as
described at the bottom of this page:

http://carpanta.dc.fi.udc.es/docs/erlang/dbg.html

Although it looks like the code -DHARDDEBUG enables doesn't compile in
R15B01.  I will see if I can fix that ...

Thanks

W.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs


Gmane