headers
Ricardo Catalinas Jiménez | 6 Feb 21:54
Picon
Gravatar

Debugger crashes handling the breakpoints

When I add some breakpoints in a module in the source code window, if I
close that window and I open it again, all the breakpoints are lost, not
shown in the sidebar nor in the `Break' menu.

Also, when I open the source code window again (with all the breakpoints
lost), if I hit on the menu `Break->Enable All' or `Break->Disable All'
the debugger crashes with:

	dbg_wx_view:error {badmatch,false}

I'm using R15B.

Regards
--

-- 
Ricardo (http://r.untroubled.be/)
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Ingela Anderton Andin | 2 Feb 11:18
Picon
Picon

[Fwd: Re: ssh daemon and encoding.]

Hi!

Pressed the wrong reply-button!

Regards Ingela
Picon Picon
From: Ingela Anderton Andin <ingela <at> erix.ericsson.se>
Subject: Re: [erlang-bugs] ssh daemon and encoding.
Date: 2012-02-02 08:20:41 GMT
Hi!

Fyodor Ustinov wrote:
> On 01.02.2012 18:50, pan <at> erlang.org wrote:
>> Hi Erik!
> Can I expect that it will be seen as a bug and corrected in the next 
> version?

I think it is a bug and should be corrected along the lines that Patrik 
suggested.  I can not promise that we will be able to priorities it
in time for the next release though.  You can always submit a patch if 
you are in a hurry ;)

Regards Ingela Erlang/OTP team - Ericsson AB
(Continue reading)

Permalink | Reply | 0 comments |
headers
Tuncer Ayaz | 1 Feb 18:59
Picon

escript: interesting stack trace

Running the following (simplified) erroneous piece of code as part
of the rebar binary, a tiny escript, or erl shell gives mostly easy
to follow stack traces.

lists:append([{a,[b]},{c,[d]}]).

I was only surprised to see win32reg:expand/1 on Linux and Darwin.
Is this expected behaviour?

The different stack traces are:

as part of the rebar binary
$ rebar compile
{'EXIT',{badarg,[{erlang,memory,0,[]},
                 {escript,run,2,[]},
                 {escript,start,1,[]},
                 {erlang,memory,0,[]}]}}

on the erl shell
$ erl
1> lists:append([{a,[b]},{c,[d]}]).
** exception error: bad argument
     in function  erl_eval:do_apply/6
     in call from shell:exprs/7
     in call from shell:eval_exprs/7
     in call from shell:eval_loop/3
     in call from erlang:memory/0

trivial escript
$ cat append1.escript
(Continue reading)

Permalink | Reply | 0 comments |
headers
systemio systemio | 1 Feb 15:13
Picon

eunit timeout doesn't work properly

My function works about 7 seconds.
i test my function via {timeout,100,[{setup,S,C,F}]} and always get timeout after 5 seconds.
BUT if i test my function via {timeout,1,[{setup,S,C,F}]} i will get timeout after a second.
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 6 comments |
headers
Scott Lystig Fritchie | 31 Jan 23:11

Race bug in net_kernel:get_status()

Hi, all.  I believe that there's a race condition bug in
net_kernel:get_status().  The system that we're seeing this on is based
on R14B04, but since R15B uses the same version of net_kernel.erl as
R14B04, R15B may also have this problem?

A process that calls net_kernel:nodes_info/0 can hang indefinitely.  A
backtrace of such a hung process looks like this:

    Program counter: 0x0000000004281120 (net_kernel:get_status/3 + 216)
    CP: 0x0000000000000000 (invalid)
    arity = 0

    0xfffffd7fd7b3e9d0 Return addr 0x0000000004280e68 (net_kernel:get_node_info/1 + 424)
    y(0)     'lhs <at> node-x.example.com'
    y(1)     <0.241.0>

    0xfffffd7fd7b3e9e8 Return addr 0x00000000042815b0 (net_kernel:get_nodes_info/2 + 96)
    y(0)     normal
    y(1)     {net_address,{{192,168,24,199},39734},"node-x.example.com",tcp,inet}
    y(2)     <0.241.0>
    y(3)     up

    [....]

