Bjorn Gustavsson | 1 Aug 11:26 2005
Picon
Picon

Re: Internal consistency check error (Wings Compile)

This bug will be fixed in R10B-7.

/Björn

Brent Fulgham <bfulg <at> pacbell.net> writes:

> I received an Internal consistency check error when attempting to
> compile Wings 0.98.29b under OTP R10B-6 under Mac OS X (10.4.2 Tiger):
> 
> Chaz:~/Desktop/wings-0.98.29b brent$ make
> (cd src; make)
> make TYPE=opt common
> erlc -pa /ebin +warn_unused_vars -I/include -I ../e3d -W +debug_info
> '-Dwings_version="0.98.29b"' -pa ../ebin -o../ebin wings_color.erl
> wings_color: function internal_rgb_to_hsv/3+97:
>    Internal consistency check failed - please report this bug.
>    Instruction: {test,is_eq_exact,{f,80},[{x,0},{atom,error}]}
>    Error:       {unsafe_instruction,{float_error_state,cleared}}:
> 
> make[2]: *** [../ebin/wings_color.beam] Error 1
> make[1]: *** [opt] Error 2
> make: *** [all] Error 2
> 
> Chaz:~/Desktop/wings-0.98.29b brent$ uname -a
> Darwin Chaz.local 8.2.0 Darwin Kernel Version 8.2.0: Fri Jun 24
> 17:46:54 PDT 2005; root:xnu-792.2.4.obj~3/RELEASE_PPC Power Macintosh
> powerpc
> Chaz:~/Desktop/wings-0.98.29b brent$
> 
> 
(Continue reading)

Sean Hinde | 3 Aug 00:09 2005
Picon

R10B-6 compiler bug

Hi,

Just came across this one:

-module(compile_bug).
-export([ test/1]).

-record(a, {a,b,c}).

test(As) ->
     case As of
     A when A#a.b == ""; A#a.b == undefined ->
         true;
     _ ->
         false
     end.

23> c(compile_bug).
Function test/1 refers to undefined label 5
./compile_bug.erl:none: internal error in beam_dead;
crash reason: {{case_clause,{'EXIT',{undefined_label,5}}},
                [{compile,'-select_passes/2-anonymous-2-',2},
                 {compile,'-internal_comp/4-anonymous-1-',2},
                 {compile,fold_comp,3},
                 {compile,internal_comp,4},
                 {compile,internal,3}]}
error

The error seems to occur in pass 'beam_bool' - skipping this pass  
avoids creating the error
(Continue reading)

Bjorn Gustavsson | 3 Aug 12:28 2005
Picon
Picon

Re: R10B-6 compiler bug

Thanks! Corrected! (The correction will be included in R10B-7.)

/Björn

Sean Hinde <sean.hinde <at> gmail.com> writes:

