From camuig@REDACTED Fri Aug 1 08:47:30 2008 From: camuig@REDACTED (camui) Date: Fri, 1 Aug 2008 10:47:30 +0400 Subject: [erlang-bugs] Connection via ODBC Message-ID: <3df44f150807312347l35bc066fsf06a4734b492dce0@mail.gmail.com> Hi, I have posted about this problem in erlang-questions mailing lists. http://erlang.org/pipermail/erlang-questions/2008-July/036656.html ---------------- "I have a problem with connection to the remote database via ODBC in Erlang. 1> odbc:connect("DSN=pg", [{scrollable_cursors, off}]). {error,{{badmatch,{error,eafnosupport}}, [{odbc,init,1},{gen_server,init_it,6},{proc_lib,init_p,5}]}} The database is located on another machine in the local network. I have tried to connect to this database in the OpenOffice Base (using ODBC) and there are no problems. And I had not any troubles with connection in Erlang on the machine where database is located." ---------------- I am not sure it is a bug, but I have trouble with connection only in erlang. PS: Sorry for my english Andrey. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Fri Aug 1 09:14:28 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Fri, 01 Aug 2008 09:14:28 +0200 Subject: [erlang-bugs] Connection via ODBC In-Reply-To: <3df44f150807312347l35bc066fsf06a4734b492dce0@mail.gmail.com> References: <3df44f150807312347l35bc066fsf06a4734b492dce0@mail.gmail.com> Message-ID: <4892B7D4.5060209@erix.ericsson.se> camui wrote: > Hi, > > I have posted about this problem in erlang-questions mailing lists. > http://erlang.org/pipermail/erlang-questions/2008-July/036656.html > Well yes, and I posted an answer to this question http://erlang.org/pipermail/erlang-questions/2008-July/036994.html Even though the archive seems to have lost the thread information somehow... Sockets are used internally to communicate between erlang and c as some odbc-drivers mess with standard fildescriptors rendering the normal "erlang-port-program-communication" to malfunction. And this code is general to work with both ipv4 and ipv6 hence my guess at what might be the problem. Regards Ingela Erlang/OTP, Ericsson > ---------------- > "I have a problem with connection to the remote database via ODBC in > Erlang. > > 1> odbc:connect("DSN=pg", [{scrollable_cursors, off}]). > {error,{{badmatch,{error,eafnosupport}}, > [{odbc,init,1},{gen_server,init_it,6},{proc_lib,init_p,5}]}} > > The database is located on another machine in the local network. > I have tried to connect to this database in the OpenOffice Base (using > ODBC) > and there are no problems. And I had not any troubles with connection in > Erlang on the machine where database is located." > ---------------- > > I am not sure it is a bug, but I have trouble with connection only in > erlang. > > PS: Sorry for my english > > Andrey. > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From camuig@REDACTED Fri Aug 1 09:35:47 2008 From: camuig@REDACTED (camui) Date: Fri, 1 Aug 2008 11:35:47 +0400 Subject: [erlang-bugs] Connection via ODBC In-Reply-To: <4892B7D4.5060209@erix.ericsson.se> References: <3df44f150807312347l35bc066fsf06a4734b492dce0@mail.gmail.com> <4892B7D4.5060209@erix.ericsson.se> Message-ID: <3df44f150808010035h5e4bd600i5357630f19903afe@mail.gmail.com> Thank you very much, Ingela! Your post helped me. It is a pity that it was lost and I did not see it earlier. The IPv6 support was disabled... 2008/8/1, Ingela Anderton Andin : > > camui wrote: > >> Hi, >> >> I have posted about this problem in erlang-questions mailing lists. >> http://erlang.org/pipermail/erlang-questions/2008-July/036656.html >> >> > Well yes, and I posted an answer to this question > http://erlang.org/pipermail/erlang-questions/2008-July/036994.html > > Even though the archive seems to have lost the thread information > somehow... > > Sockets are used internally to communicate between erlang and c as > some odbc-drivers mess with standard fildescriptors rendering the > normal "erlang-port-program-communication" to malfunction. And this code is > general to work with both ipv4 and ipv6 hence my > guess at what might be the problem. > > Regards Ingela Erlang/OTP, Ericsson > >> ---------------- >> "I have a problem with connection to the remote database via ODBC in >> Erlang. >> >> 1> odbc:connect("DSN=pg", [{scrollable_cursors, off}]). >> {error,{{badmatch,{error,eafnosupport}}, >> [{odbc,init,1},{gen_server,init_it,6},{proc_lib,init_p,5}]}} >> >> The database is located on another machine in the local network. >> I have tried to connect to this database in the OpenOffice Base (using >> ODBC) >> and there are no problems. And I had not any troubles with connection in >> Erlang on the machine where database is located." >> ---------------- >> >> I am not sure it is a bug, but I have trouble with connection only in >> erlang. >> >> PS: Sorry for my english >> >> Andrey. >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rickard.s.green@REDACTED Mon Aug 4 17:50:14 2008 From: rickard.s.green@REDACTED (Rickard Green) Date: Mon, 04 Aug 2008 17:50:14 +0200 Subject: [erlang-bugs] erts_port[].drv_ptr == 0, when erts_port[].status not free In-Reply-To: <20080703155957.GB5148@erix.ericsson.se> References: <1214958245.16472.46.camel@localhost> <20080703155957.GB5148@erix.ericsson.se> Message-ID: <48972536.1040002@ericsson.com> Hi Paul, Thanks for the bug report. The attached patch should fix the problem. This fix will be included in R12B-4. How to apply the patch: $ gtar -zxf otp_src_R12B-3.tar.gz $ gpatch -ZNp0 < OTP-7464.patch patching file otp_src_R12B-3/erts/emulator/beam/io.c $ # Build and install as usual BR, Rickard Green, Erlang/OTP, Ericsson AB. Raimo Niskanen wrote: > Thank you for your bug report. > > We will look into your problem when the concerned developers > comes in after their vacation. > > Can you give us host OS and Erlang release too? > > > > On Tue, Jul 01, 2008 at 07:24:05PM -0500, Paul Fisher wrote: >> We have a system where we run lots of linked-in driver ports that get >> created/used/closed frequently and sometimes very quickly. Today when >> several open_port/2, port_command/2 and port_close/1 cycles happened >> rapid succession, a SIGSEGV occurrect in erl_bif_ddl.c: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 1125235040 (LWP 12087)] >> 0x0000000000449712 in erl_ddll_try_unload_2 (p=0x2aaaab11fc90, >> name_term=659339, options=46912503328425) at beam/erl_bif_ddll.c:592 >> >> The emulator was run on a Q6600 (quad-core, 2.4Ghz), and started with +A >> 8, >> and the linked-in driver executes the bulk of its work with >> driver_async(). >> There were continuously 8 driver cycles running for 5-10 seconds before >> the >> segfault occurred. >> >> ???(gdb) where >> #0 0x0000000000449712 in erl_ddll_try_unload_2 (p=0x2aaaab11fc90, >> name_term=659339, options=46912503328425) at beam/erl_bif_ddll.c:592 >> #1 0x000000000052337f in process_main () at beam/beam_emu.c:2073 >> #2 0x000000000049c213 in sched_thread_func (vesdp=0x2ae18cb74f98) >> at beam/erl_process.c:741 >> #3 0x00000000005b6818 in thr_wrapper (vtwd=0x7fff1eb77de0) >> at common/ethread.c:474 >> #4 0x00002ae18c530f1a in start_thread () from /lib/libpthread.so.0 >> #5 0x00002ae18c8135d2 in clone () from /lib/libc.so.6 >> #6 0x0000000000000000 in ?? () >> >> So the code at the point of the SIGSEGV @ erl_bif_ddll.c:592 says: >> >> for (j = 0; j < erts_max_ports; j++) { >> => if (!(erts_port[j].status & FREE_PORT_FLAGS) >> && erts_port[j].drv_ptr->handle == dh) { >> >> It appears that the code assumes that if the erts_port array entry being >> evaluated during the search has a valid (non-zero) drv_ptr value, if the >> entry is not marked as free. At the time of the crash, this is clearly >> not >> the case: >> >> (gdb) p j >> $8 = 896 >> >> (gdb) p erts_port[j] >> $7 = {sched = {next = 0x0, prev = 0x0, taskq = 0x0, exe_taskq = 0x0}, >> timeout_task = {counter = 0}, refc = {counter = 2}, lock = 0x81b3c8, >> xports = 0x0, id = 14343, connected = 0, caller = 0, data = 0, bp = >> 0x0, >> nlinks = 0x0, monitors = 0x0, bytes_in = 0, bytes_out = 0, ptimer = >> 0x0, >> tracer_proc = 18446744073709551611, trace_flags = 0, ioq = {size = 0, >> v_start = 0x0, v_end = 0x0, v_head = 0x0, v_tail = 0x0, v_small = {{ >> iov_base = 0x0, iov_len = 0}, {iov_base = 0x0, iov_len = 0}, { >> iov_base = 0x0, iov_len = 0}, {iov_base = 0x0, iov_len = 0}, { >> iov_base = 0x0, iov_len = 0}}, b_start = 0x0, b_end = 0x0, >> b_head = 0x0, b_tail = 0x0, b_small = {0x0, 0x0, 0x0, 0x0, 0x0}}, >> dist_entry = 0x0, name = 0x0, drv_ptr = 0x0, drv_data = 0, suspended = >> 0x0, >> linebuf = 0x0, status = 4096, control_flags = 0, reg = 0x0, >> port_data_lock = 0x0} >> >> (gdb) p erts_port[j].drv_ptr >> $6 = (ErlDrvEntry *) 0x0 >> >> >> So the real questions are: 1) is whether the assumption built into this >> code is correct; and 2) if so, how did we get in the position of >> violating >> it. I'd appreciate some insight into what could be going on here, and >> where I should can start looking. >> >> >> -- >> paul >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- A non-text attachment was scrubbed... Name: OTP-7464.patch Type: text/x-patch Size: 1145 bytes Desc: not available URL: From jmeredith@REDACTED Tue Aug 5 00:07:58 2008 From: jmeredith@REDACTED (Jon Meredith) Date: Mon, 4 Aug 2008 16:07:58 -0600 Subject: [erlang-bugs] dbg:tracer() aborts on binary match Message-ID: Hi, I'm writing a small parser for reading log lines. When it didn't do what I expected I tried to use dbg:tracer() to see where it was going wrong and it aborted. Here is the cut down minimal test case. I'm expecting it to match and then try and call parse_headers with Hdr added to the Hdrs list, but instead the VM aborts. Am I doing something wrong/strange? Many thanks, Jon. %% Abort when running dbg:tracer(). %% %% 1> binbug:bug(). %% size_object: matchstate term not allowedAbort trap -module(binbug). -export([bug/0, parse_headers/4]). parse_headers(<<"\\r\\n", T/binary>>, Hdr, Hdrs, Toks) -> parse_headers(T, <<>>, [Hdr | Hdrs], Toks). bug() -> dbg:tracer(), dbg:p(all, call), dbg:tpl(?MODULE, []), parse_headers(<<"\\r\\n]">>, <<"hdr1">>, [], []). From bjorn@REDACTED Tue Aug 5 10:07:09 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 05 Aug 2008 10:07:09 +0200 Subject: [erlang-bugs] dbg:tracer() aborts on binary match In-Reply-To: References: Message-ID: Jon Meredith writes: > Hi, > > I'm writing a small parser for reading log lines. When it didn't do > what I expected I tried to use dbg:tracer() to see where it was going > wrong and it aborted. Here is the cut down minimal test case. Thanks! A correction for this bug will be included in R12B-4. I have attached a patch in case you need a correction before that. /Bjorn -------------- next part -------------- A non-text attachment was scrubbed... Name: bin_syntax_trace.patch Type: text/x-patch Size: 2658 bytes Desc: Correction for binary syntax/trace problem URL: -------------- next part -------------- -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From fredrik.svahn@REDACTED Tue Aug 5 10:34:17 2008 From: fredrik.svahn@REDACTED (Fredrik Svahn) Date: Tue, 5 Aug 2008 10:34:17 +0200 Subject: [erlang-bugs] out of memory and crash when using linebuf io Message-ID: Hi, I knew that the new regexp library ("re") in Erlang/OTP R12B-3 is fast. But I wanted to know just how fast "erlgrep" could be compared to the well-known unix grep which has been around since 1973. My input file was quite big (about 980 Mb) and in the first attempt it took some 30 minutes for my io:get_line-based program to scan through the input compared to 8 minutes for grep. However, I quickly discovered that io was the bottleneck rather than the regexps. Also to my surprise, the beam process grew until it had a resident size of 950 Mb (according to top). Not quite what I had hoped for. I wonder what would have happened on my machine with 2 Gb RAM if the file had been three times the size? I then tried the well-known "open_port({fd,0,1}, [eof,binary,line])" approach, and ended up in a program that quickly grew until there was no memory left (>1.2 Gb before top stopped working) and then *completely* locking up the computer for some 20 minutes before I finally managed to take beam down by force. I believe the later issue is the same that was discussed a about a year ago by Ulf Wiger and others and the suggestion then was to add some kind of flow control to line oriented port io. So I hereby humbly submit a patch to add some very very basic flow control. I am sure that more skilled designers can easily improve it to also handle io:get_line() on large files without beam growth. I am also sure there is a corner case or two which I have not thought of. This is arguably not a bug since piping big chunks of data into beam was not what the system originally was built for, but I am still hoping to get away with sending it to erlang-bugs and getting it in since: a) It has been experienced by others as well that it is easy to crash beam if you have big piped input files b) Currently there is no *fast* way to read data from stdin without risking beam growth/crash - this is a serious limitation c) I have provided a patch (which also seems to keep the memory consumption at more normal levels) *** erts/emulator/beam/io.c.old 2008-08-01 00:29:16.000000000 +0200 --- erts/emulator/beam/io.c 2008-08-04 22:26:00.000000000 +0200 *************** static void missing_drv_callback(Port *p *** 2437,2447 **** --- 2437,2472 ---- void erts_port_ready_input(Port *p, ErlDrvEvent hndl) { + Process *rp = NULL; + ErtsProcLocks rp_locks = ERTS_PROC_LOCK_MSGQ; + ERTS_SMP_CHK_NO_PROC_LOCKS; ERTS_SMP_LC_ASSERT(erts_lc_is_port_locked(p)); ASSERT((p->status & ERTS_PORT_SFLGS_DEAD) == 0); + /* When using linebuf_io there is a risk of ending up with an ever growing + * message queue in the connected process since there is no flow control + * and we usually end up with many small messages instead of one large. + + * The obvious disadvantage with the simple flow control below is that a + * message queue which has grown for other reasons than io may temporarily + * stop io messages to the controlling process. On the other hand if we + * have a message queue of 4*ERL_MESSAGE_BUF_SZ then it is not helping us + * to fill it up with even more messages. + + * With this patch at least we will not run out of memory and crash, and + * this makes it easier to analyse the problem... */ + + if (p->status & ERTS_PORT_SFLG_LINEBUF_IO) { + rp = erts_pid2proc(NULL, 0, p->connected, rp_locks); + if (rp) { + int mq_too_long = rp->msg.len > 4*ERL_MESSAGE_BUF_SZ; + erts_smp_proc_unlock(rp, rp_locks); + if (mq_too_long) return; + } + } + if (!p->drv_ptr->ready_input) missing_drv_callback(p, hndl, DO_READ); else { BR /Fredrik PS. So how did the new re library match up to grep with the above patch? Quite well I would say. Almost two minutes faster than grep (using the mmap option to grep only made a few seconds difference). Even though I knew re was fast from previous experiments I was quite pleasantly surprised. It is still using more memory than grep, for sure, but still, I am willing to make that trade-off in this case. $ time otp_src_R12B-3/bin/erl -smp disable -user logreader < /tmp/messages.4 > output2.txt real 6m16.410s user 6m12.910s sys 0m3.220s $ time grep -E '(Mar|Apr) *[0-9]+ *0(1|2):' < /tmp/messages.4 > output3.txt real 8m17.259s user 8m15.170s sys 0m1.640s $ diff output2.txt output3.txt $ -------------- next part -------------- A non-text attachment was scrubbed... Name: logreader.erl Type: application/octet-stream Size: 544 bytes Desc: not available URL: From ulf.wiger@REDACTED Tue Aug 5 11:10:48 2008 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Tue, 05 Aug 2008 11:10:48 +0200 Subject: [erlang-bugs] out of memory and crash when using linebuf io In-Reply-To: References: Message-ID: <48981918.4070202@ericsson.com> Fredrik Svahn skrev: > PS. So how did the new re library match up to grep with the above > patch? Quite well I would say. Almost two minutes faster than grep > (using the mmap option to grep only made a few seconds difference). > Even though I knew re was fast from previous experiments I was quite > pleasantly surprised. It is still using more memory than grep, for > sure, but still, I am willing to make that trade-off in this case. Pretty impressive payoff for 11 extra lines of code. (: I think that in practice, it should usually be a result of very poor design to have the receiving process also handle large amounts of messages from other sources. BR, Ulf W From bengt.kleberg@REDACTED Tue Aug 5 11:33:01 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Tue, 05 Aug 2008 11:33:01 +0200 Subject: [erlang-bugs] out of memory and crash when using linebuf io In-Reply-To: References: Message-ID: <1217928781.4447.29.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Greetings, It is a good thing to correct the problem with having no flow control for line oriented port io. It would also be (IMHO) a good thing to add the possibility to use standard io with file:read/2 . For best effect this could be done like in io:read/3 . bengt On Tue, 2008-08-05 at 10:34 +0200, Fredrik Svahn wrote: > Hi, > > I knew that the new regexp library ("re") in Erlang/OTP R12B-3 is > fast. But I wanted to know just how fast "erlgrep" could be compared > to the well-known unix grep which has been around since 1973. My input > file was quite big (about 980 Mb) and in the first attempt it took > some 30 minutes for my io:get_line-based program to scan through the > input compared to 8 minutes for grep. However, I quickly discovered > that io was the bottleneck rather than the regexps. Also to my > surprise, the beam process grew until it had a resident size of 950 Mb > (according to top). Not quite what I had hoped for. I wonder what > would have happened on my machine with 2 Gb RAM if the file had been > three times the size? > > I then tried the well-known "open_port({fd,0,1}, [eof,binary,line])" > approach, and ended up in a program that quickly grew until there was > no memory left (>1.2 Gb before top stopped working) and then > *completely* locking up the computer for some 20 minutes before I > finally managed to take beam down by force. > > I believe the later issue is the same that was discussed a about a > year ago by Ulf Wiger and others and the suggestion then was to add > some kind of flow control to line oriented port io. So I hereby humbly > submit a patch to add some very very basic flow control. I am sure > that more skilled designers can easily improve it to also handle > io:get_line() on large files without beam growth. I am also sure there > is a corner case or two which I have not thought of. > > This is arguably not a bug since piping big chunks of data into beam > was not what the system originally was built for, but I am still > hoping to get away with sending it to erlang-bugs and getting it in > since: > > a) It has been experienced by others as well that it is easy to crash > beam if you have big piped input files > b) Currently there is no *fast* way to read data from stdin without > risking beam growth/crash - this is a serious limitation > c) I have provided a patch (which also seems to keep the memory > consumption at more normal levels) > > > *** erts/emulator/beam/io.c.old 2008-08-01 00:29:16.000000000 +0200 > --- erts/emulator/beam/io.c 2008-08-04 22:26:00.000000000 +0200 > *************** static void missing_drv_callback(Port *p > *** 2437,2447 **** > --- 2437,2472 ---- > void > erts_port_ready_input(Port *p, ErlDrvEvent hndl) > { > + Process *rp = NULL; > + ErtsProcLocks rp_locks = ERTS_PROC_LOCK_MSGQ; > + > ERTS_SMP_CHK_NO_PROC_LOCKS; > ERTS_SMP_LC_ASSERT(erts_lc_is_port_locked(p)); > > ASSERT((p->status & ERTS_PORT_SFLGS_DEAD) == 0); > > + /* When using linebuf_io there is a risk of ending up with an ever growing > + * message queue in the connected process since there is no flow control > + * and we usually end up with many small messages instead of one large. > + > + * The obvious disadvantage with the simple flow control below is that a > + * message queue which has grown for other reasons than io may > temporarily > + * stop io messages to the controlling process. On the other hand if we > + * have a message queue of 4*ERL_MESSAGE_BUF_SZ then it is not helping us > + * to fill it up with even more messages. > + > + * With this patch at least we will not run out of memory and crash, and > + * this makes it easier to analyse the problem... */ > + > + if (p->status & ERTS_PORT_SFLG_LINEBUF_IO) { > + rp = erts_pid2proc(NULL, 0, p->connected, rp_locks); > + if (rp) { > + int mq_too_long = rp->msg.len > 4*ERL_MESSAGE_BUF_SZ; > + erts_smp_proc_unlock(rp, rp_locks); > + if (mq_too_long) return; > + } > + } > + > if (!p->drv_ptr->ready_input) > missing_drv_callback(p, hndl, DO_READ); > else { > > > BR /Fredrik > > PS. So how did the new re library match up to grep with the above > patch? Quite well I would say. Almost two minutes faster than grep > (using the mmap option to grep only made a few seconds difference). > Even though I knew re was fast from previous experiments I was quite > pleasantly surprised. It is still using more memory than grep, for > sure, but still, I am willing to make that trade-off in this case. > > > $ time otp_src_R12B-3/bin/erl -smp disable -user logreader < > /tmp/messages.4 > output2.txt > > real 6m16.410s > user 6m12.910s > sys 0m3.220s > > $ time grep -E '(Mar|Apr) *[0-9]+ *0(1|2):' < /tmp/messages.4 > output3.txt > > real 8m17.259s > user 8m15.170s > sys 0m1.640s > > $ diff output2.txt output3.txt > $ > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From jmeredith@REDACTED Tue Aug 5 15:12:42 2008 From: jmeredith@REDACTED (Jon Meredith) Date: Tue, 5 Aug 2008 07:12:42 -0600 Subject: [erlang-bugs] [erlang-questions] dbg:tracer() aborts on binary match In-Reply-To: <4d08db370808050027r4490e568ke21ecdc1d7514c6f@mail.gmail.com> References: <4d08db370808050027r4490e568ke21ecdc1d7514c6f@mail.gmail.com> Message-ID: Hi, Thanks for the response. I'm trying to look for the (unescaped) character string \r\n (0x5c 0x72 0x5c 0x6e) from inside a squid access log with HTTP header information delimited by \r\n. I think I've escaped it correctly. Here's an alternative version with the escaping ambiguity removed. %% Abort when running dbg:tracer(). %% %% 1> binbug:bug(). %% size_object: matchstate term not allowedAbort trap -module(binbug2). -export([bug/0, parse_headers/4]). parse_headers(<<92:8, 114:8, 92:8, 110:8, T/binary>>, Hdr, Hdrs, Toks) -> parse_headers(T, <<>>, [Hdr | Hdrs], Toks). bug() -> dbg:tracer(), dbg:p(all, call), dbg:tpl(?MODULE, []), parse_headers(<<92:8, 114:8, 92:8, 110:8, 10:8>>, <<>>, [], []). Jon On Aug 5, 2008, at 1:27 AM, Hynek Vychodil wrote: > There is wrong escaping off topic. It should be: > > parse_headers(<<"\r\n", T/binary>>, Hdr, Hdrs, Toks) -> > parse_headers(T, <<>>, [Hdr | Hdrs], Toks). > > bug() -> > dbg:tracer(), > dbg:p(all, call), > dbg:tpl(?MODULE, []), > parse_headers(<<"\r\n]">>, <<"hdr1">>, [], []). > > > On Tue, Aug 5, 2008 at 12:07 AM, Jon Meredith > wrote: > Hi, > > I'm writing a small parser for reading log lines. When it didn't do > what I expected I tried to use dbg:tracer() to see where it was going > wrong and it aborted. Here is the cut down minimal test case. > > I'm expecting it to match and then try and call parse_headers with Hdr > added to the Hdrs list, but instead the VM aborts. Am I doing > something wrong/strange? > > Many thanks, Jon. > > %% Abort when running dbg:tracer(). > %% > %% 1> binbug:bug(). > %% size_object: matchstate term not allowedAbort trap > > -module(binbug). > -export([bug/0, > parse_headers/4]). > > parse_headers(<<"\\r\\n", T/binary>>, Hdr, Hdrs, Toks) -> > parse_headers(T, <<>>, [Hdr | Hdrs], Toks). > > bug() -> > dbg:tracer(), > dbg:p(all, call), > dbg:tpl(?MODULE, []), > parse_headers(<<"\\r\\n]">>, <<"hdr1">>, [], []). > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-questions > > > > -- > --Hynek (Pichi) Vychodil -------------- next part -------------- An HTML attachment was scrubbed... URL: From phvander@REDACTED Fri Aug 8 16:03:30 2008 From: phvander@REDACTED (philippe vanderstraeten) Date: Fri, 8 Aug 2008 16:03:30 +0200 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 Message-ID: <12d458770808080703i71c61915g578501f49f5e15f9@mail.gmail.com> Hello , I wanted to know if Erlang otp_src_R12B-2 is supported on PowerPC 64 and RHEL 4 (Red Hat Enterprise Linux AS release 4 (Nahant Update 3)). I started the install script and I got errors at the end: /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel.src > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel /usr/bin/install -c -d /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp ( cd /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp && \ erlc -W -I/home/admin/download/otp_src_R12B-2/lib/kernel/ebin -I/home/admin/download/otp_src_R12B-2/lib/stdlib/ebin -I/home/admin/download/otp_src_R12B-2/lib/sasl/ebin -o /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.rel ) /bin/sh: erlc: command not found make[3]: *** [/home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script] Error 127 make[3]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts/start_scripts' make[2]: *** [release] Error 2 make[2]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts/start_scripts' make[1]: *** [release] Error 2 make[1]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts' make: *** [install.emulator] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mint@REDACTED Fri Aug 8 16:03:36 2008 From: mint@REDACTED (Kristoffer Warming) Date: Fri, 8 Aug 2008 16:03:36 +0200 Subject: [erlang-bugs] R12B-3 +native pattern-matching bug Message-ID: <241885760808080703yf854902pc168446899fce2c@mail.gmail.com> Hi :) I am seeing faulty pattern matching in Erlang apps compiled to R12B-3 with +native, on 64-bit. Applies to older versions as well More specificially this happens in Mochiweb in mochiweb_http.erl:request/2 Here is the code: request(Socket, Body) -> case gen_tcp:recv(Socket, 0, ?IDLE_TIMEOUT) of {ok, {http_request, Method, Path, Version}} -> headers(Socket, {Method, Path, Version}, [], Body); {error, {http_error, "\r\n"}} -> request(Socket, Body); {error, {http_error, "\n"}} -> request(Socket, Body); _Other -> io:format("~nOther = ~p~n", [_Other]), %my debug line gen_tcp:close(Socket), exit(normal) end. I put debugline under the default condition, to see what the case was. Oddly enough it gave me this output: Other = {ok,{http_request,'GET',{abs_path,"/"},{1,1}}} which is a perfect match for the first condition. ...And It matches up just fine, if not compiled with +native I also tried replacing the {http_request,Method,Path,Version} pattern with _Message, and that gave a successful a match. _Message contained the same as Other (without the 'ok') To reproduce: grab Mochiweb source code (r84 of this writing), append +native to ERLC_FLAGS in support/include.mk. Execute `scripts/new_mochiweb.erl foo` to get skeleton files, and append +native to foo/support/include.mk. here as well. make, and ./start-dev.sh Regards, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From frederic.minot@REDACTED Fri Aug 8 17:00:09 2008 From: frederic.minot@REDACTED (Frederic Minot) Date: Fri, 8 Aug 2008 08:00:09 -0700 (PDT) Subject: [erlang-bugs] Bug in xmerl In-Reply-To: <486B3092.8060604@erix.ericsson.se> References: <486B3092.8060604@erix.ericsson.se> Message-ID: <18893464.post@talk.nabble.com> Hi, I just had the same problem with UTF-8 xml file, with same solution, but I changed line 3991 too, from to_ucs(Encoding,Chars) when Encoding=='utf-8'; Encoding == undefined -> to to_ucs(Encoding,Chars) when Encoding=="utf-8"; Encoding == undefined -> since Encoding is a list, not an atom. Don't know if it is really useful. Regards, Fred Lars Thorsen wrote: > > > Hi, > it was a bug in xmerl. The ending parenthesis in the call to > string_to_char_set/2 (line 2449 in xmerl_scan)was placed wrong. > This will be fixed in R12B-4 but I include some patch lines below. > > -- View this message in context: http://www.nabble.com/Bug-in-xmerl-tp18154837p18893464.html Sent from the Erlang Bugs mailing list archive at Nabble.com. From nick@REDACTED Fri Aug 8 17:12:35 2008 From: nick@REDACTED (Niclas Eklund) Date: Fri, 8 Aug 2008 17:12:35 +0200 (CEST) Subject: [erlang-bugs] Bug in xmerl In-Reply-To: <18893464.post@talk.nabble.com> References: <486B3092.8060604@erix.ericsson.se> <18893464.post@talk.nabble.com> Message-ID: Hello! Thank you for reporting this! We'll investigate this as soon as possible, but it seems like it's a bug since the following function use the same gurad: to_char_set(UTF8,Ch) when UTF8 =:= "utf-8"; UTF8 =:= undefined -> Best Regards, Niclas, the Erlang/OTP Team On Fri, 8 Aug 2008, Frederic Minot wrote: > > Hi, > > I just had the same problem with UTF-8 xml file, with same solution, but I > changed line 3991 too, from > to_ucs(Encoding,Chars) when Encoding=='utf-8'; Encoding == undefined -> > to > to_ucs(Encoding,Chars) when Encoding=="utf-8"; Encoding == undefined -> > since Encoding is a list, not an atom. > > Don't know if it is really useful. > > Regards, > Fred > > Lars Thorsen wrote: >> >> >> Hi, >> it was a bug in xmerl. The ending parenthesis in the call to >> string_to_char_set/2 (line 2449 in xmerl_scan)was placed wrong. >> This will be fixed in R12B-4 but I include some patch lines below. >> >> > > -- > View this message in context: http://www.nabble.com/Bug-in-xmerl-tp18154837p18893464.html > Sent from the Erlang Bugs mailing list archive at Nabble.com. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From mikpe@REDACTED Fri Aug 8 20:25:06 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 8 Aug 2008 20:25:06 +0200 Subject: [erlang-bugs] R12B-3 +native pattern-matching bug In-Reply-To: <241885760808080703yf854902pc168446899fce2c@mail.gmail.com> References: <241885760808080703yf854902pc168446899fce2c@mail.gmail.com> Message-ID: <18588.36738.389043.722311@harpo.it.uu.se> Kristoffer Warming writes: > Hi :) > > I am seeing faulty pattern matching in Erlang apps compiled to R12B-3 > with +native, on 64-bit. Applies to older versions as well > > More specificially this happens in Mochiweb in mochiweb_http.erl:request/2 > Here is the code: > > request(Socket, Body) -> > case gen_tcp:recv(Socket, 0, ?IDLE_TIMEOUT) of > {ok, {http_request, Method, Path, Version}} -> > > headers(Socket, {Method, Path, Version}, [], Body); > {error, {http_error, "\r\n"}} -> > > request(Socket, Body); > {error, {http_error, "\n"}} -> > > request(Socket, Body); > _Other -> > > io:format("~nOther = ~p~n", [_Other]), %my debug line > > gen_tcp:close(Socket), > exit(normal) > end. > > I put debugline under the default condition, to see what the case was. > Oddly enough it gave me this output: > > Other = {ok,{http_request,'GET',{abs_path,"/"},{1,1}}} > > which is a perfect match for the first condition. > ...And It matches up just fine, if not compiled with +native > > I also tried replacing the {http_request,Method,Path,Version} pattern with > _Message, and that gave a successful a match. _Message contained the same as > Other (without the 'ok') > > To reproduce: grab Mochiweb source code (r84 of this writing), append > +native to ERLC_FLAGS in support/include.mk. Execute > `scripts/new_mochiweb.erl foo` to get skeleton files, and append > +native to foo/support/include.mk. here as well. > make, and ./start-dev.sh It would help if you could supply a small standalone test case. From mikpe@REDACTED Fri Aug 8 23:10:17 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 8 Aug 2008 23:10:17 +0200 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 In-Reply-To: <12d458770808080703i71c61915g578501f49f5e15f9@mail.gmail.com> References: <12d458770808080703i71c61915g578501f49f5e15f9@mail.gmail.com> Message-ID: <18588.46649.504810.364766@harpo.it.uu.se> philippe vanderstraeten writes: > Hello , > > I wanted to know if Erlang otp_src_R12B-2 is supported on PowerPC 64 and > RHEL 4 (Red Hat Enterprise Linux AS release 4 (Nahant Update 3)). > > I started the install script and I got errors at the end: > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel.src > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel > /usr/bin/install -c -d > /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp > ( cd /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp && \ > erlc -W -I/home/admin/download/otp_src_R12B-2/lib/kernel/ebin > -I/home/admin/download/otp_src_R12B-2/lib/stdlib/ebin > -I/home/admin/download/otp_src_R12B-2/lib/sasl/ebin -o > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.rel ) > /bin/sh: erlc: command not found > make[3]: *** > [/home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script] > Error 127 > make[3]: Leaving directory > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' > make[2]: *** [release] Error 2 > make[2]: Leaving directory > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' > make[1]: *** [release] Error 2 > make[1]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts' > make: *** [install.emulator] Error 2 I don't have RHEL4, but otp R12B-3 builds and installs fine on my ppc64 box running YDL6 (similar to FC6 and RHEL5). I suspect either an incorrect ./configure or make command, or some undetected build failure prior to the failure you quoted above. Please show us your entire build log, including your ./configure and make commands. (It's going to be big and may not be suitable for posting to a mailing list. You can just give us a URL to it.) /Mikael From phvander@REDACTED Sat Aug 9 11:57:05 2008 From: phvander@REDACTED (philippe vanderstraeten) Date: Sat, 9 Aug 2008 11:57:05 +0200 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 In-Reply-To: <18588.46649.504810.364766@harpo.it.uu.se> References: <12d458770808080703i71c61915g578501f49f5e15f9@mail.gmail.com> <18588.46649.504810.364766@harpo.it.uu.se> Message-ID: <12d458770808090257g4fdb9c4eif6cfde2c6cd463b0@mail.gmail.com> Hi, thanks for your answer. I have uploaded make and configure stdout and stderr. URLs are: http://pagesperso-orange.fr/punu/erlang/configure.log http://pagesperso-orange.fr/punu/erlang/make.log Thanks for your help. On Fri, Aug 8, 2008 at 11:10 PM, Mikael Pettersson wrote: > philippe vanderstraeten writes: > > Hello , > > > > I wanted to know if Erlang otp_src_R12B-2 is supported on PowerPC 64 and > > RHEL 4 (Red Hat Enterprise Linux AS release 4 (Nahant Update 3)). > > > > I started the install script and I got errors at the end: > > > > > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel.src > > > > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel > > /usr/bin/install -c -d > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp > > ( cd /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp && \ > > erlc -W -I/home/admin/download/otp_src_R12B-2/lib/kernel/ebin > > -I/home/admin/download/otp_src_R12B-2/lib/stdlib/ebin > > -I/home/admin/download/otp_src_R12B-2/lib/sasl/ebin -o > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.rel ) > > /bin/sh: erlc: command not found > > make[3]: *** > > > [/home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script] > > Error 127 > > make[3]: Leaving directory > > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' > > make[2]: *** [release] Error 2 > > make[2]: Leaving directory > > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' > > make[1]: *** [release] Error 2 > > make[1]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts' > > make: *** [install.emulator] Error 2 > > I don't have RHEL4, but otp R12B-3 builds and installs fine on > my ppc64 box running YDL6 (similar to FC6 and RHEL5). > > I suspect either an incorrect ./configure or make command, or some > undetected build failure prior to the failure you quoted above. > Please show us your entire build log, including your ./configure > and make commands. (It's going to be big and may not be suitable > for posting to a mailing list. You can just give us a URL to it.) > > /Mikael > -------------- next part -------------- An HTML attachment was scrubbed... URL: From phvander@REDACTED Sat Aug 9 13:06:47 2008 From: phvander@REDACTED (philippe vanderstraeten) Date: Sat, 9 Aug 2008 13:06:47 +0200 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 In-Reply-To: <12d458770808090257g4fdb9c4eif6cfde2c6cd463b0@mail.gmail.com> References: <12d458770808080703i71c61915g578501f49f5e15f9@mail.gmail.com> <18588.46649.504810.364766@harpo.it.uu.se> <12d458770808090257g4fdb9c4eif6cfde2c6cd463b0@mail.gmail.com> Message-ID: <12d458770808090406g33eedee0i6a3b42a82f68d7b@mail.gmail.com> I also upload configure, configure.in, and config.status On Sat, Aug 9, 2008 at 11:57 AM, philippe vanderstraeten wrote: > Hi, > > thanks for your answer. I have uploaded make and configure stdout and > stderr. URLs are: > http://pagesperso-orange.fr/punu/erlang/configure.log > http://pagesperso-orange.fr/punu/erlang/make.log > > Thanks for your help. > > > On Fri, Aug 8, 2008 at 11:10 PM, Mikael Pettersson wrote: > >> philippe vanderstraeten writes: >> > Hello , >> > >> > I wanted to know if Erlang otp_src_R12B-2 is supported on PowerPC 64 >> and >> > RHEL 4 (Red Hat Enterprise Linux AS release 4 (Nahant Update 3)). >> > >> > I started the install script and I got errors at the end: >> > >> > >> > >> /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel.src >> > > >> > >> /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel >> > /usr/bin/install -c -d >> > /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp >> > ( cd /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp && \ >> > erlc -W -I/home/admin/download/otp_src_R12B-2/lib/kernel/ebin >> > -I/home/admin/download/otp_src_R12B-2/lib/stdlib/ebin >> > -I/home/admin/download/otp_src_R12B-2/lib/sasl/ebin -o >> > >> /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script >> > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.rel >> ) >> > /bin/sh: erlc: command not found >> > make[3]: *** >> > >> [/home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script] >> > Error 127 >> > make[3]: Leaving directory >> > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' >> > make[2]: *** [release] Error 2 >> > make[2]: Leaving directory >> > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' >> > make[1]: *** [release] Error 2 >> > make[1]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts' >> > make: *** [install.emulator] Error 2 >> >> I don't have RHEL4, but otp R12B-3 builds and installs fine on >> my ppc64 box running YDL6 (similar to FC6 and RHEL5). >> >> I suspect either an incorrect ./configure or make command, or some >> undetected build failure prior to the failure you quoted above. >> Please show us your entire build log, including your ./configure >> and make commands. (It's going to be big and may not be suitable >> for posting to a mailing list. You can just give us a URL to it.) >> >> /Mikael >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpe@REDACTED Sat Aug 9 13:52:12 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Sat, 9 Aug 2008 13:52:12 +0200 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 In-Reply-To: <12d458770808090257g4fdb9c4eif6cfde2c6cd463b0@mail.gmail.com> References: <12d458770808080703i71c61915g578501f49f5e15f9@mail.gmail.com> <18588.46649.504810.364766@harpo.it.uu.se> <12d458770808090257g4fdb9c4eif6cfde2c6cd463b0@mail.gmail.com> Message-ID: <18589.34028.348083.652425@harpo.it.uu.se> philippe vanderstraeten writes: > Hi, > > thanks for your answer. I have uploaded make and configure stdout and > stderr. URLs are: > http://pagesperso-orange.fr/punu/erlang/configure.log > http://pagesperso-orange.fr/punu/erlang/make.log > > Thanks for your help. > > On Fri, Aug 8, 2008 at 11:10 PM, Mikael Pettersson wrote: > > > philippe vanderstraeten writes: > > > Hello , > > > > > > I wanted to know if Erlang otp_src_R12B-2 is supported on PowerPC 64 and > > > RHEL 4 (Red Hat Enterprise Linux AS release 4 (Nahant Update 3)). > > > > > > I started the install script and I got errors at the end: > > > > > > > > > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel.src > > > > > > > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_all_example.rel > > > /usr/bin/install -c -d > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp > > > ( cd /home/admin/download/otp_src_R12B-2/erts/start_scripts/tmp && \ > > > erlc -W -I/home/admin/download/otp_src_R12B-2/lib/kernel/ebin > > > -I/home/admin/download/otp_src_R12B-2/lib/stdlib/ebin > > > -I/home/admin/download/otp_src_R12B-2/lib/sasl/ebin -o > > > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script > > > /home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.rel ) > > > /bin/sh: erlc: command not found > > > make[3]: *** > > > > > [/home/admin/download/otp_src_R12B-2/erts/start_scripts/start_clean.script] > > > Error 127 > > > make[3]: Leaving directory > > > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' > > > make[2]: *** [release] Error 2 > > > make[2]: Leaving directory > > > `/home/admin/download/otp_src_R12B-2/erts/start_scripts' > > > make[1]: *** [release] Error 2 > > > make[1]: Leaving directory `/home/admin/download/otp_src_R12B-2/erts' > > > make: *** [install.emulator] Error 2 > > > > I don't have RHEL4, but otp R12B-3 builds and installs fine on > > my ppc64 box running YDL6 (similar to FC6 and RHEL5). > > > > I suspect either an incorrect ./configure or make command, or some > > undetected build failure prior to the failure you quoted above. > > Please show us your entire build log, including your ./configure > > and make commands. (It's going to be big and may not be suitable > > for posting to a mailing list. You can just give us a URL to it.) (please don't top-post) According to your configure.log you don't have a java compiler and jinterface is supposed to be disabled: >configure: WARNING: Could not find any usable java compiler, will skip: jinterface >... >********************************************************************* >********************** APPLICATIONS DISABLED ********************** >********************************************************************* > >jinterface : No Java compiler found This should result in a file lib/jinterface/SKIP containing the text "No Java compiler found". But your make command shows it trying to build jinterface anyway, and failing: >=== Entering application jinterface >make[3]: Entering directory `/home/admin/download/otp_src_R12B-2/lib/jinterface/java_src' >set -e; set -x; \ >case "make" in *clearmake*) tflag="-T";; *) tflag="";; esac; \ >if test -f com/ericsson/otp/erlang/ignore_config_record.inf; then xflag=$tflag; fi; \ >(cd com/ericsson/otp/erlang && make -f Makefile.otp $xflag opt) >+ case "make" in >+ tflag= >+ test -f com/ericsson/otp/erlang/ignore_config_record.inf >+ xflag= >+ cd com/ericsson/otp/erlang >+ make -f Makefile.otp opt >make[4]: Entering directory `/home/admin/download/otp_src_R12B-2/lib/jinterface/java_src/com/ericsson/otp/erlang' >if [ ! -d "/home/admin/download/otp_src_R12B-2/lib/jinterface/priv/" ];then mkdir "/home/admin/download/otp_src_R12B-2/lib/jinterface/priv/"; fi >CLASSPATH=/home/admin/download/otp_src_R12B-2/lib/jinterface/java_src/ -d /home/admin/download/otp_src_R12B-2/lib/jinterface/priv/ OtpAuthException.java >/bin/sh: -d: command not found >make[4]: *** [/home/admin/download/otp_src_R12B-2/lib/jinterface/priv/com/ericsson/otp/erlang/OtpAuthException.class] Error 127 >make[4]: Leaving directory `/home/admin/download/otp_src_R12B-2/lib/jinterface/java_src/com/ericsson/otp/erlang' >make[3]: *** [opt] Error 2 >make[3]: Leaving directory `/home/admin/download/otp_src_R12B-2/lib/jinterface/java_src' >make[2]: *** [opt] Error 2 >make[2]: Leaving directory `/home/admin/download/otp_src_R12B-2/lib/jinterface' >make[1]: *** [opt] Error 2 >make[1]: Leaving directory `/home/admin/download/otp_src_R12B-2/lib' >make: *** [fourth_bootstrap_build] Error 2 At this point the system is incompletely built, so it's no surprise that the 'make install' doesn't work. The real problem here is that make shouldn't even have tried to build jinterface. Can you do the following: 1. rm -rf otp_src_R12B-2 2. tar zxvf otp_src_R12B-2.tar.gz (so we have known good sources) 3. cd otp_src_R12B-2 4. ./configure (show us the exact parameters you gave it, and the output) 5. find . -name SKIP (if configure found no java compiler then it should disable jinterface, and it does that by creating lib/jinterface/SKIP) 6. make (show us the exact command parameters you gave it, if any, and the output) If configure still finds no java but make still tries to build jinterface, then something is very very wrong on your RHEL4 system, and someone with access to RHEL4 (I don't) should take a closer look at it. /Mikael From mint@REDACTED Sun Aug 10 01:17:23 2008 From: mint@REDACTED (Kristoffer Warming) Date: Sun, 10 Aug 2008 01:17:23 +0200 Subject: [erlang-bugs] R12B-3 +native pattern-matching bug In-Reply-To: <489C9160.7050001@it.uu.se> References: <241885760808080703yf854902pc168446899fce2c@mail.gmail.com> <489C9160.7050001@it.uu.se> Message-ID: <1218323843.8606.5.camel@kris-ubuntu> > It would help if you could supply a small standalone test case. It seems as though my last message didn't manage to get through because the attachment was too big. (400kb) It was just a precompiled mochiweb, as i have not managed to reproduce the bug in a small test-case. > This is a bug for now a workaround would be to add > +{hipe,[no_icode_type]} as an option to the compiler, but a patch > should > be forthcoming. > > Per Gustafsson This didn't fix it. I got error messages like this: =CRASH REPORT==== 8-Aug-2008::22:30:59 === crasher: pid: <0.56.0> registered_name: [] exception error: bad argument in function foo_web:loop/2 in call from mochiweb_http:headers/4 in call from mochiweb_util:unquote/1 initial call: mochiweb_socket_server:acceptor_loop({<0.55.0>,#Port<0.137>, #Fun}) ancestors: [foo_web,foo_sup,<0.53.0>] messages: [] links: [<0.55.0>,#Port<0.138>] dictionary: [] trap_exit: false status: running heap_size: 987 stack_size: 23 reductions: 931 neighbours: =ERROR REPORT==== 8-Aug-2008::22:30:59 === {mochiweb_socket_server,235,{child_error,badarg}} From mint@REDACTED Fri Aug 8 22:56:11 2008 From: mint@REDACTED (Kristoffer Warming) Date: Fri, 8 Aug 2008 22:56:11 +0200 Subject: [erlang-bugs] R12B-3 +native pattern-matching bug Message-ID: <241885760808081356y70b0c617uade3c5cff383ee59@mail.gmail.com> > This is a bug for now a workaround would be to add > +{hipe,[no_icode_type]} as an option to the compiler, but a patch > should > be forthcoming. > > Per Gustafsson This didn't work, in fact it caused crash reports like this =CRASH REPORT==== 8-Aug-2008::22:30:59 === crasher: pid: <0.56.0> registered_name: [] exception error: bad argument in function foo_web:loop/2 in call from mochiweb_http:headers/4 in call from mochiweb_util:unquote/1 initial call: mochiweb_socket_server:acceptor_loop({<0.55.0>,#Port<0.137>, #Fun}) ancestors: [foo_web,foo_sup,<0.53.0>] messages: [] links: [<0.55.0>,#Port<0.138>] dictionary: [] trap_exit: false status: running heap_size: 987 stack_size: 23 reductions: 931 neighbours: =ERROR REPORT==== 8-Aug-2008::22:30:59 === {mochiweb_socket_server,235,{child_error,badarg}} > It would help if you could supply a small standalone test case. Attachment is Mochiweb compiled against R12B-3 AMD64 +native, with my custom debug line. Launch mochiweb/foo/start-dev.sh and visit http://localhost:8000/ This should yield debug message saying "THIS SHOULDN'T HAPPEN.. _Other = ..." -------------- next part -------------- A non-text attachment was scrubbed... Name: mochiweb_native_amd64.tar.bz2 Type: application/x-bzip2 Size: 431772 bytes Desc: not available URL: From phvander@REDACTED Mon Aug 11 13:24:38 2008 From: phvander@REDACTED (philippe vanderstraeten) Date: Mon, 11 Aug 2008 13:24:38 +0200 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 - how to not compile odbc Message-ID: <12d458770808110424s6e75c6fdgd897d15da7a50b15@mail.gmail.com> Hi, I want to compile ERLANG without any ODBC stuff. Is there a way to do that through ./configure options. Unfortunaltely, some ODBC stuff is installed on the system. But make do not find any sql.h and other includes related to SQL. I read somewhere to modify lib/Makefile to add support of ODBC. So by analogy, I suppress all odbc strings I found in lib/Makefile. Is it the right way to suppress Erlang's odbc compile ? If not what is the rigth way. Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew@REDACTED Mon Aug 11 23:38:36 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Mon, 11 Aug 2008 16:38:36 -0500 Subject: [erlang-bugs] xmerl_xpath doesn't handle "//@*" correctly? Message-ID: I'm not an xpath expert, but this seems inconsistent to me: 1> F = fun(S) -> {Doc, _} = xmerl_scan:string(S), length(xmerl_xpath:string("//@*", Doc)) end. #Fun 2> F(""). 1 3> F(""). 1 4> F(" "). 0 Shouldn't "//@*" return 1 attribute for the last case as well? (Using "//*/@*" instead works in all three cases as I expect.) From matthew@REDACTED Tue Aug 12 08:11:49 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Tue, 12 Aug 2008 01:11:49 -0500 Subject: [erlang-bugs] xmerl_xpath doesn't handle "//@*" correctly? In-Reply-To: References: Message-ID: Here is a patch for a handful of XPath bugs I found while trying to track down the previous issue. The first four hunks and the seventh hunk fix the handling of 'preceding', 'preceding-sibling', 'following', and 'following-sibling' to handle when the context nodeset includes a text node. E.g., "//text()/preceding::*" or "//b/following::text()" against "xx". The fifth hunk fixes match_attribute to not throw away any accumulated context nodes just because a non-element node was tested. E.g., "//@*" against "x". The sixth hunk fixes xmerl_xpath.erl to compile correctly when -Ddebug=true is given. (I'm not an xpath guru, so someone should double check that my test cases aren't bogus. I just used http://www.whitebeam.org/library/guide/TechNotes/xpathtestbed.rhtm as a sanity check.) --- xmerl_xpath.erl.orig 2008-08-12 00:28:54.000000000 -0500 +++ xmerl_xpath.erl 2008-08-12 00:50:16.000000000 -0500 @@ -525,7 +525,7 @@ match_following_sibling(Tok, N, Acc, Con case Ps of [#xmlNode{type = element, node = #xmlElement{} = PNode}|_] -> - FollowingSiblings = lists:nthtail(Node#xmlElement.pos, + FollowingSiblings = lists:nthtail(get_position(Node), get_content(PNode)), lists:foldr( fun(E, AccX) -> @@ -553,7 +553,7 @@ match_following(Tok, N, Acc, Context) -> case Ps of [#xmlNode{type = element, node = #xmlElement{} = PNode}|_] -> - FollowingSiblings = lists:nthtail(Node#xmlElement.pos, + FollowingSiblings = lists:nthtail(get_position(Node), get_content(PNode)), lists:foldr( fun(E, AccX) -> @@ -588,7 +588,7 @@ match_preceding_sibling(Tok, N, Acc, Con [#xmlNode{type = element, node = #xmlElement{} = PNode}|_] -> PrecedingSiblings = lists:sublist(get_content(PNode), 1, - Node#xmlElement.pos-1), + get_position(Node) - 1), lists:foldr( fun(E, AccX) -> ThisN = #xmlNode{type = node_type(E), @@ -616,7 +616,7 @@ match_preceding(Tok, N, Acc, Context) -> [#xmlNode{type = element, node = #xmlElement{} = PNode}|_] -> PrecedingSiblings = lists:sublist(get_content(PNode), 1, - Node#xmlElement.pos-1), + get_position(Node) - 1), lists:foldr( fun(E, AccX) -> ThisN = #xmlNode{type = node_type(E), @@ -655,7 +655,7 @@ match_attribute(Tok, N, Acc, Context) -> end end, Acc, E#xmlElement.attributes); _Other -> - [] + Acc end. node_type(#xmlAttribute{}) -> attribute; @@ -736,12 +736,12 @@ node_test({name, {_Tag, Prefix, Local}}, case expanded_name(Prefix, Local, Context) of [] -> ?dbg("node_test(~p, ~p) -> ~p.~n", - [{Tag, Prefix, Local}, write_node(Name), false]), + [{_Tag, Prefix, Local}, write_node(Name), false]), false; ExpName -> Res = (ExpName == {NS#xmlNamespace.default,Name}), ?dbg("node_test(~p, ~p) -> ~p.~n", - [{Tag, Prefix, Local}, write_node(Name), Res]), + [{_Tag, Prefix, Local}, write_node(Name), Res]), Res end; node_test({name, {Tag,_Prefix,_Local}}, @@ -811,4 +811,11 @@ get_content(#xmlElement{content = F} = E get_content(#xmlDocument{content = C}) when list(C) -> C; get_content(#xmlDocument{content = C}) -> - [C]. + [C]; +get_content(#xmlText{}) -> + []. + +get_position(#xmlElement{pos = N}) -> + N; +get_position(#xmlText{pos = N}) -> + N. From bertil.karlsson@REDACTED Tue Aug 12 12:58:00 2008 From: bertil.karlsson@REDACTED (Bertil Karlsson) Date: Tue, 12 Aug 2008 12:58:00 +0200 Subject: [erlang-bugs] [erlang-patches] xmerl_xpath doesn't handle "//@*" correctly? In-Reply-To: References: Message-ID: <48A16CB8.5030606@ericsson.com> Matthew, thanks for this. It will be included in the next patch. /Bertil Matthew Dempsky wrote: > Here is a patch for a handful of XPath bugs I found while trying to > track down the previous issue. > > The first four hunks and the seventh hunk fix the handling of > 'preceding', 'preceding-sibling', 'following', and 'following-sibling' > to handle when the context nodeset includes a text node. E.g., > "//text()/preceding::*" or "//b/following::text()" against > "xx". > > The fifth hunk fixes match_attribute to not throw away any accumulated > context nodes just because a non-element node was tested. E.g., > "//@*" against "x". > > The sixth hunk fixes xmerl_xpath.erl to compile correctly when > -Ddebug=true is given. > > (I'm not an xpath guru, so someone should double check that my test > cases aren't bogus. I just used > http://www.whitebeam.org/library/guide/TechNotes/xpathtestbed.rhtm as > a sanity check.) > > --- xmerl_xpath.erl.orig 2008-08-12 00:28:54.000000000 -0500 > +++ xmerl_xpath.erl 2008-08-12 00:50:16.000000000 -0500 > @@ -525,7 +525,7 @@ match_following_sibling(Tok, N, Acc, Con > case Ps of > [#xmlNode{type = element, > node = #xmlElement{} = PNode}|_] -> > - FollowingSiblings = lists:nthtail(Node#xmlElement.pos, > + FollowingSiblings = lists:nthtail(get_position(Node), > get_content(PNode)), > lists:foldr( > fun(E, AccX) -> > @@ -553,7 +553,7 @@ match_following(Tok, N, Acc, Context) -> > case Ps of > [#xmlNode{type = element, > node = #xmlElement{} = PNode}|_] -> > - FollowingSiblings = lists:nthtail(Node#xmlElement.pos, > + FollowingSiblings = lists:nthtail(get_position(Node), > get_content(PNode)), > lists:foldr( > fun(E, AccX) -> > @@ -588,7 +588,7 @@ match_preceding_sibling(Tok, N, Acc, Con > [#xmlNode{type = element, > node = #xmlElement{} = PNode}|_] -> > PrecedingSiblings = lists:sublist(get_content(PNode), 1, > - Node#xmlElement.pos-1), > + get_position(Node) - 1), > lists:foldr( > fun(E, AccX) -> > ThisN = #xmlNode{type = node_type(E), > @@ -616,7 +616,7 @@ match_preceding(Tok, N, Acc, Context) -> > [#xmlNode{type = element, > node = #xmlElement{} = PNode}|_] -> > PrecedingSiblings = lists:sublist(get_content(PNode), 1, > - Node#xmlElement.pos-1), > + get_position(Node) - 1), > lists:foldr( > fun(E, AccX) -> > ThisN = #xmlNode{type = node_type(E), > @@ -655,7 +655,7 @@ match_attribute(Tok, N, Acc, Context) -> > end > end, Acc, E#xmlElement.attributes); > _Other -> > - [] > + Acc > end. > > node_type(#xmlAttribute{}) -> attribute; > @@ -736,12 +736,12 @@ node_test({name, {_Tag, Prefix, Local}}, > case expanded_name(Prefix, Local, Context) of > [] -> > ?dbg("node_test(~p, ~p) -> ~p.~n", > - [{Tag, Prefix, Local}, write_node(Name), false]), > + [{_Tag, Prefix, Local}, write_node(Name), false]), > false; > ExpName -> > Res = (ExpName == {NS#xmlNamespace.default,Name}), > ?dbg("node_test(~p, ~p) -> ~p.~n", > - [{Tag, Prefix, Local}, write_node(Name), Res]), > + [{_Tag, Prefix, Local}, write_node(Name), Res]), > Res > end; > node_test({name, {Tag,_Prefix,_Local}}, > @@ -811,4 +811,11 @@ get_content(#xmlElement{content = F} = E > get_content(#xmlDocument{content = C}) when list(C) -> > C; > get_content(#xmlDocument{content = C}) -> > - [C]. > + [C]; > +get_content(#xmlText{}) -> > + []. > + > +get_position(#xmlElement{pos = N}) -> > + N; > +get_position(#xmlText{pos = N}) -> > + N. > _______________________________________________ > erlang-patches mailing list > erlang-patches@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-patches > > From pfisher@REDACTED Mon Aug 11 13:35:05 2008 From: pfisher@REDACTED (Paul Fisher) Date: Mon, 11 Aug 2008 06:35:05 -0500 Subject: [erlang-bugs] Erlang on PowerPC 64 RHEL 4 - how to not compile odbc In-Reply-To: <12d458770808110424s6e75c6fdgd897d15da7a50b15@mail.gmail.com> References: <12d458770808110424s6e75c6fdgd897d15da7a50b15@mail.gmail.com> Message-ID: <48A023E9.70305@alertlogic.net> philippe vanderstraeten wrote: > Hi, > > I want to compile ERLANG without any ODBC stuff. Is there a way to do > that through ./configure options. --without-odbc -- paul From paul-trapexit@REDACTED Wed Aug 13 00:02:34 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Tue, 12 Aug 2008 15:02:34 -0700 (PDT) Subject: [erlang-bugs] lists:usort/2 documentation bug Message-ID: the documentation says: "Returns a list which contains the sorted elements of List1 where all but the first element of the elements comparing equal according to the ordering function Fun have been deleted. Fun(A, B) should return true if A comes before B in the ordering, false otherwise." however, if one uses a fun that returns (A < B), one gets a bad result; this is because equality is detected via Fun (A, B) and Fun (B, A) both being true. so instead the fun should return (A =< B). i would suggest rephrasing as "... should return true if A compares less than or equal to B in the ordering, false otherwise". -- p From xbmodder@REDACTED Wed Aug 13 00:15:38 2008 From: xbmodder@REDACTED (Sargun Dhillon) Date: Tue, 12 Aug 2008 15:15:38 -0700 Subject: [erlang-bugs] HTTP documentation bug Message-ID: <7c9d57ea0808121515p73cdb04cx7a714f18ae90c0ca@mail.gmail.com> There is a typo in the http documentation: This module provides the API to a HTTP/1.1 client according to RFC 2616, caching is currentyl not supported. It should read: This module provides the API to a HTTP/1.1 client according to RFC 2616, caching is currently not supported. From erlang-questions_efine@REDACTED Wed Aug 13 08:00:47 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Wed, 13 Aug 2008 02:00:47 -0400 Subject: [erlang-bugs] [BUG] gen_tcp:connect/3, 4 returns socket for closed port Message-ID: <6c2563b20808122300s1025f969seb2674b98653503@mail.gmail.com> *Problem Statement* When calling gen_tcp:connect/3 or /4 on a host/port that does not have a running program listening on it, at random intervals gen_tcp:connect returns an {ok, Sock} instead of the expected {error, econnrefused}. If gen_tcp:recv(Sock, 0) is called immediately using the socket just returned, it returns an {error, econnrefused}. Connection options used were [binary, {packet, raw}, {active, false}]. It should be noted that the gen_tcp:connect succeeds when there is a program listening on that sane host/port, so it's unlikely to be a firewall issue. *Reproducing the error* The attached test program demonstrates the bug most quickly if you run with more than one scheduler and with kernel poll enabled. It was run in the shell as gen_tcp_connect_bug:go(Host, Port). It seemed to make no difference whether gen_tcp:connect/3 or gen_tcp:connect/4 was called. The destination system was another computer on the same local subnet, which was running Windows XP. Running the test with only one scheduler (+S 1) didn't return a false positive in over 4 million connect() attempts (after which I terminated the program). It may be reasonable to assume that the issue won't appear with one scheduler. - erl +S 4 +K true: false positive returned in between 1 and a few thousand attempts. - erl +S 4 +K false: false positive returned in around 70,000 or more attempts. - erl +S 1 +K true or false: no false positive returned in > 4.2 million attempts. The attached Wireshark text file trace shows that on every occasion, gen_tcp sent a SYN and received an RST, even for the request that returned an open socket, so it doesn't seem to be a TCP/IP problem. The binary version of the trace is available if required. This seems to suggest that the bug is related to SMP mode, and may have something to do with 64-bit mode. I haven't got a 32-bit system to try it on. Why it returns much quicker when using kernel poll is probably due to timing. *Test Environment* - Intel Q6600, Intel XBX2 MB, 8GB RAM, On-board Broadcom Gigabit Ethernet - Ubuntu Linux x86_64 Gutsy (Linux 2.6.24-16-generic #1 SMP Thu Apr 10 12:47:45 UTC 2008 x86_64 GNU/Linux) - Erlang R12B-3 Regards, Edwin Fine -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gen_tcp_connect_bug.erl Type: text/x-erlang Size: 1085 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gen_tcp_connect_bug.wireshark_cap.20080813.txt.gz Type: application/x-gzip Size: 11680 bytes Desc: not available URL: From ingela@REDACTED Wed Aug 13 08:07:53 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 13 Aug 2008 08:07:53 +0200 Subject: [erlang-bugs] HTTP documentation bug In-Reply-To: <7c9d57ea0808121515p73cdb04cx7a714f18ae90c0ca@mail.gmail.com> References: <7c9d57ea0808121515p73cdb04cx7a714f18ae90c0ca@mail.gmail.com> Message-ID: <48A27A39.4040405@erix.ericsson.se> Thank you for reporting this, it will be fixed in the next release. Regards Ingela Erlang/OTP, Ericsson Sargun Dhillon wrote: > There is a typo in the http documentation: > This module provides the API to a HTTP/1.1 client according to RFC > 2616, caching is currentyl not supported. > > It should read: > > This module provides the API to a HTTP/1.1 client according to RFC > 2616, caching is currently not supported. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From pguyot@REDACTED Wed Aug 13 11:13:50 2008 From: pguyot@REDACTED (Paul Guyot) Date: Wed, 13 Aug 2008 11:13:50 +0200 Subject: [erlang-bugs] inets:http client: bug and feature request Message-ID: <732EAD3F-933B-4DB3-AEB3-24544B5970CE@kallisys.net> Hello, I noticed a bug (or an undocumented feature?) with http:request. If the request is asynchronous, option {full_result, false} is not honored, the result is always full. This is a nasty bug as fixing it might break code (OTOH, why would you pass {full_result, false} if it doesn't work?). Besides, one can perform basic authentication with the "login:password@" URI scheme (which is not documented, AFAIK). However, this probably doesn't work when the login or the password contains the @ sign (typically an e-mail address is used for the login). I wish there would be a non-ambiguous way to specify the login and the password for authentication (the workaround is to add the "Authorization" header directly). Paul From hroe@REDACTED Wed Aug 13 21:32:01 2008 From: hroe@REDACTED (hroe@REDACTED) Date: Wed, 13 Aug 2008 21:32:01 +0200 Subject: [erlang-bugs] erts_sys_ddll_call_init() anomaly Message-ID: <27849374.1218655921116.JavaMail.root@webmail2.groni1> Hi, the win32 function void *erts_sys_ddll_call_init(void *function) { void *(*initfn)(TWinDynDriverCallbacks *) = function; return (*initfn)(&wddc); } seems to be incorrect, it should have been: void *erts_sys_ddll_call_init(void *function) { void *(*initfn)(void) = function; return (*initfn)(); } Hth, Herman From erlang-questions_efine@REDACTED Fri Aug 15 02:12:31 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Thu, 14 Aug 2008 20:12:31 -0400 Subject: [erlang-bugs] Documentation bug in file:write_file/3 (R12B-3) Message-ID: <6c2563b20808141712v5e3ff9fao9efa6a50a289baab@mail.gmail.com> write_file/3 lists *Binary* as the second argument, but *Modes* in the description (no mention of *Binary*). >From the documentation: write_file(Filename, *Binary*, Bytes) -> ok | {error, Reason} Types: Filename = name() Bytes = iodata() *Modes = [Mode] -- see open/2* Reason = ext_posix() | terminated | system_limit Same as write_file/2, but takes a third argument Modes, a list of possible modes, see open/2. The mode flags binary and write are implicit, so they should not be used. -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Fri Aug 15 07:58:39 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: Fri, 15 Aug 2008 07:58:39 +0200 Subject: [erlang-bugs] Documentation bug in file:write_file/3 (R12B-3) In-Reply-To: <6c2563b20808141712v5e3ff9fao9efa6a50a289baab@mail.gmail.com> References: <6c2563b20808141712v5e3ff9fao9efa6a50a289baab@mail.gmail.com> Message-ID: <48A51B0F.3070901@erix.ericsson.se> Edwin Fine wrote: > write_file/3 lists /Binary/ as the second argument, but /Modes/ in the > description (no mention of /Binary/). Thanks! It will be corrected in R12B-4. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From zbyszek@REDACTED Fri Aug 15 12:51:23 2008 From: zbyszek@REDACTED (=?UTF-8?Q?Zbyszek_=C5=BB=C3=B3=C5=82kiewski?=) Date: Fri, 15 Aug 2008 12:51:23 +0200 Subject: [erlang-bugs] epmd not cleaning up node name if node is down. Message-ID: Hello, I have noticed that epmd is not cleaning node names if there are multiple nodes running on the same system and one of the node is shuted down. When i try to run node (jggtrans) In logs i can see: Aug 15 12:22:05 xmpp epmd: epmd: epmd running - daemon = 1 Aug 15 12:22:05 xmpp epmd: epmd: node name already occupied jggtrans Aug 15 12:22:46 xmpp epmd: epmd: epmd running - daemon = 1 Aug 15 12:22:46 xmpp epmd: epmd: node name already occupied jggtrans epmd - name: epmd: up and running on port 4369 with data: name jggtrans at port 46477 name zero at port 58591 while: netstat -plan | grep 58591 tcp 0 0 0.0.0.0:58591 0.0.0.0:* LISTEN 2105/beam.smp tcp 0 0 213.134.161.163:58591 213.134.161.162:36438 ESTABLISHED2105/beam.smp netstat -plan | grep 58591 gives nothing, actually node jggtrans is NOT running. The above problem makes running jggtrans node (after restart) imposible without killing epmd process - but it also requires of restarting all nodes in the system. I can reproduce this problem any time. What can cause it? thanks! -- pozdrawiam, Zbyszek ???kiewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Fri Aug 15 13:32:49 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Fri, 15 Aug 2008 13:32:49 +0200 Subject: [erlang-bugs] epmd not cleaning up node name if node is down. In-Reply-To: References: Message-ID: Hi, The normal and correct behaviour is that a node is unregistered from epmd when it is shutdown. each Erlang node that register to epmd establishes and keep an open tcp connection towards epmd. When that connection is broken the Erlang node is unregistered. On what OS is this? How is the Erlang node shutdown? I just run an example on Suse Linux where I create 2 Erlang nodes like this: erl -sname a and in another shell erl -sname b In a third shell epmd -names reported both nodes. I then tried to terminate one of the nodes normally and epmd -names correctly reported that there is only one node left. i started the second node again and epmd -names reported the 2 nodes. I killed one of the nodes with kill -9 and again epmd -names reported only one node as expected. There must be something else causing the behaviour on your system. /Kenneth Erlang/OTP team Ericsson 2008/8/15 Zbyszek ???kiewski : > Hello, > > I have noticed that epmd is not cleaning node names if there are multiple > nodes running on the same system and one of the node is shuted down. > When i try to run node (jggtrans) In logs i can see: > > Aug 15 12:22:05 xmpp epmd: epmd: epmd running - daemon = 1 > Aug 15 12:22:05 xmpp epmd: epmd: node name already occupied jggtrans > Aug 15 12:22:46 xmpp epmd: epmd: epmd running - daemon = 1 > Aug 15 12:22:46 xmpp epmd: epmd: node name already occupied jggtrans > > epmd - name: > > epmd: up and running on port 4369 with data: > name jggtrans at port 46477 > name zero at port 58591 > > while: > > netstat -plan | grep 58591 > > tcp 0 0 0.0.0.0:58591 0.0.0.0:* > LISTEN 2105/beam.smp > tcp 0 0 213.134.161.163:58591 213.134.161.162:36438 > ESTABLISHED2105/beam.smp > > netstat -plan | grep 58591 gives nothing, actually node jggtrans is NOT > running. > > The above problem makes running jggtrans node (after restart) imposible > without killing epmd process - but it also requires of restarting all nodes > in the system. > I can reproduce this problem any time. What can cause it? > > thanks! > > > > -- > pozdrawiam, > Zbyszek ???kiewski > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From zbyszek@REDACTED Fri Aug 15 14:22:36 2008 From: zbyszek@REDACTED (=?UTF-8?Q?Zbyszek_=C5=BB=C3=B3=C5=82kiewski?=) Date: Fri, 15 Aug 2008 14:22:36 +0200 Subject: [erlang-bugs] epmd not cleaning up node name if node is down. In-Reply-To: References: Message-ID: Hello, thanks for the reply, System is Debian 4.0, custom compiled erlang OTP R11B-5, Erlang (BEAM) emulator version 5.5.5 [source] [smp:2] [async-threads:0] [hipe] [kernel-poll:true] (so the nodes are running with +K true -smp options) software that we use is ejabberd xmpp server, we are using cluster mode with 3 nodes (2 on one server and 1 on other server), in this case node was crashed, but the same situation appear on both servers, if i stop node with init:stop()., ctrl+G, k 1, q combination - so quite legaly exiting and shuting down node... so do you have any clue what can cause that epmd is not removing entry from its table? and what we can do to determine problem, and finaly, is there any way of clear epmd table from invalid entries? thanks, 2008/8/15 Kenneth Lundin > Hi, > > The normal and correct behaviour is that a node is unregistered from > epmd when it is shutdown. > each Erlang node that register to epmd establishes and keep an open > tcp connection towards epmd. > When that connection is broken the Erlang node is unregistered. > > On what OS is this? > How is the Erlang node shutdown? > > I just run an example on Suse Linux where I create 2 Erlang nodes like > this: > > erl -sname a > > and in another shell > > erl -sname b > > In a third shell epmd -names reported both nodes. > > I then tried to terminate one of the nodes normally and epmd -names > correctly reported that there > is only one node left. > > i started the second node again and epmd -names reported the 2 nodes. > > I killed one of the nodes with kill -9 and again epmd -names reported > only one node as expected. > > There must be something else causing the behaviour on your system. > > /Kenneth Erlang/OTP team Ericsson > > -- pozdrawiam, Zbyszek ???kiewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From saleyn@REDACTED Sat Aug 16 23:13:06 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Sat, 16 Aug 2008 17:13:06 -0400 Subject: [erlang-bugs] Edoc error Message-ID: <48A742E2.7020107@gmail.com> There seems to be an error in edoc trying to parse URLs with query string arguments: ---------------- $ cat overview.edoc Test Project @doc Test. ColumnModel configuration ---------------- Error being generated: 3748- fatal: expected_entity_reference_semicolon 2628- fatal: error_scanning_entity_ref overview.edoc: at line 8: error in XML parser: {fatal, {error_scanning_entity_ref, {file,file_name_unknown}, {line,51}, {col,88}}}. edoc: error in doclet 'edoc_doclet': {'EXIT',error}. Apparently it doesn't like the ampersand in the URL. Changing the link to '/docs/?class=ColumnModel' works with no issues. Serge From saleyn@REDACTED Sun Aug 17 02:34:26 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Sat, 16 Aug 2008 20:34:26 -0400 Subject: [erlang-bugs] [erlang-questions] Edoc error In-Reply-To: References: <48A742E2.7020107@gmail.com> Message-ID: <48A77212.9060700@gmail.com> Thanks! Apparently I missed the statement on escaping in 1.11.5 chapter of edoc. :-( Sorry for noise. Dale Harvey wrote: > if its looking for valid xml, try using & ? > > 2008/8/16 Serge Aleynikov > >> There seems to be an error in edoc trying to parse URLs with query >> string arguments: >> >> ---------------- >> $ cat overview.edoc >> >> Test Project >> >> @doc Test. >> >> ColumnModel >> configuration >> ---------------- >> >> Error being generated: >> >> 3748- fatal: expected_entity_reference_semicolon >> 2628- fatal: error_scanning_entity_ref >> overview.edoc: at line 8: error in XML parser: {fatal, >> {error_scanning_entity_ref, >> {file,file_name_unknown}, >> {line,51}, >> {col,88}}}. >> edoc: error in doclet 'edoc_doclet': {'EXIT',error}. >> >> >> >> Apparently it doesn't like the ampersand in the URL. Changing the link >> to '/docs/?class=ColumnModel' works with no issues. >> >> Serge >> _______________________________________________ >> erlang-questions mailing list >> erlang-questions@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-questions >> > From matthew@REDACTED Sun Aug 17 10:26:20 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sun, 17 Aug 2008 03:26:20 -0500 Subject: [erlang-bugs] Two xmerl_xpath predicate handling bugs Message-ID: Summary: 1. "//c[1]" against "" should return both 'c' elements; xmerl_xpath returns the first one. 2. "/a/b[@e='f'][position()=1]" against "" should return the second 'b' element; xmerl_xpath returns an empty set. For the first bug, the XPath spec states: NOTE: The location path //para[1] does *not* mean the same as the location path /descendant::para[1]. The latter selects the first descendant para element; the former selects all descendant para elements that are the first para children of their parents. Accordingly, "//c[1]" against "" should match both 'c' elements, but xmerl_xpath only returns the first. This is because when xmerl_xpath:path_expr applies the child::c axis/node-test selection to its context nodeset of all nodes, xmerl_xpath:axis merges the result nodesets before path_expr calls pred_expr, so the [1] predicate is applied to the merged nodeset rather than to each individual nodeset. For the second bug, the spec states: child::para[attribute::type='warning'][position()=5] selects the fifth para child of the context node that has a type attribute with value warning Accordingly, "/a/b[@e='f'][position()=1]" against "" should return the second 'b' element, because it is the first b child of the context node (the root 'a' element) that has its 'e' attribute with value 'f'; but xmerl_xpath returns an empty set. This is because xmerl_xpath numbers the node positions only once after applying the axis/node tests, so "position()" still evaluates to 2 in xmerl_xpath_pred. (Note that "/a/b[@e='f'][1]" still works correctly because xmerl_xpath includes a short-circuit to not depend on #xmlNode.pos.) As a third bug, you might also argue that "//b/following::b" against "" should return the final 'b' element only once, because mathematically unions of sets should omit duplicates and node-sets as defined in expression contexts omit duplicates, but if the user ensures to call lists:usort on the result, the only other negative consequence is worsened performance in contrived test cases. Also beware I'm unlikely to submit a patch for the above issues any time soon. (At this point, I'm more tempted to write my own XPath implementation that uses lazy axis walking, but I've already spent far, far more time on XPath than I really should have...) From richardc@REDACTED Sun Aug 17 10:30:34 2008 From: richardc@REDACTED (Richard Carlsson) Date: Sun, 17 Aug 2008 10:30:34 +0200 Subject: [erlang-bugs] [erlang-questions] Edoc error In-Reply-To: <48A77212.9060700@gmail.com> References: <48A742E2.7020107@gmail.com> <48A77212.9060700@gmail.com> Message-ID: <48A7E1AA.2040808@it.uu.se> It has nothing to do with the edoc wiki expansion; it's just that xmerl takes a legalistic approach to parsing (whereas browsers in general are much more forgiving). The rhs of the attribute is CDATA, which is subject to entity expansion, i.e., you can use enities like " etc. anywhere in the quoted string. Spurious ampersands are not actually allowed - even though they are used to separate fields in a query URL - but browsers tend to leave them as single ampersands if they don't seem to signal an entity (which is helpful if you just want to paste an URL into an HTML page). See http://www.w3.org/TR/html401/appendix/notes.html#h-B.2 (B.2.2) /Richard Serge Aleynikov wrote: > Thanks! Apparently I missed the statement on escaping in 1.11.5 chapter > of edoc. :-( > > Sorry for noise. > > Dale Harvey wrote: >> if its looking for valid xml, try using & ? >> >> 2008/8/16 Serge Aleynikov >> >>> There seems to be an error in edoc trying to parse URLs with query >>> string arguments: >>> >>> ---------------- >>> $ cat overview.edoc >>> >>> Test Project >>> >>> @doc Test. >>> >>> ColumnModel >>> configuration >>> ---------------- >>> >>> Error being generated: >>> >>> 3748- fatal: expected_entity_reference_semicolon >>> 2628- fatal: error_scanning_entity_ref >>> overview.edoc: at line 8: error in XML parser: {fatal, >>> {error_scanning_entity_ref, >>> {file,file_name_unknown}, >>> {line,51}, >>> {col,88}}}. >>> edoc: error in doclet 'edoc_doclet': {'EXIT',error}. >>> >>> >>> >>> Apparently it doesn't like the ampersand in the URL. Changing the link >>> to '/docs/?class=ColumnModel' works with no issues. >>> >>> Serge >>> _______________________________________________ >>> erlang-questions mailing list >>> erlang-questions@REDACTED >>> http://www.erlang.org/mailman/listinfo/erlang-questions >>> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From B.Candler@REDACTED Mon Aug 18 13:43:31 2008 From: B.Candler@REDACTED (Brian Candler) Date: Mon, 18 Aug 2008 12:43:31 +0100 Subject: [erlang-bugs] Minor typos in FSM example Message-ID: <20080818114331.GA11578@uk.tiscali.com> I think there are a couple of typos in the FSM example at http://www.erlang.org/doc/design_principles/fsm.html#ex (1) Spurious semicolon at the end of the case statement in locked/2, which prevents it compiling (2) Timeout value disagrees with that given in the text (30 seconds) --- code_lock.erl.orig 2008-08-18 12:34:51.000000000 +0100 +++ code_lock.erl.new 2008-08-18 12:34:40.000000000 +0100 @@ -18,11 +18,11 @@ case [Digit|SoFar] of Code -> do_unlock(), - {next_state, open, {[], Code}, 3000}; + {next_state, open, {[], Code}, 30000}; Incomplete when length(Incomplete) {next_state, locked, {Incomplete, Code}}; _Wrong -> - {next_state, locked, {[], Code}}; + {next_state, locked, {[], Code}} end. open(timeout, State) -> After this, and after adding do_lock and do_unlock functions, it compiled and ran fine. Regards, Brian. From zbyszek@REDACTED Mon Aug 18 14:11:18 2008 From: zbyszek@REDACTED (=?UTF-8?Q?Zbyszek_=C5=BB=C3=B3=C5=82kiewski?=) Date: Mon, 18 Aug 2008 14:11:18 +0200 Subject: [erlang-bugs] epmd not cleaning up node name if node is down. In-Reply-To: References: Message-ID: so? no one have any idea? On Fri, Aug 15, 2008 at 14:22, Zbyszek ???kiewski wrote: > Hello, thanks for the reply, > > System is Debian 4.0, custom compiled erlang OTP R11B-5, > Erlang (BEAM) emulator version 5.5.5 [source] [smp:2] [async-threads:0] > [hipe] [kernel-poll:true] > (so the nodes are running with +K true -smp options) > > software that we use is ejabberd xmpp server, we are using cluster mode > with 3 nodes (2 on one server and 1 on other server), in this case node was > crashed, > but the same situation appear on both servers, if i stop node with > init:stop()., ctrl+G, k 1, q combination - so quite legaly exiting and > shuting down node... > > so do you have any clue what can cause that epmd is not removing entry from > its table? and what we can do to determine problem, and finaly, is there any > way of clear epmd table from invalid entries? > > thanks, > > > > 2008/8/15 Kenneth Lundin > >> Hi, >> >> The normal and correct behaviour is that a node is unregistered from >> epmd when it is shutdown. >> each Erlang node that register to epmd establishes and keep an open >> tcp connection towards epmd. >> When that connection is broken the Erlang node is unregistered. >> >> On what OS is this? >> How is the Erlang node shutdown? >> >> I just run an example on Suse Linux where I create 2 Erlang nodes like >> this: >> >> erl -sname a >> >> and in another shell >> >> erl -sname b >> >> In a third shell epmd -names reported both nodes. >> >> I then tried to terminate one of the nodes normally and epmd -names >> correctly reported that there >> is only one node left. >> >> i started the second node again and epmd -names reported the 2 nodes. >> >> I killed one of the nodes with kill -9 and again epmd -names reported >> only one node as expected. >> >> There must be something else causing the behaviour on your system. >> >> /Kenneth Erlang/OTP team Ericsson >> >> > > -- > pozdrawiam, > Zbyszek ???kiewski > -- pozdrawiam, Zbyszek ???kiewski -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenneth.lundin@REDACTED Mon Aug 18 15:42:05 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 18 Aug 2008 15:42:05 +0200 Subject: [erlang-bugs] epmd not cleaning up node name if node is down. In-Reply-To: References: Message-ID: Can you start epmd manually like this "epmd -debug" before you start the Erlang nodes on the same host. You will then get debug printouts from empd showing when it register and unregister E-nodes. /Kenneth 2008/8/18 Zbyszek ???kiewski : > so? no one have any idea? > > On Fri, Aug 15, 2008 at 14:22, Zbyszek ???kiewski > wrote: >> >> Hello, thanks for the reply, >> >> System is Debian 4.0, custom compiled erlang OTP R11B-5, >> Erlang (BEAM) emulator version 5.5.5 [source] [smp:2] [async-threads:0] >> [hipe] [kernel-poll:true] >> (so the nodes are running with +K true -smp options) >> >> software that we use is ejabberd xmpp server, we are using cluster mode >> with 3 nodes (2 on one server and 1 on other server), in this case node was >> crashed, >> but the same situation appear on both servers, if i stop node with >> init:stop()., ctrl+G, k 1, q combination - so quite legaly exiting and >> shuting down node... >> >> so do you have any clue what can cause that epmd is not removing entry >> from its table? and what we can do to determine problem, and finaly, is >> there any way of clear epmd table from invalid entries? >> >> thanks, >> >> >> >> 2008/8/15 Kenneth Lundin >>> >>> Hi, >>> >>> The normal and correct behaviour is that a node is unregistered from >>> epmd when it is shutdown. >>> each Erlang node that register to epmd establishes and keep an open >>> tcp connection towards epmd. >>> When that connection is broken the Erlang node is unregistered. >>> >>> On what OS is this? >>> How is the Erlang node shutdown? >>> >>> I just run an example on Suse Linux where I create 2 Erlang nodes like >>> this: >>> >>> erl -sname a >>> >>> and in another shell >>> >>> erl -sname b >>> >>> In a third shell epmd -names reported both nodes. >>> >>> I then tried to terminate one of the nodes normally and epmd -names >>> correctly reported that there >>> is only one node left. >>> >>> i started the second node again and epmd -names reported the 2 nodes. >>> >>> I killed one of the nodes with kill -9 and again epmd -names reported >>> only one node as expected. >>> >>> There must be something else causing the behaviour on your system. >>> >>> /Kenneth Erlang/OTP team Ericsson >>> >> >> >> -- >> pozdrawiam, >> Zbyszek ???kiewski > > > > -- > pozdrawiam, > Zbyszek ???kiewski > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From nc@REDACTED Mon Aug 18 23:11:08 2008 From: nc@REDACTED (Nicolas Charpentier) Date: Mon, 18 Aug 2008 23:11:08 +0200 Subject: [erlang-bugs] httpd configuration file auth_user_file and auth_group_file location Message-ID: <48A9E56C.8070707@charpi.net> Hi, In the httpd page of the inets reference manual (R12B3) , I can read that authentication properties for each directory can be configured using auth_user_file and auth_group_file. The documentation is saying that the filename can be either absolute, either relative to the server_root. (I understand that it's refering to the server_root attribute of the httpd service). However, those 2 attributes always refer to absolute path or relative to CURRENT directory. I was using this code to start httpd start() -> Web_server_config = [{server_name, httpd_socket:resolve()}, {port, 8090}, {server_root, "/opt/my_server"}, {document_root, "/opt/my_server"}, {server_admin, "admin@REDACTED"}, {error_log, "error.log"}, {security_log, "security.log"}, {transfer_log, "transfer.log"}, {modules,[mod_alias,mod_auth,mod_esi,mod_actions,mod_cgi,mod_dir,mod_get,mod_head,mod_log,mod_trace]}, {directory, {"/", [{auth_type, dets}, {auth_user_file, "users.lst"}, {auth_group_file, "groups.lst"}, {require_group, ["admin"]}, {auth_name, "Administration"}, {auth_access_password, "NoPassword"} ]}} ], {ok, Httpd} = inets: start (httpd, Web_server_config) Httpd. Authentication access never worked until I put the file users.lst and groups.lst in the directory from which I started the VM. Looking at the code, I can see in $ERL_DIR/lib/inets/src/http_server/src:mod_auth_plain.erl and $ERL_DIR/lib/inets/src/http_server/src:mod_auth_dets.erl that you never refer to the server_root configuration parameter. At the opposite, in mod_log.erl you have a case on filename:pathtype/1 to know where to store log files. Regards, Nicolas Charpentier From hans.bolinder@REDACTED Tue Aug 19 08:30:41 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 19 Aug 2008 08:30:41 +0200 Subject: [erlang-bugs] lists:usort/2 documentation bug In-Reply-To: References: Message-ID: <18602.26769.5266.439839@gargle.gargle.HOWL> [Paul Mineiro:] > the documentation says: > > "Returns a list which contains the sorted elements of List1 where all but > the first element of the elements comparing equal according to the > ordering function Fun have been deleted. Fun(A, B) should return true if A > comes before B in the ordering, false otherwise." > > however, if one uses a fun that returns (A < B), one gets a bad result; > this is because equality is detected via Fun (A, B) and Fun (B, A) both > being true. so instead the fun should return (A =< B). i would suggest > rephrasing as > > "... should return true if A compares less than or equal to B in the > ordering, false otherwise". Note that erlang:'<'/2 is not an ordering function (it is not reflexive). This issue pops up every now and then, so I'll add a note stating what is expected of an ordering function. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson AB From ingela@REDACTED Tue Aug 19 09:56:36 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 19 Aug 2008 09:56:36 +0200 Subject: [erlang-bugs] httpd configuration file auth_user_file and auth_group_file location In-Reply-To: <48A9E56C.8070707@charpi.net> References: <48A9E56C.8070707@charpi.net> Message-ID: <48AA7CB4.80303@erix.ericsson.se> Hello, If it does not work as documented it is indeed a bug. Maybe this functionality has not been extensively used as it has been around for quite some while. I have created a ticket for this to be fixed and better tested in the future. Regards Ingela - Erlang/OTP, Ericsson Nicolas Charpentier wrote: > Hi, > In the httpd page of the inets reference manual (R12B3) , I can read > that authentication properties for each directory can be configured > using auth_user_file and auth_group_file. > The documentation is saying that the filename can be either absolute, > either relative to the server_root. (I understand that it's refering to > the server_root attribute of the httpd service). However, those 2 > attributes always refer to absolute path or relative to CURRENT directory. > > I was using this code to start httpd > > > start() -> > Web_server_config = > [{server_name, httpd_socket:resolve()}, > {port, 8090}, > {server_root, "/opt/my_server"}, > {document_root, "/opt/my_server"}, > {server_admin, "admin@REDACTED"}, > {error_log, "error.log"}, > {security_log, "security.log"}, > {transfer_log, "transfer.log"}, > {modules,[mod_alias,mod_auth,mod_esi,mod_actions,mod_cgi,mod_dir,mod_get,mod_head,mod_log,mod_trace]}, > {directory, {"/", [{auth_type, dets}, > {auth_user_file, "users.lst"}, > {auth_group_file, "groups.lst"}, > {require_group, ["admin"]}, > {auth_name, "Administration"}, > {auth_access_password, "NoPassword"} > ]}} > ], > {ok, Httpd} = inets: start (httpd, Web_server_config) > Httpd. > > > Authentication access never worked until I put the file users.lst and > groups.lst in the directory from which I started the VM. > > Looking at the code, I can see in > $ERL_DIR/lib/inets/src/http_server/src:mod_auth_plain.erl and > $ERL_DIR/lib/inets/src/http_server/src:mod_auth_dets.erl that > you never refer to the server_root configuration parameter. > > At the opposite, in mod_log.erl you have a case on filename:pathtype/1 > to know where to store log files. > > > Regards, > Nicolas Charpentier > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From ingela@REDACTED Tue Aug 19 11:03:00 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Tue, 19 Aug 2008 11:03:00 +0200 Subject: [erlang-bugs] inets:http client: bug and feature request In-Reply-To: <732EAD3F-933B-4DB3-AEB3-24544B5970CE@kallisys.net> References: <732EAD3F-933B-4DB3-AEB3-24544B5970CE@kallisys.net> Message-ID: <48AA8C44.9030409@erix.ericsson.se> Hi, Paul Guyot wrote: > Hello, > > I noticed a bug (or an undocumented feature?) with http:request. If > the request is asynchronous, option {full_result, false} is not > honored, the result is always full. This is a nasty bug as fixing it > might break code (OTOH, why would you pass {full_result, false} if it > doesn't work?). > > Hum .. the not full result only means that the synchronous call will throw away some data before returning the data to the user. The request-handling process will always send the whole result to the client, and when the call is asynchronous there is no filter in between. I would say that it is the {full_result, false} that is feature. Acctualy it was keep for backwards compatibility reasons. > Besides, one can perform basic authentication with the > "login:password@" URI scheme (which is not documented, AFAIK). > However, this probably doesn't work when the login or the password > contains the @ sign (typically an e-mail address is used for the > login). I wish there would be a non-ambiguous way to specify the > login and the password for authentication (the workaround is to add > the "Authorization" header directly). > > Well that is not documented as we have not had the time to properly test it and think it through. This is still "original-contribution-code". It is has not been a high priority as it works to add the headers. If you would like to make a patch-suggestion we will probably be willing to take it in. Otherwise I have made a ticket for this but quite frankly it will not be so highly prioritized. Regards Ingela - Erlang/OTP, Ericsson From erlang-questions_efine@REDACTED Thu Aug 21 06:35:21 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Thu, 21 Aug 2008 00:35:21 -0400 Subject: [erlang-bugs] OTP-OS-MON-MIB bugs In-Reply-To: <4843BFDD.4070601@erix.ericsson.se> References: <6c2563b20805281512kd94b832r5b8473d9f0fd180d@mail.gmail.com> <4843BFDD.4070601@erix.ericsson.se> Message-ID: <6c2563b20808202135r434d09cbj93614aed3a615846@mail.gmail.com> Bj?rn-Egil, I reported this bug for R12B-2, and only just got back to working with SNMP. I see that this bug is still present in R12B-3. I'm not surprised, seeing that R12B-3 was released on June 11 and I only reported the issue on May 28. That's not nearly enough time to fix and test it. Will it be fixed for the next release? Regards, Edwin Fine On Mon, Jun 2, 2008 at 5:39 AM, Bj?rn-Egil Dahlberg wrote: > Thank you for pointing out this problem. > > I will look into it. > > Regards, > Bj?rn-Egil > Erlang/OTP > > Edwin Fine wrote: > >> I need to thank Martin Bjorkland for helping me recognize this bug. >> >> I believe that the file OTP-OS-MON-MIB.mib has two sets of bugs, one more >> serious than the other. Fixing the first bug also showed up a potential >> third bug (see later). >> >> *The More Serious One* >> >> The following objects in OTP-OS-MON-MIB.mib are defined as type Gauge32, >> and cause problems when the values returned are actually greater than a >> 32-bit value can represent: >> >> loadSystemTotalMemory Gauge32, >> loadSystemUsedMemory Gauge32, >> loadLargestErlProcessUsedMemory Gauge32, >> >> To reproduce this problem, simply do an snmpwalk on a 64-bit system that >> has more than 4 GB of memory (mine is Ubuntu 7.10 x86_64 with 8 GB) and try >> to get the loadSystemTotalMemory.0 object. >> >> *Example of error:* >> >> $ snmpwalk -m ALL -u initial 127.0.0.1:4000 >> loadSystemTotalMemory.0 >> Error in packet. >> Reason: (genError) A general failure occured >> Failed object: OTP-OS-MON-MIB::loadSystemTotalMemory."" >> >> OTP-OS-MON-MIB::loadSystemTotalMemory."" = No Such Instance currently >> exists at this OID >> >> ------------- >> *Agent error message* >> >> I believe the agent error message below shows that the value of 8386678784 >> (not coincidentally, about 8 GB) is out of range. >> >> =ERROR REPORT==== 28-May-2008::00:26:03 === >> ** User error: Got 8386678784 from {os_mon_mib,load_table,[]}. Using >> wrongValue >> >> -------------- >> *Proposed Solution* >> >> The solution according to Martin is to change the Gauge32 types to be >> CounterBasedGauge64, from HCNUM-TC. >> >> I tried this in OTP-OS-MON-MIB as follows: >> >> 1. cd /usr/local/lib/erlang/lib/os_mon-2.1.5/mibs >> 2. cp OTP-OS-MON-MIB.mib OTP-OS-MON-MIB.mib.buggy >> 3. (Modified OTP-OS-MON-MIB.mib as shown in the diff output at the >> end of this email.) >> 4. cp /usr/share/snmp/mibs/HCNUM-TC.txt ./HCNUM-TC.mib >> 5. erlc -o ../priv/mibs/ -I ../priv/mibs -I >> ../../otp_mibs-1.0.4.1/priv/mibs HCNUM-TC.mib OTP-OS-MON-MIB.mib >> 6. Reloaded the agent >> >> >> This fixed the error, but exposed another possible bug. If otp-mib is not >> loaded into the agent, then the snmpwalk causes this error below. This is >> reproducible. I would think that if otp-mib was absent, the agent would at >> least show that a required dependency was not loaded and not crash. >> >> *** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT LOG *** >> apply: os_mon_mib,disk_table,[get_next,[],[0]] >> >> *** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT INFO *** >> Call to: >> Module: os_mon_mib >> Function: disk_table >> Args: [get_next,[],[0]] >> >> resulted in an exit >> >> {{badmatch,false}, >> [{snmp_generic,table_info,1}, >> {snmp_generic_mnesia,table_func,4}, >> {os_mon_mib,update_disk_table,0}, >> {snmp_shadow_table,update,3}, >> {snmp_shadow_table,table_func,4}, >> {snmpa_agent,dbg_apply,3}, >> {snmpa_agent,get_next_values_all_rows,6}, >> {snmpa_agent,get_next_table,4}]} >> >> =ERROR REPORT==== 28-May-2008::18:07:30 === >> ** User error: Invalid return value >> {'EXIT',{{badmatch,false},[{snmp_generic,table_info,1},{snmp_generic_mnesia,table_func,4},{os_mon_mib,update_disk_table,0},{snmp_shadow_table,update,3},{snmp_shadow_table,table_func,4},{snmpa_agent,dbg_apply,3},{snmpa_agent,get_next_values_all_rows,6},{snmpa_agent,get_next_table,4}]}} >> from {os_mon_mib,disk_table,[]} (get_next) >> -------------------------------------- >> ---------------------- >> $ diff -U 0 OTP-OS-MON-MIB.mib.buggy OTP-OS-MON-MIB.mib >> --- OTP-OS-MON-MIB.mib.buggy 2008-05-06 10:02:27.000000000 -0400 >> +++ OTP-OS-MON-MIB.mib 2008-05-28 17:28:42.000000000 -0400 >> @@ -14,0 +15,2 @@ >> + CounterBasedGauge64 >> + FROM HCNUM-TC >> @@ -111,2 +113,2 @@ >> - loadSystemTotalMemory Gauge32, >> - loadSystemUsedMemory Gauge32, >> + loadSystemTotalMemory CounterBasedGauge64, >> + loadSystemUsedMemory CounterBasedGauge64, >> @@ -114 +116 @@ >> - loadLargestErlProcessUsedMemory Gauge32, >> + loadLargestErlProcessUsedMemory CounterBasedGauge64, >> @@ -129 +131 @@ >> - SYNTAX Gauge32 >> + SYNTAX CounterBasedGauge64 >> @@ -138 +140 @@ >> - SYNTAX Gauge32 >> + SYNTAX CounterBasedGauge64 >> @@ -156 +158 @@ >> - SYNTAX Gauge32 >> + SYNTAX CounterBasedGauge64 >> @@ -283,4 +285,4 @@ >> - GROUP loadAlarmsGroup >> - DESCRIPTION >> - "This group is optional for systems implementing the >> - load supervison functionality." >> + --GROUP loadAlarmsGroup >> + --DESCRIPTION >> + -- "This group is optional for systems implementing the >> + -- load supervison functionality." >> @@ -291,4 +293,4 @@ >> - GROUP diskAlarmsGroup >> - DESCRIPTION >> - "This group is optional for systems implementing the >> - disk supervison functionality." >> + --GROUP diskAlarmsGroup >> + --DESCRIPTION >> + -- "This group is optional for systems implementing the >> + -- disk supervison functionality." >> >> -------------------------------------------- >> *The less serious bug >> >> *Maybe this is not a bug, but two groups are referenced that do not exist >> in OTP-OS-MON-MIB.mib: >> >> GROUP loadAlarmsGroup >> GROUP diskAlarmsGroup >> >> This causes snmpwalk to emit error messages. Commenting out the above >> lines seemed to have no effect other than stopping the snmpwalk error >> messages. >> >> Regards, >> Edwin Fine >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs >> > > > -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Fri Aug 22 19:09:30 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Fri, 22 Aug 2008 13:09:30 -0400 Subject: [erlang-bugs] Documentation request: integer encoding and truncation Message-ID: <6c2563b20808221009l1e5787f2q5d6c2f868b06c61f@mail.gmail.com> I refer to the following post. I was caught unawares by this apparently undocumented behavior. http://www.erlang.org/pipermail/erlang-questions/2007-July/027657.html May I strongly recommend placing this information (taken from the above post) in the Erlang Reference Manual, in the section on binaries. It may save other people time and confusion. A further question is whether or not this *should* be the behavior. As a language used for writing highly reliable systems, shouldn't this overflow condition be caught? Maybe as an optional run-time flag? Integer Encoding and Truncation <> is equivalent to <<(I band ((1 bsl N) - 1)):N>> That is, if the integer I can not be represented in N bits, the low N bits of the integer is put into the binary. Binaries work in a similar manner e.g. 1> <<1,2>> = << (<<1,2,3>>):2/binary >>. <<1,2>> Regards, Edwin Fine -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: From kenji.rikitake@REDACTED Sun Aug 24 06:03:00 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Sun, 24 Aug 2008 13:03:00 +0900 Subject: [erlang-bugs] Erlang R12B3 inet_ssl_dist does not work with ssl-3.9 In-Reply-To: <20080823081636.GA63811@k2r.org> References: <20080823081636.GA63811@k2r.org> Message-ID: <20080824040300.GA78691@k2r.org> I have been trying many times to start Erlang SSL distribution on R12B3 with ssl-3.9, which hasn't been successful. I'm running Erlang VM on FreeBSD 6.3-RELEASE. *** Problems: * 0. ssl-3.9 manual Chapter 5 does not represent the latest implementation. * 1. In creating start_ssl.boot as described in ssl-3.9 manual section 5.2, two warnings remain: content of the start_ssl.rel file: -- begin -- {release, {"OTP APN 181 01","R12B"}, {erts, "5.6.3"}, [{kernel,"2.12.3"}, {stdlib,"1.15.3"}, {ssl,"3.9"}]}. -- end -- after invoking erl (with no option): -- begin -- Erlang (BEAM) emulator version 5.6.3 [source] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.3 (abort with ^G) 1> systools:make_script("start_ssl",[]). *WARNING* ssl: Source code not found: ssl_pkix_oid.erl *WARNING* ssl: Source code not found: 'OTP-PKIX'.erl ok 2> -- end -- To suppress the warning messages, creating symbolic links worked: (cd $ERLANG_TOP/lib/ssl-3.9/src; ln -s ../pkix/OTP-PKIX.erl; ln -s ../pkix/ssk_pkix_old.erl;) * 2. Even after the boot script is built, ssl_server is not registered, which is supposed to be, as described in ssl manual Section 5.2. -- start -- erl -boot /my/directory/start_ssl Erlang (BEAM) emulator version 5.6.3 [source] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.3 (abort with ^G) 1> whereis(ssl_server). undefined 2> c:regs(). ** Registered procs on node nonode@REDACTED ** Name Pid Initial Call Reds Msgs application_controlle <0.5.0> erlang:apply/2 710 0 code_server <0.19.0> erlang:apply/2 80684 0 erl_prim_loader <0.2.0> erlang:apply/2 67923 0 error_logger <0.4.0> gen_event:init_it/6 286 0 file_server_2 <0.18.0> file_server:init/1 17399 0 global_group <0.17.0> global_group:init/1 78 0 global_name_server <0.11.0> global:init/1 67 0 inet_db <0.15.0> inet_db:init/1 165 0 init <0.0.0> otp_ring0:start/2 3522 0 kernel_safe_sup <0.26.0> supervisor:kernel/1 63 0 kernel_sup <0.9.0> supervisor:kernel/1 1319 0 rex <0.10.0> rpc:init/1 46 0 ssl_broker_sup <0.32.0> supervisor:ssl_broker_sup 60 0 ssl_connection_sup <0.34.0> supervisor:ssl_connection 60 0 ssl_manager <0.33.0> ssl_manager:init/1 68 0 ssl_sup <0.31.0> supervisor:ssl_sup/1 265 0 user <0.22.0> group:server/3 47 0 ** Registered ports on node nonode@REDACTED ** Name Id Command ok -- end -- * 3. By reading the source code, I found that ssl_server is no longer registered in ssl-3.9 (see ssl:ensure_old_ssl_started/0). So I tested as follows: erl -boot /my/directory/start_ssl -proto_dist inet_ssl 1: ssl:version() -> {ok,{"3.9","OpenSSL 0.9.7e-p1 25 Oct 2004", "OpenSSL 0.9.7e-p1 25 Oct 2004"}} 2: net_kernel:start([a1]) -> {error,{shutdown,{child,undefined,net_sup_dynamic, {erl_distribution,start_link,[[a1]]}, permanent,1000,supervisor, [erl_distribution]}}} * 4. I added SASL to the boot script (after stdlib and before ssl) to report the errors, and found: -- begin -- Erlang (BEAM) emulator version 5.6.3 [source] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.33.0>}, {name,alarm_handler}, {mfa,{alarm_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,sasl_safe_sup} started: [{pid,<0.34.0>}, {name,overload}, {mfa,{overload,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,sasl_sup} started: [{pid,<0.32.0>}, {name,sasl_safe_sup}, {mfa, {supervisor,start_link, [{local,sasl_safe_sup},sasl,safe]}}, {restart_type,permanent}, {shutdown,infinity}, {child_type,supervisor}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,sasl_sup} started: [{pid,<0.35.0>}, {name,release_handler}, {mfa,{release_handler,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === application: sasl started_at: nonode@REDACTED =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,ssl_sup} started: [{pid,<0.41.0>}, {name,ssl_broker_sup}, {mfa,{ssl_broker_sup,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,supervisor}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,ssl_sup} started: [{pid,<0.42.0>}, {name,ssl_manager}, {mfa,{ssl_manager,start_link,[]}}, {restart_type,permanent}, {shutdown,4000}, {child_type,worker}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === supervisor: {local,ssl_sup} started: [{pid,<0.43.0>}, {name,ssl_connection}, {mfa,{ssl_connection_sup,start_link,[]}}, {restart_type,permanent}, {shutdown,4000}, {child_type,supervisor}] =PROGRESS REPORT==== 24-Aug-2008::11:38:38 === application: ssl started_at: nonode@REDACTED Eshell V5.6.3 (abort with ^G) 1> ssl:version(). {ok,{"3.9","OpenSSL 0.9.7e-p1 25 Oct 2004", "OpenSSL 0.9.7e-p1 25 Oct 2004"}} 2> =PROGRESS REPORT==== 24-Aug-2008::11:38:48 === supervisor: {local,ssl_sup} started: [{pid,<0.48.0>}, {name,ssl_server}, {mfa,{ssl_server,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] 2> net_kernel:start([a1,shortnames). =PROGRESS REPORT==== 24-Aug-2008::11:39:07 === supervisor: {local,net_sup} started: [{pid,<0.51.0>}, {name,ssl_server_prim}, {mfa,{ssl_server,start_link_prim,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Aug-2008::11:39:07 === supervisor: {local,net_sup} started: [{pid,<0.52.0>}, {name,erl_epmd}, {mfa,{erl_epmd,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =PROGRESS REPORT==== 24-Aug-2008::11:39:07 === supervisor: {local,net_sup} started: [{pid,<0.53.0>}, {name,auth}, {mfa,{auth,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =INFO REPORT==== 24-Aug-2008::11:39:07 === Protocol: "alt_ssl": register error: {normal, {gen_server,call, [ssl_server_prim, {listen,<0.54.0>,{0,0,0,0},0,[],128}, infinity]}} {error,{shutdown,{child,undefined,net_sup_dynamic, {erl_distribution,start_link,[[a1,shortnames]]}, permanent,1000,supervisor, [erl_distribution]}}} 3> =CRASH REPORT==== 24-Aug-2008::11:39:07 === crasher: pid: <0.54.0> registered_name: net_kernel exception exit: {error,badarg} in function gen_server:init_it/6 initial call: gen:init_it(gen_server,<0.50.0>,<0.50.0>, {local,net_kernel}, net_kernel, {a1,shortnames,15000}, []) ancestors: [net_sup,kernel_sup,<0.8.0>] messages: [] links: [<0.50.0>] dictionary: [{longnames,false}] trap_exit: true status: running heap_size: 377 stack_size: 23 reductions: 269 neighbours: =SUPERVISOR REPORT==== 24-Aug-2008::11:39:07 === Supervisor: {local,net_sup} Context: start_error Reason: {'EXIT',nodistribution} Offender: [{pid,undefined}, {name,net_kernel}, {mfa,{net_kernel,start_link,[[a1,shortnames]]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =SUPERVISOR REPORT==== 24-Aug-2008::11:39:07 === Supervisor: {local,net_sup} Context: shutdown_error Reason: normal Offender: [{pid,<0.51.0>}, {name,ssl_server_prim}, {mfa,{ssl_server,start_link_prim,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] 3> c:regs(). ** Registered procs on node nonode@REDACTED ** Name Pid Initial Call Reds Msgs alarm_handler <0.33.0> gen_event:init_it/6 34 0 application_controlle <0.5.0> erlang:apply/2 920 0 code_server <0.19.0> erlang:apply/2 86519 0 erl_prim_loader <0.2.0> erlang:apply/2 76524 0 error_logger <0.4.0> gen_event:init_it/6 19948 0 file_server_2 <0.18.0> file_server:init/1 17537 0 global_group <0.17.0> global_group:init/1 78 0 global_name_server <0.11.0> global:init/1 67 0 inet_db <0.15.0> inet_db:init/1 164 0 init <0.0.0> otp_ring0:start/2 5008 0 kernel_safe_sup <0.26.0> supervisor:kernel/1 63 0 kernel_sup <0.9.0> supervisor:kernel/1 1375 0 overload <0.34.0> overload:init/1 45 0 release_handler <0.35.0> release_handler:init/1 1433 0 rex <0.10.0> rpc:init/1 46 0 sasl_safe_sup <0.32.0> supervisor:sasl/1 200 0 sasl_sup <0.31.0> supervisor:sasl/1 182 0 ssl_broker_sup <0.41.0> supervisor:ssl_broker_sup 60 0 ssl_connection_sup <0.43.0> supervisor:ssl_connection 60 0 ssl_manager <0.42.0> ssl_manager:init/1 68 0 ssl_server <0.48.0> ssl_server:init/1 1248 0 ssl_sup <0.40.0> supervisor:ssl_sup/1 344 0 user <0.22.0> group:server/3 12320 0 ** Registered ports on node nonode@REDACTED ** Name Id Command ok -- end -- *** So far I can't find any workaround for this. I suspect this glitch happened when ssl library internal structure has been changed in ssl-3.9. Please let me know how I can start up inet_ssl_dist on R12B3. Kenji Rikitake From nc@REDACTED Sun Aug 24 14:00:37 2008 From: nc@REDACTED (Nicolas Charpentier) Date: Sun, 24 Aug 2008 14:00:37 +0200 Subject: [erlang-bugs] Miss the key 'query_string' in the environment parameter when a ESI callback is called. Message-ID: <48B14D65.8000201@charpi.net> Hi Using the ESI feature of OTP R12B-3, I'm facing a bug. I'm doing 'GET' requests and I'm expecting a key 'query_string' in the Env parameter passed to my callback module as described in the documentation (http://www.erlang.org/doc/man/mod_esi.html#Module:Function-3) Obviously this value isn't mandatory as I can use the Input value but it seems to have a lack of documentation or a regression since OTP R10B-5. I didn't tested with R10B-5 but looking at mod_esi.erl code the query_string value seemed to exist in the Env parameters. I attach a patch to fix the problem. Regards, ---- Nicolas Charpentier http://charpi.net -------------- next part -------------- A non-text attachment was scrubbed... Name: bug_mod_esi.patch Type: text/x-diff Size: 685 bytes Desc: not available URL: From kenji.rikitake@REDACTED Tue Aug 26 04:45:43 2008 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Tue, 26 Aug 2008 11:45:43 +0900 Subject: [erlang-bugs] [erlang-questions] Erlang R12B3 inet_ssl_dist (SSL distribution) with ssl-3.9? In-Reply-To: <597c69660808250928o1699dec6ucbdbeedf503ae663@mail.gmail.com> References: <20080823081636.GA63811@k2r.org> <597c69660808250928o1699dec6ucbdbeedf503ae663@mail.gmail.com> Message-ID: <20080826024543.GA29444@k2r.org> Thanks Attila. I'm new to Erlang so your help is appreciated. I've tried the application:start/1 function, but things didn't change. The ssl-3.9/src/ssl_sup.hrl in R12B3 explicity disables the old ssl_server in the boot-time process registration by init([]). I also discovered ssl_esock port driver crashed with SIGSEGV on FreeBSD, when the net_kernel:start tries to listen to an SSL port. Testing this on WinXP SP3 hangs up the Erlang shell and no response returned, while the Ctrl-G intervention worked. I should conclude that at least the manual of ssl module about inet_ssl_dist (Section 5) should be thoroughly revised. So I cross-post this message to erlang-bugs also. Regards, Kenji Rikitake In the message <597c69660808250928o1699dec6ucbdbeedf503ae663@REDACTED> dated Mon, Aug 25, 2008 at 06:27:43PM +0200, Attila Babo writes: > All you need to start ssl from a boot file is to state ssl as required > application in your .app file. Without a proper boot file just start > it like application:start(ssl). I hope this helps! From bgustavsson@REDACTED Tue Aug 26 08:18:07 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Tue, 26 Aug 2008 08:18:07 +0200 Subject: [erlang-bugs] Documentation request: integer encoding and truncation In-Reply-To: <6c2563b20808221009l1e5787f2q5d6c2f868b06c61f@mail.gmail.com> References: <6c2563b20808221009l1e5787f2q5d6c2f868b06c61f@mail.gmail.com> Message-ID: <6672d0160808252318s23bae75xfed8fc9ed52fb4f@mail.gmail.com> 2008/8/22 Edwin Fine > I refer to the following post. I was caught unawares by this apparently > undocumented behavior. > > http://www.erlang.org/pipermail/erlang-questions/2007-July/027657.html > > May I strongly recommend placing this information (taken from the above > post) in the Erlang Reference Manual, in the section on binaries. It may > save other people time and confusion. A further question is whether or not > this *should* be the behavior. As a language used for writing highly > reliable systems, shouldn't this overflow condition be caught? Maybe as an > optional run-time flag? > > We consider the behavior to be a feature. I have now added some information about the behavior to the reference manual (to appear in R12B-4). /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Tue Aug 26 08:46:21 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Tue, 26 Aug 2008 02:46:21 -0400 Subject: [erlang-bugs] Integer truncation in binary conversion considered harmful Message-ID: <6c2563b20808252346k5800142bjb64ffbdacceefec5@mail.gmail.com> Bjorn, Thank you for updating the documentation. However, I strongly disagree that silently truncating integers in conversion to binaries is a feature. The huge number of bugs in C/C++ programming due to overflows in general, and the creation of secure integer libraries to prevent this, should be a strong indicator of the potential harm in allowing this. In "Programming Erlang", Joe Armstrong writes: "Erlang uses arbitrary-sized integers for performing integer arithmetic. In Erlang, integer arithmetic is exact, so you don't have to worry about arithmetic overflows or not being able to represent an integer in a cer- tain word size." But as soon as you convert to binary, that protection is lost and you *do*have to worry about integer overflows. Erlang is designed for programming fault-tolerant systems, yet this "feature" actually contributes to potential faults. The compiler and run-time should be there to help us, not hinder us. How difficult could it be to add *optional* run-time checking to detect this condition without a serious risk of adverse effects on the correctness of Erlang run-time execution? On Tue, Aug 26, 2008 at 2:18 AM, Bjorn Gustavsson wrote: > 2008/8/22 Edwin Fine > >> I refer to the following post. I was caught unawares by this apparently >> undocumented behavior. >> >> http://www.erlang.org/pipermail/erlang-questions/2007-July/027657.html >> >> May I strongly recommend placing this information (taken from the above >> post) in the Erlang Reference Manual, in the section on binaries. It may >> save other people time and confusion. A further question is whether or not >> this *should* be the behavior. As a language used for writing highly >> reliable systems, shouldn't this overflow condition be caught? Maybe as an >> optional run-time flag? >> >> > We consider the behavior to be a feature. > > I have now added some information about the behavior to the reference > manual (to appear in R12B-4). > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: From bgustavsson@REDACTED Tue Aug 26 09:24:02 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Tue, 26 Aug 2008 09:24:02 +0200 Subject: [erlang-bugs] Integer truncation in binary conversion considered harmful In-Reply-To: <6c2563b20808252346k5800142bjb64ffbdacceefec5@mail.gmail.com> References: <6c2563b20808252346k5800142bjb64ffbdacceefec5@mail.gmail.com> Message-ID: <6672d0160808260024j75f1129eo5a3fa04b3d11e3be@mail.gmail.com> On Tue, Aug 26, 2008 at 8:46 AM, Edwin Fine wrote: > How difficult could it be to add *optional* run-time checking to detect > this condition without a serious risk of adverse effects on the correctness > of Erlang run-time execution? > If checking is turned on for the entire run-time system, library code that depends on the truncation could fail. I think it would be better to add optional support in the compiler to turn on checks (either for an entire module, or for individual segments of a binary). If someone writes an EEP, we will consider implementing it. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Tue Aug 26 09:54:15 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Tue, 26 Aug 2008 03:54:15 -0400 Subject: [erlang-bugs] Integer truncation in binary conversion considered harmful In-Reply-To: <6672d0160808260024j75f1129eo5a3fa04b3d11e3be@mail.gmail.com> References: <6c2563b20808252346k5800142bjb64ffbdacceefec5@mail.gmail.com> <6672d0160808260024j75f1129eo5a3fa04b3d11e3be@mail.gmail.com> Message-ID: <6c2563b20808260054r5e41b427lbfc182dca0b5caa9@mail.gmail.com> Bjorn, That would work, too, although it could be considered that libraries that depend on the truncation behavior may in fact unwittingly be harboring truncation bugs, and might be better served by explicitly truncating the integer down to size prior to converting to binary. Perhaps a truncate(Integer, NumBytes) BIF could be provided. Still, being able to turn on range checking for a specific binary conversion (-pragma(range-check), anyone?) or a module might be a very nice compromise feature. I'll look into what it takes to write an EEP and submit one if I think I can get it right ;-) Regards, Ed On Tue, Aug 26, 2008 at 3:24 AM, Bjorn Gustavsson wrote: > On Tue, Aug 26, 2008 at 8:46 AM, Edwin Fine < > erlang-questions_efine@REDACTED> wrote: > >> How difficult could it be to add *optional* run-time checking to detect >> this condition without a serious risk of adverse effects on the correctness >> of Erlang run-time execution? >> > > If checking is turned on for the entire run-time system, library code that > depends on the truncation could fail. > > I think it would be better to add optional support in the compiler to turn > on checks (either for an entire module, or for individual segments of > a binary). > > If someone writes an EEP, we will consider implementing it. > > /Bjorn > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: From erlang-questions_efine@REDACTED Wed Aug 27 06:46:46 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Wed, 27 Aug 2008 00:46:46 -0400 Subject: [erlang-bugs] [erlang-questions] Integer truncation in binary conversion considered harmful In-Reply-To: <351137C8-CC35-4C87-9F1D-F40BA7E0ED31@cs.otago.ac.nz> References: <6c2563b20808252346k5800142bjb64ffbdacceefec5@mail.gmail.com> <18088_1219736056_m7Q7Y9lR018396_6672d0160808260024j75f1129eo5a3fa04b3d11e3be@mail.gmail.com> <351137C8-CC35-4C87-9F1D-F40BA7E0ED31@cs.otago.ac.nz> Message-ID: <6c2563b20808262146v66906222j4d8315780c8bd3e1@mail.gmail.com> Awesome EEP, Richard. Thanks so much for showing me (intentionally or otherwise) how it's done. Maybe I can do some of my own in future now that I have a model! Thanks also for immediately grokking the value of having such a run-time check. Disclaimer: This is Sincere Praise and Appreciation, not Loathsome Toadying and Brown-Nosing. Regards, Edwin Fine On Tue, Aug 26, 2008 at 10:58 PM, Richard A. O'Keefe wrote: > On 26 Aug 2008, at 7:24 pm, Bjorn Gustavsson wrote: > >> If someone writes an EEP, we will consider implementing it. >> > > Done. > > > > > > > -- For every expert there is an equal and opposite expert - Arthur C. Clarke -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Wed Aug 27 07:22:59 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Wed, 27 Aug 2008 07:22:59 +0200 Subject: [erlang-bugs] escript man page Message-ID: <1219814579.4363.61.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Greetings, I would like to ask for one correction (and one clarification) on the escript man page (as found here: http://erlang.org/doc/man/escript.html). 1 Correction. The man page says: If you know the location of the escript executable, the first line can directly give the path to escript. For instance: #!/usr/local/bin/escript factorial That is not correct and should be #!/usr/local/bin/escript Reason: The factorial string after /usr/local/bin/escript is included in the call to the factorial script and means that the script will always say: usage: factorial integer even when called like this: ./factorial 2 2 Clarification I can not, on the man page, find the very important information (IMHO) that when escript starts it has trap_exit set to true. That should be added, please. bengt From zl9d97p02@REDACTED Wed Aug 27 07:51:50 2008 From: zl9d97p02@REDACTED (Simon Cornish) Date: Tue, 26 Aug 2008 22:51:50 -0700 Subject: [erlang-bugs] megaco_flex_scanner doesn't work under Solaris10 x86 Message-ID: <28954-42507@sneakemail.com> Hi, I don't know if anyone uses this - I don't, I was chasing a bug with my own linked-in driver - but the megaco_flex_scanner obviously isn't built with the correct PIC options. [simon@REDACTED iss]$ erl Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [async-threads:0] [kernel-poll:false] Eshell V5.6.3 (abort with ^G) 1> megaco_flex_scanner:start(). {error,{load_driver,"ld.so.1: beam: fatal: relocation error: R_AMD64_PC32: file /usr/local/lib/erlang/lib/megaco-3.8/priv/lib/megaco_flex_scanner_drv_mt.so: symbol main: value 0x280017e0694 does not fit"}} R12B-3 configured with "CC=gcc -m64". The other linked-in drivers that come with the distribution (eg. crypto_drv, asn1_erl_drv, etc) work ok. (app@REDACTED)1> erl_ddll:loaded_drivers(). {ok,["async","efile","tcp_inet","udp_inet","zlib_drv", "ram_file_drv","tty_sl","bets_drv","crypto_drv"]} Regards, Simon From bgustavsson@REDACTED Wed Aug 27 17:14:39 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 27 Aug 2008 17:14:39 +0200 Subject: [erlang-bugs] escript man page In-Reply-To: <1219814579.4363.61.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> References: <1219814579.4363.61.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Message-ID: <6672d0160808270814w4394fac4mb2fa7879c8de8373@mail.gmail.com> On Wed, Aug 27, 2008 at 7:22 AM, Bengt Kleberg wrote: > Greetings, > > I would like to ask for one correction (and one clarification) on the > escript man page (as found here: > http://erlang.org/doc/man/escript.html). > > 1 Correction. > > The man page says: > > If you know the location of the escript executable, the first line can > directly give the path to escript. For instance: > #!/usr/local/bin/escript factorial > > That is not correct and should be > #!/usr/local/bin/escript > > Reason: The factorial string after /usr/local/bin/escript is included in > the call to the factorial script and means that the script will always > say: > usage: factorial integer > > even when called like this: > ./factorial 2 > > Thanks! It will be corrected in R12B-4. > > 2 Clarification > > I can not, on the man page, find the very important information (IMHO) > that when escript starts it has trap_exit set to true. That should be > added, please. > That trap_exit is true is not intentional. Maybe it would be better to change the implementation to set the trap_exit flag to false instead (to follow the principle of least surprise)? /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Thu Aug 28 06:52:35 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Thu, 28 Aug 2008 06:52:35 +0200 Subject: [erlang-bugs] escript man page In-Reply-To: <6672d0160808270814w4394fac4mb2fa7879c8de8373@mail.gmail.com> References: <1219814579.4363.61.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> <6672d0160808270814w4394fac4mb2fa7879c8de8373@mail.gmail.com> Message-ID: <1219899156.23851.5.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> If trap_exit is supposed to be false (which, I agree, is what I expect) then either I have made a mistake somewhere(*), or there is a bug in escript (not the man page). (*) test program: #! /usr/bin/env escript main(_) -> io:fwrite( "~w~n", [erlang:process_info(erlang:self(), trap_exit)] ). environment: ; which escript /app/erlang/otp_R11B05/bin/escript ; uname -a Linux seasc0642 2.6.16.53-0.16-smp #1 SMP Tue Oct 2 16:57:49 UTC 2007 i686 i686 i386 GNU/Linux bengt On Wed, 2008-08-27 at 17:14 +0200, Bjorn Gustavsson wrote: > On Wed, Aug 27, 2008 at 7:22 AM, Bengt Kleberg > wrote: > Greetings, > > I would like to ask for one correction (and one clarification) > on the > escript man page (as found here: > http://erlang.org/doc/man/escript.html). > > 1 Correction. > > The man page says: > > If you know the location of the escript executable, the first > line can > directly give the path to escript. For instance: > #!/usr/local/bin/escript factorial > > That is not correct and should be > #!/usr/local/bin/escript > > Reason: The factorial string after /usr/local/bin/escript is > included in > the call to the factorial script and means that the script > will always > say: > usage: factorial integer > > even when called like this: > ./factorial 2 > > Thanks! It will be corrected in R12B-4. > > > 2 Clarification > > I can not, on the man page, find the very important > information (IMHO) > that when escript starts it has trap_exit set to true. That > should be > added, please. > > That trap_exit is true is not intentional. > > Maybe it would be better to change the implementation to set the > trap_exit flag to false instead > (to follow the principle of least surprise)? > > > /Bjorn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > From bgustavsson@REDACTED Thu Aug 28 10:32:03 2008 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Thu, 28 Aug 2008 10:32:03 +0200 Subject: [erlang-bugs] escript man page In-Reply-To: <1219899156.23851.5.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> References: <1219814579.4363.61.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> <6672d0160808270814w4394fac4mb2fa7879c8de8373@mail.gmail.com> <1219899156.23851.5.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Message-ID: <6672d0160808280132u1d3a2bf7n6c9d112084bf0b3f@mail.gmail.com> On Thu, Aug 28, 2008 at 6:52 AM, Bengt Kleberg wrote: > If trap_exit is supposed to be false (which, I agree, is what I expect) > then either I have made a mistake somewhere(*), or there is a bug in > escript (not the man page). > I didn't doubt that trap_exit indeed is set to true. I confirmed it using a similar test program as yours. What I meant was that trap_exit is set to true by accident, not design. It happens that any command run by '-run' runs in a process where trap_exit has been turned on. I don't dare to change the general behaviour of '-run' and '-s' in a maintenance release, but I think it is safe to change escript (there can't be too many escripts out there depending on trap_exit being true) rather than documenting a counter-intuitive behaviour. Therefore, I have now changed escript to reset trap_exit to false before calling the main/1 function of the script. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB -------------- next part -------------- An HTML attachment was scrubbed... URL: