From mickael.remond@REDACTED Fri Mar 3 19:09:28 2006 From: mickael.remond@REDACTED (Mickael Remond) Date: Fri, 3 Mar 2006 19:09:28 +0100 Subject: Mnesia Crash Dump Message-ID: <20060303180928.GA1214@memphis.process-one.net> Hello, I get the following Mnesia crash dump when generating a database from one of our installers. I think this crash has happens several times and was not happening in Erlang/OTP R10B-6. Please, contact me if you need extra details. Cheers, -- Micka?l R?mond http://www.process-one.net/ -------------- next part -------------- A non-text attachment was scrubbed... Name: MnesiaCore.default@REDACTED Type: application/x-gunzip Size: 7175 bytes Desc: not available URL: From ulf.wiger@REDACTED Fri Mar 3 21:47:49 2006 From: ulf.wiger@REDACTED (Ulf Wiger (AL/EAB)) Date: Fri, 3 Mar 2006 21:47:49 +0100 Subject: Mnesia Crash Dump Message-ID: It looks as if mnesia is unable to locate your mnesia directory - or rather, it's not where it's supposed to be: {mnesia_dir,"/home/mremond/ejabberd-nero/database/default", {error,enoent}}, (the core dump can be read by doing the following in an erlang shell: {ok,Bin} = file:read_file(".../MnesiaCore@REDACTED"). binary_to_term(Bin). /Ulf W > -----Original Message----- > From: owner-erlang-bugs@REDACTED > [mailto:owner-erlang-bugs@REDACTED] On Behalf Of Mickael Remond > Sent: den 3 mars 2006 19:09 > To: erlang-bugs@REDACTED > Subject: Mnesia Crash Dump > > Hello, > > I get the following Mnesia crash dump when generating a > database from one of our installers. > I think this crash has happens several times and was not > happening in Erlang/OTP R10B-6. > > Please, contact me if you need extra details. > > Cheers, > > -- > Micka?l R?mond > http://www.process-one.net/ > From mickael.remond@REDACTED Sat Mar 4 10:32:34 2006 From: mickael.remond@REDACTED (=?ISO-8859-1?Q?Micka=EBl_R=E9mond?=) Date: Sat, 4 Mar 2006 10:32:34 +0100 Subject: Mnesia Crash Dump In-Reply-To: References: Message-ID: <8344168F-FAB1-478B-9E29-038D13B30BCE@process-one.net> Le 3 mars 06 ? 21:47, Ulf Wiger ((AL/EAB)) a ?crit : > > It looks as if mnesia is unable to locate your > mnesia directory - or rather, it's not where it's > supposed to be: > > {mnesia_dir,"/home/mremond/ejabberd-nero/database/default", > {error,enoent}}, > > (the core dump can be read by doing the following in > an erlang shell: > > {ok,Bin} = file:read_file(".../MnesiaCore@REDACTED"). > binary_to_term(Bin). Hello, I did not know that :-) So it seems it is my mistake, sorry for the false alarm. Do you know what are the rules that trigger the generation of a Mnesia Core ? I would have expected to see this kind of user error in the log and, before this mail, thought that Mnesia were dumped on internal problem. Anyway, thank you very much ! -- Micka?l R?mond From ulf@REDACTED Sat Mar 4 10:58:40 2006 From: ulf@REDACTED (Ulf Wiger) Date: Sat, 04 Mar 2006 10:58:40 +0100 Subject: Mnesia Crash Dump In-Reply-To: <8344168F-FAB1-478B-9E29-038D13B30BCE@process-one.net> References: <8344168F-FAB1-478B-9E29-038D13B30BCE@process-one.net> Message-ID: Den 2006-03-04 10:32:34 skrev Micka?l R?mond : > Do you know what are the rules that trigger the generation of a Mnesia > Core ? I haven't really studied it, but I think it's any time there's an internal crash in mnesia. > I would have expected to see this kind ofuser error in the log and, > before this mail, thought that Mnesia were dumped on internal problem. I agree that one would expect this kind of error to be logged as a user error, rather than dumping core. /Ulf W -- Ulf Wiger From johanc@REDACTED Thu Mar 9 09:27:45 2006 From: johanc@REDACTED (Johan Carlsson) Date: Thu, 09 Mar 2006 09:27:45 +0100 Subject: Network error (socket error) on Windows XP SP2 Message-ID: <440FE701.2090100@torped.se> >Submitter-Id: johanc@REDACTED >Originator: Johan Carlsson >Organization: Colliberty >Confidential: no >Synopsis: Network error on Windows XP SP2 >Severity: critical >Priority: high >Category: Network, socket, Windows XP SP2 >Class: sw-bug >Release: OTP R10B, Erlang 5.4.13 >Environment: HP Compaq nx7010, Windows XP SP2 >Description: All attempts to use the networks fail. (see description) >How-To-Repeat: %%from the shell: 1> gentcp:listen(). {error,enotsock} %%Or if I try to start a distributed node from a command shell c:\erl> erl -sname master1 >Fix: No fix so far. -- Johan Carlsson Colliberty Torsgatan 72 113 37 Stockholm tele: +46-8-31 24 94 mobl: +46-70-558 25 24 mail: johanc@REDACTED webb: http://www.easypublisher.com From johanc@REDACTED Thu Mar 9 18:45:09 2006 From: johanc@REDACTED (Johan Carlsson) Date: Thu, 09 Mar 2006 18:45:09 +0100 Subject: Network error (socket error) on Windows XP SP2 Message-ID: <441069A5.9060309@torped.se> >Submitter-Id: johanc@REDACTED >Originator: Johan Carlsson >Organization: Colliberty >Confidential: no >Synopsis: Network error on Windows XP SP2 >Severity: critical >Priority: high >Category: Network, socket, Windows XP SP2 >Class: sw-bug >Release: OTP R10B, Erlang 5.4.13 >Environment: HP Compaq nx7010, Windows XP SP2 >Description: All attempts to use the networks fail. (see description) >How-To-Repeat: %%from the shell: 1> gentcp:listen(). {error,enotsock} %%Or if I try to start a distributed node from a command shell c:\erl> erl -sname master1 >Fix: No fix so far. -- Johan Carlsson Colliberty Torsgatan 72 113 37 Stockholm tele: +46-8-31 24 94 mobl: +46-70-558 25 24 mail: johanc@REDACTED webb: http://www.easypublisher.com From johan@REDACTED Tue Mar 14 07:24:06 2006 From: johan@REDACTED (Johan Montelius) Date: Tue, 14 Mar 2006 07:24:06 +0100 Subject: No subject Message-ID: I encountered this bug while accessing a HTTP server. A GET 1.0 request resulted in a reply divided up into several TCP packets. As pointed out by Per Hedland, the last packet also carried the FIN flag. It could be that this is part of the problem. The call to gen_tcp:recv should however return all data regardless if the FIN flag is in the last data packet or in a separate packet. The problem is probably OS-related, I'm running: Windows XP Professional SP2 Erlang V 5.4.13 I've tried to reconstruct the senario with the tcpbug. Tried to set {dealy_send, true} on the server so that the last data segment is buffered and only sent when the socket was closed. A better approach woudlof course be to generate the data packet manually. The server is sending one packet with 1500 bytes, the reciever has a recbuf of 100 bytes (don't know how important this is nor why I get 1024 bytes in the first read). 8>tcpbug:cli(3481). Got 1024 bytes Got {error,closed} ok 9> tcpbug:cli(3483). Got 1024 bytes Got 476 bytes Got {error,closed} ok 10> tcpbug:cli(3485). Got 1024 bytes Got 476 bytes Got {error,closed} ok 11> tcpbug:cli(3487). Got 1024 bytes Got {error,closed} ok 12> tcpbug:cli(3489). Got 1024 bytes Got 476 bytes Got {error,closed} ok 13> tcpbug:cli(3491). Got 1024 bytes Got 476 bytes Got {error,closed} ok 14> tcpbug:cli(3493). Got 1024 bytes Got {error,closed} ok 15> My guess is that the bug has to do with how the WinSOck API is used. Looking at the Erlang src gen_tcp:recv/3 calls inet_db:lookup_socket/1 to see where the socket belongs or if it is closed ....? I guess this is where it detects that the socket is closed? If is reports that the socket is closed while there is still data in the Erlang socket buffer this is an error. Afaik, the WinSock API shoudl not report closed if there is still data in the WinSock buffer. What happens in erlang:get_port_data/1? 8<------------------------------------------------------------------------ -module(tcpbug). -export([srv/0, cli/1]). srv() -> {ok, S} = gen_tcp:listen(0, [{delay_send, true}]), {ok, P} = inet:port(S), io:format("Listen port: ~w~n", [P]), srv_loop(S). srv_loop(S) -> {ok, A} = gen_tcp:accept(S), gen_tcp:send(A, lists:duplicate(1500, $A)), gen_tcp:close(A). cli(P) -> {ok, S} = gen_tcp:connect("localhost", P, [list, {recbuf, 100}, {packet,0}, {active, false}]), cli_loop(S). cli_loop(S) -> case gen_tcp:recv(S, 0, 40000) of {ok, L} -> io:format("Got ~w bytes~n", [length(L)]), sleep(500), % parsing... cli_loop(S); R -> io:format("Got ~p~n", [R]) end, gen_tcp:close(S). sleep(T) -> receive after T -> ok end. -- Johan Montelius From vlad.xx.dumitrescu@REDACTED Wed Mar 15 13:00:06 2006 From: vlad.xx.dumitrescu@REDACTED (Vlad Dumitrescu XX (LN/EAB)) Date: Wed, 15 Mar 2006 13:00:06 +0100 Subject: Jinterface addition Message-ID: <11498CB7D3FCB54897058DE63BE3897C015D7571@esealmw105.eemea.ericsson.se> Hi, Here is an addition to OtpEpmd.java, allowing programs to retrieve the list of registered nodes. best regards, Vlad public static String[] lookupNames() throws IOException { Socket s = null; try { OtpOutputStream obuf = new OtpOutputStream(); s = new Socket(InetAddress.getLocalHost(), epmdPort); obuf.write2BE(1); obuf.write1(names4req); // send request obuf.writeTo(s.getOutputStream()); if (traceLevel >= traceThreshold) System.out.println("-> NAMES (r4) "); // get reply byte[] tmpbuf = new byte[1024]; int n = s.getInputStream().read(tmpbuf); if (n < 0) { // this was an r3 node => not a failure (yet) if (s != null) s.close(); throw new IOException("Nameserver not responding when requesting names"); } OtpInputStream ibuf = new OtpInputStream(tmpbuf); int port = ibuf.read4BE(); byte[] buf = new byte[n-4]; System.arraycopy(tmpbuf, 4, buf, 0, n-4); String all = new String(buf); return all.split("\n"); } catch (IOException e) { // epmd closed the connection = fail if (s != null) s.close(); if (traceLevel >= traceThreshold) System.out.println("<- (no response)"); throw new IOException("Nameserver not responding when requesting names"); } catch (OtpErlangDecodeException e) { if (s != null) s.close(); if (traceLevel >= traceThreshold) System.out.println("<- (invalid response)"); throw new IOException("Nameserver not responding when requesting names"); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From mickael.remond@REDACTED Wed Mar 15 13:53:41 2006 From: mickael.remond@REDACTED (Mickael Remond) Date: Wed, 15 Mar 2006 13:53:41 +0100 Subject: Jinterface addition In-Reply-To: <11498CB7D3FCB54897058DE63BE3897C015D7571@esealmw105.eemea.ericsson.se> References: <11498CB7D3FCB54897058DE63BE3897C015D7571@esealmw105.eemea.ericsson.se> Message-ID: <20060315125341.GA18262@memphis.ilius.fr> * Vlad Dumitrescu XX (LN/EAB) [2006-03-15 13:00:06 +0100]: > Hi, > > Here is an addition to OtpEpmd.java, allowing programs to retrieve the > list of registered nodes. Hello, I take the opportunity to submit another JInterface patch, developed by a coworker (Nicolas Blanc). GenericQueue has been patched to add a method to get a non-synchronized compteur for the number of object in the queue. This information is moving a lot and synchronisation does not seem relevant in this case. If you want to take decision based on the result of this function if will most likely have changed in the meantime. The method getCount has also been added to OtpMbox to get the number of messages waiting in a mailbox. It uses the method getUnsynchronizedCount of GenericQueue. I hope this helps, -- Micka?l R?mond http://www.process-one.net/ -------------- next part -------------- --- GenericQueue.java.orig 2006-03-10 10:11:09.000000000 +0100 +++ GenericQueue.java 2006-03-06 16:11:54.000000000 +0100 @@ -143,6 +143,10 @@ return count; } + public int getUnsynchronizedCount() { + return count; + } + /* * The Bucket class. The queue is implemented as a linked list * of Buckets. The container holds the queued object and a -------------- next part -------------- --- OtpMbox.java.orig 2006-03-10 10:11:10.000000000 +0100 +++ OtpMbox.java 2006-03-06 16:12:18.000000000 +0100 @@ -648,4 +648,8 @@ } } } + + public int getCount() { + return this.queue.getUnsynchronizedCount(); + } } From ft@REDACTED Tue Mar 21 14:59:32 2006 From: ft@REDACTED (Fredrik Thulin) Date: Tue, 21 Mar 2006 14:59:32 +0100 Subject: Terminating application during startup Message-ID: <200603211459.32100.ft@it.su.se> Hi I have a problem with getting my application to terminate nicely when an error occurs during startup. I have done some serious testing here and discovered that the problem is with reason strings longer than exactly 30 characters. The problem can be seem with the attached example application, compiled like this : $ /pkg/erlang/R10B-10/bin/erlc my.erl $ /pkg/erlang/R10B-10/bin/erlc my.rel Booting 'my' with '-extra short' works (meaning the erlang VM terminates), '-extra long' gives an ugly error message and the erlang VM never terminates! $ /pkg/erlang/R10B-10/bin/erl -boot my -noshell -extra short =INFO REPORT==== 21-Mar-2006::14:48:14 === application: my exited: {"123456789012345678901234567890",{my,start,[normal,[foo]]}} type: permanent {"Kernel pid terminated",application_controller,"{application_start_failure,my, {[49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48], {my,start,[normal,[foo]]}}}"} Crash dump was written to: erl_crash.dump Kernel pid terminated (application_controller) ({application_start_failure,my, {[49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48], {my,start,[normal,[foo]]}}}) $ /pkg/erlang/R10B-10/bin/erl -boot my -noshell -extra long =INFO REPORT==== 21-Mar-2006::14:48:19 === application: my exited: {"1234567890123456789012345678901",{my,start,[normal, [foo]]}} type: permanent {"Kernel pid terminated",application_controller,"{application_start_failure,my, {[49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48,49], {my,start,[normal,[foo]]}}}"} {error_logger,{{2006,3,21},{14,48,21}},'~s~n',['Error in process <0.0.0> with exit value: {badarg,[{erlang,halt,["Kernel pid terminated (application_controller) ({application_start_failure,my, {[49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48,49,50,51,52,53,54,55,56,57,48,49], {m... \n']} /Fredrik PS. Does anyone have alternate suggestions about how to get your application to terminate on startup problems? The '-extra short' output isn't very appealing either with the big "Kernel pid terminated" tuple outputted. I'd rather not have an erl_crash.dump file written for all occasions either. Non-zero exit-status is necessary. -------------- next part -------------- {application, my, [{description, "Test app"}, {vsn,"0.0"}, {modules, [ my ]}, {registered, []}, {mod, {my, [foo]}}, {env, []}, {applications, [kernel, stdlib]}]}. -------------- next part -------------- -module(my). -export([start/2]). start(normal, [foo]) -> case init:get_plain_arguments() of ["short"] -> {error, "123456789012345678901234567890"}; ["long"] -> {error, "1234567890123456789012345678901"} end. -------------- next part -------------- {release, {"Test app","0.0"}, {erts, "5.2"}, [{kernel,"2.10.13"}, {stdlib,"1.13.12"}, {ssl, "3.0.11"}, {mnesia, "4.2.5"}, {my, "0.0"} ]}. From raimo@REDACTED Thu Mar 23 15:32:02 2006 From: raimo@REDACTED (Raimo Niskanen) Date: 23 Mar 2006 15:32:02 +0100 Subject: Jinterface addition References: <11498CB7D3FCB54897058DE63BE3897C015D7571@esealmw105.eemea.ericsson.se> Message-ID: Thank you for the patch. We will have a look at it. It is not certain it will make it into R11B, though... vlad.xx.dumitrescu@REDACTED (Vlad Dumitrescu XX LN/EAB) writes: > Hi, > > Here is an addition to OtpEpmd.java, allowing programs to retrieve the > list of registered nodes. > > best regards, > Vlad > > public static String[] lookupNames() throws IOException > { > Socket s = null; > > try > { > OtpOutputStream obuf = new OtpOutputStream(); > s = new Socket(InetAddress.getLocalHost(), epmdPort); > > obuf.write2BE(1); > obuf.write1(names4req); > > // send request > obuf.writeTo(s.getOutputStream()); > > if (traceLevel >= traceThreshold) > System.out.println("-> NAMES (r4) "); > > // get reply > byte[] tmpbuf = new byte[1024]; > int n = s.getInputStream().read(tmpbuf); > > if (n < 0) > { > // this was an r3 node => not a failure (yet) > if (s != null) > s.close(); > throw new IOException("Nameserver not responding when > requesting names"); > } > > OtpInputStream ibuf = new OtpInputStream(tmpbuf); > > int port = ibuf.read4BE(); > byte[] buf = new byte[n-4]; > System.arraycopy(tmpbuf, 4, buf, 0, n-4); > String all = new String(buf); > return all.split("\n"); > > } catch (IOException e) > { > // epmd closed the connection = fail > if (s != null) > s.close(); > if (traceLevel >= traceThreshold) > System.out.println("<- (no response)"); > throw new IOException("Nameserver not responding when > requesting names"); > } catch (OtpErlangDecodeException e) > { > if (s != null) > s.close(); > if (traceLevel >= traceThreshold) > System.out.println("<- (invalid response)"); > throw new IOException("Nameserver not responding when > requesting names"); > } > } > > -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From binouche22@REDACTED Fri Mar 24 15:41:15 2006 From: binouche22@REDACTED (roger binouche) Date: Fri, 24 Mar 2006 15:41:15 +0100 Subject: [Mnesia] bad error return Message-ID: <791070040603240641s4c114b0ax@mail.gmail.com> If you try to create a schema when mnesia is started, instead of returning an error like "Mnesia is not stopped everywhere" you get "already_exists" as if there would already exist a schema on this node. example: node1@REDACTED 1>mnesia:start(). ok node1@REDACTED 2>mnesia:create_schema([node()]). {error,{'node1@REDACTED',{already_exists,'node1@REDACTED'}}} -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpe@REDACTED Mon Mar 27 13:37:03 2006 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 27 Mar 2006 13:37:03 +0200 (MEST) Subject: [PATCH] HiPE fix for glibc-2.4 / Fedora Core 5 Message-ID: <200603271137.k2RBb3oG023493@harpo.it.uu.se> On Mon, 30 Jan 2006 11:38:10 -0500, Serge Aleynikov wrote: >We ran into the hipe compilation issue (R10B-9) on Linux Fedora related >to the newer GLIBC version. > >$ uname -a >Linux stardev1.corp.idt.net 2.6.15-1.1881_FC5.idtsmp #1 SMP PREEMPT Mon >Jan 30 02:16:35 EST 2006 i686 i686 i386 GNU/Linux > >Installed Packages >glibc.i686 2.3.90-30 > >$ make >... >/home/serge/tmp/otp_src_R10B-9/erts/obj.hybrid.beam/i686-pc-linux-gnu/hipe_x86_signal.o: >In function `my_sigaction':hipe/hipe_x86_signal.c:182: undefined >reference to `INIT' >:hipe/hipe_x86_signal.c:192: undefined reference to `__next_sigaction' >/home/serge/tmp/otp_src_R10B-9/erts/obj.hybrid.beam/i686-pc-linux-gnu/hipe_x86_signal.o: >In function `hipe_signal_init':hipe/hipe_x86_signal.c:225: undefined >reference to `INIT' >/home/serge/tmp/otp_src_R10B-9/erts/obj.hybrid.beam/i686-pc-linux-gnu/hipe_x86_signal.o: >In function `my_sigaction':hipe/hipe_x86_signal.c:182: undefined >reference to `INIT' >:hipe/hipe_x86_signal.c:192: undefined reference to `__next_sigaction' >:hipe/hipe_x86_signal.c:182: undefined reference to `INIT' >:hipe/hipe_x86_signal.c:192: undefined reference to `__next_sigaction' >collect2: ld returned 1 exit status I've tested things on FC5 final which was released a week ago, and I can confirm that the code for glibc-2.3 in hipe_x86_signal.c does work fine for glibc-2.4. The patch that's been committed to the R11 development branch is included below; it should also be applied to R10B-10. /Mikael The HiPE team --- otp-0317/erts/emulator/hipe/hipe_x86_signal.c.~1~ 2005-10-21 14:02:57.000000000 +0200 +++ otp-0317/erts/emulator/hipe/hipe_x86_signal.c 2006-03-27 12:30:08.000000000 +0200 @@ -27,7 +27,7 @@ #include #include "hipe_signal.h" -#if __GLIBC__ == 2 && __GLIBC_MINOR__ == 3 +#if __GLIBC__ == 2 && (__GLIBC_MINOR__ == 3 || __GLIBC_MINOR__ == 4) /* See comment below for glibc 2.2. */ #ifndef __USE_GNU #define __USE_GNU /* to un-hide RTLD_NEXT */