This is coming from a Riak system that is using Basho's NIF interface
to the LevelDB embedded database, eleveldb.  It's possible for those
NIFs to block for long periods of time (60 seconds or more), which is
certainly not a nice thing for a NIF to do, but until we work out some
latency problems with the LevelDB code, the NIFs cause some really crazy
scheduling of both Erlang processes and internal file descriptor
(Continue reading)

Permalink | Reply | 0 comments |
headers
Fyodor Ustinov | 31 Jan 14:00
Picon
Gravatar

ssh daemon and encoding.

Hi!

Unable to set encoding to unicode in ssh daemon session.

ok = io:setopts([{expand_fun, fun expand_prompt/1}, {encoding, unicode}]),
io:format("~p~n", [io:getopts()])

say:

[{expand_fun,#Fun<group.0.33302583>},
  {echo,true},
  {binary,false},
  {encoding,latin1}]

WBR,
     Fyodor.

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 3 comments |
headers
Roberto Aloi | 31 Jan 12:46
Favicon
Gravatar

The Erlang Restricted Shell allows execution of random commands

Hi all,

reading from the Erlang doc:

http://www.erlang.org/doc/man/shell.html#start_restricted-1

"The shell may be started in a restricted mode. In this mode, the shell evaluates a function call only if allowed."

Let's write a minimal module which whitelists the 'lists' module only:

=====
-module(restrict).

-export([local_allowed/3, non_local_allowed/3]).

-define(NON_LOCAL_ALLOWED, [lists]).

local_allowed(_Cmd, _Args, State) ->
    {false, State}.

non_local_allowed({Module, _Function}, _Args, State) ->
    {lists:member(Module, ?NON_LOCAL_ALLOWED), State}.
=====

Let's then start a restricted shell, using the above module.

$ erlc restrict.erl
$ erl -stdlib restricted_shell restrict

Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:4:4] [rq:4] [async-threads:0] [hipe] [kernel-poll:false]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthew Evans | 25 Jan 17:20
Picon

Observer table viewer crash

Hi

When I use the table viewer, select a table (any table) and "Edit->Refresh Interval" I get the following error.

I am running R15B on Ubuntu 11.10. Interestingly I can select "View->Refresh Interval" from the table list window.

The crash happens immediately, the dialog doesn't even open.

Thanks

Matt


Child crashed exiting:  <0.17131.1> {function_clause,
                                     [{observer_lib,interval_dialog,
                                       [{wx_ref,294,wxListCtrl,[]},
                                        undefined,10,300],
                                       [{file,"observer_lib.erl"},{line,40}]},
                                      {observer_tv_table,handle_event,2,
                                       [{file,"observer_tv_table.erl"},
                                        {line,374}]},
                                      {wx_object,handle_msg,5,
                                       [{file,"wx_object.erl"},{line,394}]},
                                      {proc_lib,init_p_do_apply,3,
                                       [{file,"proc_lib.erl"},{line,227}]}]}
(plexxi <at> management)13> 
=ERROR REPORT==== 25-Jan-2012::08:14:38 ===
** wx object server <0.17134.1> terminating 
** Last message in was {wx,402,
                           {wx_ref,268,wxFrame,[]},
                           [],
                           {wxCommand,command_menu_selected,[],0,0}}
** When Server state == {state,
                            {wx_ref,220,wxListCtrl,[]},
                            {wx_ref,268,wxFrame,[]},
                            {wx_ref,294,wxListCtrl,[]},
                            {wx_ref,285,wxStatusBar,[]},
                            {wx_ref,293,wxBoxSizer,[]},
                            {search,true,
                                {wx_ref,295,wxBoxSizer,[]},
                                'Search Area',
                                {wx_ref,298,wxTextCtrl,[]},
                                {wx_ref,309,wxTextCtrl,[]},
                                {{wx_ref,300,wxRadioButton,[]},
                                 {wx_ref,302,wxRadioButton,[]},
                                 {wx_ref,304,wxCheckBox,[]}},
                                undefined},
                            undefined,plexxi <at> management,2,<0.17135.1>,ets,
                            {tab,bob,81944,0,1228,<0.38.0>,ignore,protected,
                                set,1,none,false,false,undefined,undefined},
                            {attrs,
                                {wx_ref,287,wxListItemAttr,[]},
                                {wx_ref,288,wxListItemAttr,[]},
                                {wx_ref,289,wxListItemAttr,[]},
                                {wx_ref,290,wxListItemAttr,[]},
                                {wx_ref,291,wxListItemAttr,[]}},
                            undefined}