> Hi,
> 
> Just came across this one:
> 
> -module(compile_bug).
> -export([ test/1]).
> 
> -record(a, {a,b,c}).
> 
> test(As) ->
>      case As of
>      A when A#a.b == ""; A#a.b == undefined ->
>          true;
>      _ ->
>          false
>      end.
> 
> 23> c(compile_bug).
> Function test/1 refers to undefined label 5
> ./compile_bug.erl:none: internal error in beam_dead;
> crash reason: {{case_clause,{'EXIT',{undefined_label,5}}},
>                 [{compile,'-select_passes/2-anonymous-2-',2},
>                  {compile,'-internal_comp/4-anonymous-1-',2},
>                  {compile,fold_comp,3},
(Continue reading)

Vlad Dumitrescu | 22 Aug 21:25 2005
Picon

Bug in jinterface

Hi,

The OtpOutputStream implementation in jinterface is not conforming to the 
external distribution format: method write_string doesn't check if the 
length is >= 65536, when the sitring should be output with a listTag, not a 
stringTag.

The patch is (sorry, but I have a modified version of the file and the line 
numbers don't match)

-            if (bytebuf.length == len && len < 65535)
+            if (bytebuf.length == len)

regards,
Vlad

Raimo Niskanen | 23 Aug 12:16 2005
Picon
Picon

Re: Bug in jinterface

This bug is fixed in R10B (jinterface-1.3) and later:

  public void write_string(String s) { 
    int len = s.length();

    switch(len) {
    case 0:
      this.write_nil();
      break;
    default:
      byte[] bytebuf = s.getBytes();

      /* switch to se if the length of
	 the byte array is equal to the 
	 length of the list, or if the string is too long
	 for the stream protocol */
      if ((bytebuf.length == len) && (len <= 65535)) { /* Usual */
	this.write1(OtpExternal.stringTag);
	this.write2BE(len);
	this.writeN(bytebuf);
      } 
      else { /* Unicode */
	char[] charbuf = s.toCharArray();
	
	this.write_list_head(len);
	
	for(int i = 0; i<len; i++)
	  this.write_char(charbuf[i]);
	
	this.write_nil();
(Continue reading)

Serge Aleynikov | 23 Aug 22:47 2005
Picon
Picon

inets ftp bug

OTP team:

I found a bug in the inets' ftp.erl client that can be patched by 
applying the ftp.erl.patch file to the source.

The bug is seen when you try to download more than one file in a row 
using ftp:recv/2 function.  For some reason this bug doesn't occur when 
tracing is enabled (and/or debugger application is running).

Use the following to reproduce the bug:

ftp_test:test(Host, User, Password, RemoteDir, RemoteFile).

~/tmp/dirtest>erl -pa ~/Projects/DRP/lib/drpdb-1.0/ebin
Erlang (BEAM) emulator version 5.4.8 [source] [hipe] [threads:0]

Eshell V5.4.8  (abort with ^G)
1> ftp_test:test("localhost", "serge", "...", "/home/serge", "tt.txt").
"220 ProFTPD 1.2.6 Server (DevLinuxPro FTP) [devlinuxpro.mis.idt.net]"
"331 Password required for serge."
"230 User serge logged in."
"250 CWD command successful."
"500 EPSV not understood."
"200 PORT command successful"
"150 Opening ASCII mode data connection for tt.txt (7487 bytes)"
"226 Transfer complete."
"200 PORT command successful"
** exited: {{function_clause,[{inet,tcp_close,[{lsock,#Port<0.123>}]},
                               {ftp,do_termiante,2},
                               {gen_server,terminate,6},
(Continue reading)

Serge Aleynikov | 23 Aug 23:19 2005
Picon
Picon

Re: inets ftp bug

Actually, there seems to be one more (at least :-( ) issue with the 
ftp.erl.  With the applied patch there is no more exception raised, but 
the second transfer of a file doesn't happen if you run the code outside 
of the debugger.

When running with a debugger, I get:

~/tmp/dirtest>erl
Erlang (BEAM) emulator version 5.4.8 [source] [hipe] [threads:0]

Eshell V5.4.8  (abort with ^G)
1> i:ii(ftp).
{module,ftp}
2> i:ib(ftp, activate_data_connection, 1).
ok
3> debugger:start().
{ok,<0.36.0>}
4> ftp_test:test("localhost", "serge", "...", "/home/serge/tmp/data", 
"cust_group.txt").
"220 ProFTPD 1.2.6 Server (DevLinuxPro FTP) [devlinuxpro.mis.idt.net]"
"331 Password required for serge."
"230 User serge logged in."
"250 CWD command successful."
"500 EPSV not understood."
"200 PORT command successful"
"150 Opening ASCII mode data connection for cust_group.txt (7487 bytes)"
"226 Transfer complete."
"150 Opening ASCII mode data connection for cust_group.txt (7487 bytes)"
ok

(Continue reading)

Ingela Anderton | 24 Aug 08:39 2005
Picon
Picon

Re: inets ftp bug


Actually this is an already known and fixed problem in inets-4.5.2

Realeasnotes says:

[ftp, client] Calling ftp:recv/2 twice on the same connection failed
due to that the last message on the ctrl channel was not appropriately
taken care of. This could potentially cause a problem for any
operation performed on the same connection where there had previously
been an ftp:recv/2 call. Also, in some cases, when the process tries
to close the data connection, it does not take into account that the
data connection may actually not have been established.

This will definitely be part of the next open source release. We are
actually working on inets-4.5.3 at the moment that will fix some more
bugs and add some new nice features to the inets components (not only
ftp). The aim is that this version should be the one in the next open
source release.

Serge Aleynikov wrote:
> OTP team:
> 
> I found a bug in the inets' ftp.erl client that can be patched by 
> applying the ftp.erl.patch file to the source.
> 
> The bug is seen when you try to download more than one file in a row 
> using ftp:recv/2 function.  For some reason this bug doesn't occur when 
> tracing is enabled (and/or debugger application is running).
> 
> Use the following to reproduce the bug:
(Continue reading)

Serge Aleynikov | 24 Aug 00:43 2005
Picon
Picon

Re: inets ftp bug

OTP team:

This is my second attempt to fix the issue with inets' ftp.erl, which 
seems to be more involved than I initially thought.  In this version of 
ftp.erl ftp:recv/2 seems to be working correctly, however, I am not 
quite sure that this fix covered all errors in the implementation (which 
IMHO is quite messy), and would prefer if one of the authors would take 
a look at it.

 > ftp_test:test("localhost", "serge", "...", "/home/serge/tmp/data", 
"dial_code.txt").
"220 ProFTPD 1.2.6 Server (DevLinuxPro FTP) [devlinuxpro.mis.idt.net]"
"331 Password required for serge."
"230 User serge logged in."
"250 CWD command successful."
"500 EPSV not understood."
"200 PORT command successful"
"150 Opening ASCII mode data connection for dial_code.txt (5271838 bytes)"
"226 Transfer complete."
"200 PORT command successful"
"150 Opening ASCII mode data connection for dial_code.txt (5271838 bytes)"
"226 Transfer complete."
ok

Regards,

Serge

Serge Aleynikov wrote:
> Actually, there seems to be one more (at least :-( ) issue with the 
(Continue reading)

Ulf Wiger (AL/EAB | 31 Aug 14:15 2005
Picon

arguments after --


Snipped from the 'erl' documentation:

  "-- 
	Any arguments following -- will not be interpreted in any way.
	They can be retrieved by init:get_plain_arguments/0. 
	The exception is arguments starting with a +, which will be
	interpreted as system flags (see below). "

but some experimentation shows that it doesn't work as advertised:

$ erl -boot start_clean -sname foo 
Erlang (BEAM) emulator version 5.4.7 [hipe] [threads:0] [kernel-poll]

Eshell V5.4.7  (abort with ^G)
(foo <at> ws12858)1> application:get_env(kernel,net_ticktime).
undefined
(foo <at> ws12858)2> 
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution
a
$ erl -boot start_clean -sname foo -kernel net_ticktime 60
Erlang (BEAM) emulator version 5.4.7 [hipe] [threads:0] [kernel-poll]

Eshell V5.4.7  (abort with ^G)
(foo <at> ws12858)1> application:get_env(kernel,net_ticktime).
{ok,60}
(foo <at> ws12858)2> 
BREAK: (a)bort (c)ontinue (p)roc info (i)nfo (l)oaded
       (v)ersion (k)ill (D)b-tables (d)istribution
(Continue reading)


Gmane