** Reason for termination == 
** {function_clause,
       [{observer_lib,interval_dialog,
            [{wx_ref,294,wxListCtrl,[]},undefined,10,300],
            [{file,"observer_lib.erl"},{line,40}]},
        {observer_tv_table,handle_event,2,
            [{file,"observer_tv_table.erl"},{line,374}]},
        {wx_object,handle_msg,5,[{file,"wx_object.erl"},{line,394}]},
        {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 4 comments |
headers
Ulf Wiger | 24 Jan 11:23
Gravatar

reltool upsetting the order of things


As I'm standing knee-deep in rebar and retool fun, I've noticed that reltool doesn't seem to respect the given order of applications in the 'rel' config.

It is perhaps a less known aspect of sys tools that it will do its best to preserve the application order in the .rel file, and only move apps as needed to account for application dependencies.

There was a concrete reason for this too.

Back in the days (here comes another history lesson), we discovered that there were some nasty error situations in mnesia, where the tables would never load. As we were building a system that really had to come up, no matter what, we created a little program that started *before* mnesia, and monitored table loading progress. It was vital that it started before mnesia, because if we decided to do a force_load to break a table loading deadlock, we had to ensure that other mnesia nodes didn't start going on-line at the same time. This was handled with a global lock in the application that started before mnesia.

So this was a new (reverse) application dependency of sorts. We didn't want to hack mnesia's .app file, so we agreed with OTP (actually, I and Magnus Björklund agreed - things were easier then), that the sorting function in systools_make should not change the order unless it really had to.

The sorting function is here:

(It says there that I wrote it. I thought it was Martin. But at least you can see that it's documented, sort of).

Now, retool (after I've experimented with various settings), now filters the way I want, but then calls reltool_target:sort_apps/1 and *changes* the original order. I haven't studied the algorithm to figure out which order it prefers over mine, but I had already put the apps in the order I wanted.

A few debug printouts from reltool_target:merge_apps/2 to illustrate:

MergedApps2("setup") = [stdlib,kernel,sasl,setup]
Embedded("setup") = []
Sorted("setup") = [kernel,stdlib,setup,sasl]

I maintain that reltool doesn't have to sort the list, since systools does whatever sorting is needed. Indeed, reltool should *refrain* from upsetting the original order.

If it has added applications to the list, it should add those at the end.

BR,
Ulf W
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 5 comments |
headers
PAILLEAU Eric | 22 Jan 11:12
Picon

R15B : Included application missing. Master application starting at second try.

When forgeting path to an included application (here myapp1 is an
included application of myapp0 ), the master application do not start as
expected, but start at second try.
Is it a bug or intentional ? I didn't see this in documentation ...
Did I miss something ?

(below I forgot ' -pa /home/dev/myapp1/ebin ')

--------------------------------------8<---------------------
$> erl -pa /home/dev/myapp0/ebin

Erlang R15B (erts-5.9) [source] [smp:2:2] [async-threads:0] [hipe]
[kernel-poll:false]

Eshell V5.9  (abort with ^G)

1> application:start(myapp0).
{error,{"no such file or directory","myapp1.app"}}  <--- Expected

2> application:start(myapp0).

=ERROR REPORT==== 22-Jan-2012::10:44:43 ===
    from: myapp0
    application: myapp1
    config: default
    status: stopped
    reason: "Failed to start child."
    error: {{'EXIT',
                {undef,
                    [{myapp1,start,[normal,[]],[]},
			( ... SNIP ... SNIP ...)

=PROGRESS REPORT==== 22-Jan-2012::10:44:43 ===
         application: myapp0
          started_at: nonode <at> nohost
--------------------------------------8<---------------------

_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |
headers
Eric Merritt | 16 Jan 17:31
Picon
Gravatar

Core Erlang Binary Literals in Clause Nodes Breaks the Compiler

Guys,

I believe this is a bug. I hope the included information sufficient
and useful. If
not I can provide some more programmably testable result. A binary
literal in a pattern breaks the 'from_core' compiler.  The erlang to
core compiler does not produce binary literals for patterns, so I
suspect this code has simply never been tested. Binary literals
({c_literal, [],
<<"ok">>} for example) in the pattern part of a c_clause causes the
compiler to error out. Here are two versions of the same AST one of
which works, the other causes the compiler to error.

You can compile both of these with

   compile:forms(AST, [binary, from_core]).

Working AST:

CerlAST = {c_module,
            [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
            {c_literal,
             [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
             test},
            [{c_var,[compiler_generated],{module_info,1}},
             {c_var,
              [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
              {test,1}},
             {c_var,[compiler_generated],{module_info,0}}],
            [],
            [{{c_var,[compiler_generated],{module_info,0}},
              {c_fun,
               [compiler_generated],
               [],
               {c_call,[],
                {c_literal,[],erlang},
                {c_literal,[],get_module_info},
                [{c_literal,[],test}]}}},
             {{c_var,[compiler_generated],{module_info,1}},
              {c_fun,
               [compiler_generated],
               [{c_var,[],mdetail}],
               {c_call,[],
                {c_literal,[],erlang},
                {c_literal,[],get_module_info},
                [{c_literal,[],test},{c_var,[],mdetail}]}}},
             {{c_var,
               [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
               {test,1}},
              {c_fun,
               [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
               [{c_var,

[3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                 el}],
               {c_case,

[4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                {c_var,

[4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                 el},
                [{c_clause,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                  [{c_binary,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                    [{c_bitstr,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       111},
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       8},
                      {c_literal,[compiler_generated],1},
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       integer},
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       [unsigned,big]}},
                     {c_bitstr,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       107},
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       8},
                      {c_literal,[compiler_generated],1},
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       integer},
                      {c_literal,
                       [5,

{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                       [unsigned,big]}}]}],
                  {c_literal,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   true},
                  {c_binary,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   [{c_bitstr,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      34},
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      8},
                     {c_literal,[compiler_generated],1},
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      integer},
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      [unsigned,big]}}]}},
                 {c_clause,

[7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                  [{c_var,

[7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                    '_GENSYM_727BDA1'}],
                  {c_literal,

[7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   true},
                  {c_literal,

[8,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   foo}}]}}}]}

Broken AST:

CerlAST = {c_module,
            [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
            {c_literal,
             [1,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
             test},
            [{c_var,[compiler_generated],{module_info,1}},
             {c_var,
              [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
              {test,1}},
             {c_var,[compiler_generated],{module_info,0}}],
            [],
            [{{c_var,[compiler_generated],{module_info,0}},
              {c_fun,
               [compiler_generated],
               [],
               {c_call,[],
                {c_literal,[],erlang},
                {c_literal,[],get_module_info},
                [{c_literal,[],test}]}}},
             {{c_var,[compiler_generated],{module_info,1}},
              {c_fun,
               [compiler_generated],
               [{c_var,[],mdetail}],
               {c_call,[],
                {c_literal,[],erlang},
                {c_literal,[],get_module_info},
                [{c_literal,[],test},{c_var,[],mdetail}]}}},
             {{c_var,
               [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
               {test,1}},
              {c_fun,
               [3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
               [{c_var,

[3,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                 el}],
               {c_case,

[4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                {c_var,

[4,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                 el},
                [{c_clause,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                  [{c_literal,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   <<"ok">>}],
                  {c_literal,

[5,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   true},
                  {c_binary,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   [{c_bitstr,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      34},
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      8},
                     {c_literal,[compiler_generated],1},
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      integer},
                     {c_literal,

[6,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                      [unsigned,big]}}]}},
                 {c_clause,

[7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                  [{c_var,

[7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                    '_GENSYM_727BDA1'}],
                  {c_literal,

[7,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   true},
                  {c_literal,

[8,{file,"/home/emerritt/workspace/joxa/src/test.jxa"}],
                   foo}}]}}}]}
_______________________________________________
erlang-bugs mailing list
erlang-bugs <at> erlang.org
http://erlang.org/mailman/listinfo/erlang-bugs
Permalink | Reply | 0 comments |

Gmane