From badlop@REDACTED Sun Jun 1 13:58:49 2008 From: badlop@REDACTED (Badlop) Date: Sun, 1 Jun 2008 13:58:49 +0200 Subject: [erlang-bugs] Sum small floats and get erroneous result in R12B-2 In-Reply-To: <18494.22030.843744.50472@gargle.gargle.HOWL> References: <732f49190805280427g57151a7eyd9e8f5ce9f33c1b2@mail.gmail.com> <18494.22030.843744.50472@gargle.gargle.HOWL> Message-ID: <732f49190806010458h44380d56q5842a10f2d9fa3e1@mail.gmail.com> Thanks to Hans Bolinder and Matthew Dempsky. The rest of this email is just a summary for reference. > [Badlop:] >> 2> 20.15 + 2.01. >> 22.159999999999997 On Thu, May 29, 2008 at 9:06 AM, Hans Bolinder wrote: > The floats representing 20.15 and 2.01 are not exactly equal to 20.15 > and 2.01 respectively. The sum is some other float than the one > representing 22.16. > > Floats are printed accurately as the shortest, correctly rounded > string. This is a new feature in R12B-2; Ah. That explains why R11B-5 and R12B-2 provide different values: > OTP-7084 The functions io_lib:write/1,2 and io_lib:print/1,4 have been > changed when it comes to writing floating point numbers. This > change affects the control sequences p, P, w, and W of the > io_lib module. (Thanks to Bob Ippolito for code > contribution.) http://www.erlang.org/download/otp_src_R12B-2.readme In Erlang/OTP R11B-5 and older, this is obtained: 1> 2.01+0.01. 2.02000 2> 1.123456789. 1.12346 The result 1> is correct just by coincidence: in reality the sum returns 2.0199999999999996, but this value is rounded internally using io_lib before being printed in the shell. As a result 2.02000 is printed. Similar results are obtained with: CLISP 2.44, Awk 3.1.5, Octave 3.0.1, R 2.7.0, Yorick 2.1.05, Maxima 5.13.0, ARIBAS 1.63, Google online calculator. In Erlang R12B-2 this is obtained: 1> 2.01 + 0.01. 2.0199999999999996 2> 1.23546789123456789123. 1.2354678912345678 Similar results are obtained with: Python 2.4.4, GHCi 6.8.2, OCaml 3.10.2. So, this is not a bug in OTP, but a limitation in how most programs represent floats: IEEE Standard for Binary Floating-Point Arithmetic (IEEE 754) It is more precise to calculate 2.01 + 0.01 with pencil and paper. Or use special programs like 'bc': $ bc bc 1.06.94 - An arbitrary precision calculator language Copyright 1991-1994, 1997, 1998, 2000, 2004, 2006 Free Software Foundation, Inc. This is free software with ABSOLUTELY NO WARRANTY. For details type `warranty'. 2.01 + 0.01 2.02 20.15 + 2.01 22.16 0.111111111111111111111111111111111111111111111111111111111111112 + 0.1 .211111111111111111111111111111111111111111111111111111111111112 --- From egil@REDACTED Mon Jun 2 11:39:41 2008 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Mon, 02 Jun 2008 11:39:41 +0200 Subject: [erlang-bugs] OTP-OS-MON-MIB bugs In-Reply-To: <6c2563b20805281512kd94b832r5b8473d9f0fd180d@mail.gmail.com> References: <6c2563b20805281512kd94b832r5b8473d9f0fd180d@mail.gmail.com> Message-ID: <4843BFDD.4070601@erix.ericsson.se> 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 From raimo+erlang-bugs@REDACTED Mon Jun 2 12:09:25 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 2 Jun 2008 12:09:25 +0200 Subject: [erlang-bugs] Password reminders Message-ID: <20080602100925.GA6800@erix.ericsson.se> The erlang.org mailing list's configurations have changed to not send password reminders any more, since it is a security risc to do so. -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From paul-trapexit@REDACTED Tue Jun 3 06:57:50 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Mon, 2 Jun 2008 21:57:50 -0700 (PDT) Subject: [erlang-bugs] erl_compare_ext fails to compare tuples properly Message-ID: the attached patch (which fixes the problem) is pretty clear, but i also attached a C program which demonstrates the problem just in case. -- p In an artificial world, only extremists live naturally. -- Paul Graham -------------- next part -------------- --- /usr/lib/erlang/lib/erl_interface-3.5.5.3/src/legacy/erl_marshal.c 2007-08-05 08:48:58.000000000 -0700 +++ erl_marshal.c 2008-06-02 20:20:10.000000000 -0700 @@ -1502,7 +1502,7 @@ case ERL_SMALL_TUPLE_EXT: i = *(*e1)++; j = *(*e2)++; if (i < j) return -1; - if (j > j ) return 1; + if (i > j) return 1; while (i--) { if ((j = compare_top_ext(e1, e2))) return j; } @@ -1513,7 +1513,7 @@ j = (**e2 << 24) | ((*e2)[1]) << 16| ((*e2)[2]) << 8| ((*e2)[3]) ; *e2 += 4; if (i < j) return -1; - if (j > j ) return 1; + if (i > j) return 1; while (i--) { if ((j = compare_top_ext(e1, e2))) return j; } -------------- next part -------------- A non-text attachment was scrubbed... Name: erl_compare_ext_bug.tgz Type: application/x-gtar Size: 9337 bytes Desc: URL: From egil@REDACTED Tue Jun 3 10:06:04 2008 From: egil@REDACTED (=?ISO-8859-1?Q?Bj=F6rn-Egil_Dahlberg?=) Date: Tue, 03 Jun 2008 10:06:04 +0200 Subject: [erlang-bugs] erl_compare_ext fails to compare tuples properly In-Reply-To: References: Message-ID: <4844FB6C.3060905@erix.ericsson.se> Thank you for pointing out this problem. You made it very clear about what went wrong with the attached files. Much appreciated. The corrections will be included in upcoming release. Regards, Bj?rn-Egil Erlang/OTP Paul Mineiro wrote: > the attached patch (which fixes the problem) is pretty clear, but i also > attached a C program which demonstrates the problem just in case. > > -- p > > In an artificial world, only extremists live naturally. > > -- Paul Graham > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From anders.nygren@REDACTED Tue Jun 3 18:49:52 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Tue, 3 Jun 2008 11:49:52 -0500 Subject: [erlang-bugs] ssh documentation Message-ID: In the documentation of ssh_cm:listen it says that pwdfun shall return true | false. Actually it should be true | {true, Handle} | {false, String} /Anders From erik_demming@REDACTED Wed Jun 4 17:57:48 2008 From: erik_demming@REDACTED (Erik Demming) Date: Wed, 4 Jun 2008 15:57:48 +0000 (GMT) Subject: [erlang-bugs] Segmentation fault in Erlang R12B Message-ID: <342765.45085.qm@web23109.mail.ird.yahoo.com> I encounter a segmentation fault running Erlang (BEAM) emulator version 5.6.2 [source] [64-bit] [smp:2] [async-threads:0] [kernel-poll:false] Linux 2.6.18-6-amd64 #1 SMP x86_64 GNU/Linux My Erlang program is handling web-requests (GET) storing them in an ets table, periodically switching the ets table by creating a new table and sending the finished ets table data to another remote erlang node. Here the shortcut version of what am I doing:     DataList = ets:tab2list(FinishedEts),     Data = term_to_binary(DataList),     gen_server:call(Pid, {data, Data}), The segfault is not reproducible it occurs in a few minutes after start of the web server. Load on the server is not an issue - only a 50 Req/s. Segfault also comes after switching off smp and kernel-poll. I also saved the last block (DataList) to a file which caused the segfault. But manually re-sending the block did not lead to a segfault. The problem exists on all R12B-x versions. On installing R11B-5 on all servers no segfault was generated at all. Here you can see what valgrind could identify: ==6149== Memcheck, a memory error detector. ==6149== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al. ==6149== Using LibVEX rev 1658, a library for dynamic binary translation. ==6149== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP. ==6149== Using valgrind-3.2.1-Debian, a dynamic binary instrumentation framework. ==6149== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al. ==6149== For more details, rerun with: -v ==6149== ==6149== My PID = 6149, parent PID = 1.  Prog and args are: ==6149==    /usr/local/lib/erlang/erts-5.6.2/bin/beam.smp ==6149==    -- ==6149==    -root ==6149==    /usr/local/lib/erlang ==6149==    -progname ==6149==    erl ==6149==    -- ==6149==    -home ==6149==    /root ==6149==    -name ==6149==    srv ==6149==    -setcookie ==6149==    xxxx ==6149==    -noshell ==6149==    -eval ==6149==    error_logger:logfile({open, '../log/log.txt'}). ==6149==    -eval ==6149==    reloader:start(). ==6149==    -eval ==6149==    net_adm:ping('manager@REDACTED'). ==6149==    -eval ==6149==    net_adm:ping('dist@REDACTED'). ==6149==    -eval ==6149==    net_adm:ping('dist@REDACTED'). ==6149==    -eval ==6149==    application:start(webnode). ==6149==    -eval ==6149==    net_adm:ping('dist@REDACTED'). ==6149==    -eval ==6149==    net_adm:ping('dist@REDACTED'). ==6149== ==6149== Thread 6: ==6149== Invalid read of size 8 ==6149==    at 0x45A8F2: copy_struct (copy.c:440) ==6149==    by 0x47783E: erts_send_message (erl_message.c:734) ==6149==    by 0x469E0A: do_send (bif.c:1842) ==6149==    by 0x46A3D5: send_2 (bif.c:1918) ==6149==    by 0x4D594A: process_main (beam_emu.c:1352) ==6149==    by 0x47C2A9: sched_thread_func (erl_process.c:741) ==6149==    by 0x51CBD3: thr_wrapper (ethread.c:474) ==6149==    by 0x5007F19: start_thread (in /lib/libpthread-2.3.6.so) ==6149==    by 0x52E95D1: clone (in /lib/libc-2.3.6.so) ==6149==  Address 0x579E058 is 0 bytes after a block of size 262,184 alloc'd ==6149==    at 0x4A1B858: malloc (vg_replace_malloc.c:149) ==6149==    by 0x4F06FB: erts_sys_alloc (sys.c:2415) ==6149==    by 0x42E89D: create_carrier (erl_alloc_util.c:484) ==6149==    by 0x42EF7F: erts_alcu_start (erl_alloc_util.c:2966) ==6149==    by 0x434E26: erts_gfalc_start (erl_goodfit_alloc.c:241) ==6149==    by 0x42216F: start_au_allocator (erl_alloc.c:771) ==6149==    by 0x42892F: erts_alloc_init (erl_alloc.c:575) ==6149==    by 0x43B95E: early_init (erl_init.c:640) ==6149==    by 0x43BAC8: erl_start (erl_init.c:669) ==6149==    by 0x420198: main (erl_main.c:28) ==6149== ==6149== Invalid read of size 8 ==6149==    at 0x45A8E0: copy_struct (copy.c:441) ==6149==    by 0x47783E: erts_send_message (erl_message.c:734) ==6149==    by 0x469E0A: do_send (bif.c:1842) ==6149==    by 0x46A3D5: send_2 (bif.c:1918) ==6149==    by 0x4D594A: process_main (beam_emu.c:1352) ==6149==    by 0x47C2A9: sched_thread_func (erl_process.c:741) ==6149==    by 0x51CBD3: thr_wrapper (ethread.c:474) ==6149==    by 0x5007F19: start_thread (in /lib/libpthread-2.3.6.so) ==6149==    by 0x52E95D1: clone (in /lib/libc-2.3.6.so) ==6149==  Address 0x579E060 is 8 bytes after a block of size 262,184 alloc'd ==6149==    at 0x4A1B858: malloc (vg_replace_malloc.c:149) ==6149==    by 0x4F06FB: erts_sys_alloc (sys.c:2415) ==6149==    by 0x42E89D: create_carrier (erl_alloc_util.c:484) ==6149==    by 0x42EF7F: erts_alcu_start (erl_alloc_util.c:2966) ==6149==    by 0x434E26: erts_gfalc_start (erl_goodfit_alloc.c:241) ==6149==    by 0x42216F: start_au_allocator (erl_alloc.c:771) ==6149==    by 0x42892F: erts_alloc_init (erl_alloc.c:575) ==6149==    by 0x43B95E: early_init (erl_init.c:640) ==6149==    by 0x43BAC8: erl_start (erl_init.c:669) ==6149==    by 0x420198: main (erl_main.c:28) ==6149== ==6149== Process terminating with default action of signal 11 (SIGSEGV) ==6149==  Bad permissions for mapped region at address 0x585E000 ==6149==    at 0x45A8E0: copy_struct (copy.c:441) ==6149==    by 0x47783E: erts_send_message (erl_message.c:734) ==6149==    by 0x469E0A: do_send (bif.c:1842) ==6149==    by 0x46A3D5: send_2 (bif.c:1918) ==6149==    by 0x4D594A: process_main (beam_emu.c:1352) ==6149==    by 0x47C2A9: sched_thread_func (erl_process.c:741) ==6149==    by 0x51CBD3: thr_wrapper (ethread.c:474) ==6149==    by 0x5007F19: start_thread (in /lib/libpthread-2.3.6.so) ==6149==    by 0x52E95D1: clone (in /lib/libc-2.3.6.so) ==6149== ==6149== ERROR SUMMARY: 56217 errors from 2 contexts (suppressed: 8 from 1) ==6149== malloc/free: in use at exit: 16,315,457 bytes in 38 blocks. ==6149== malloc/free: 46,027 allocs, 45,989 frees, 21,041,414 bytes allocated. ==6149== For counts of detected errors, rerun with: -v ==6149== searching for pointers to 38 not-freed blocks. ==6149== checked 226,037,216 bytes. ==6149== ==6149== LEAK SUMMARY: ==6149==    definitely lost: 0 bytes in 0 blocks. ==6149==      possibly lost: 680 bytes in 5 blocks. ==6149==    still reachable: 16,314,777 bytes in 33 blocks. ==6149==         suppressed: 0 bytes in 0 blocks. ==6149== Reachable blocks (those to which a pointer was found) are not shown. ==6149== To see them, rerun with: --show-reachable=yes Would be great if anybody has a clue on that. Thanks in advance, Erik __________________________________________________________ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matthew@REDACTED Wed Jun 4 20:28:13 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Wed, 4 Jun 2008 11:28:13 -0700 Subject: [erlang-bugs] Segmentation fault in Erlang R12B In-Reply-To: <342765.45085.qm@web23109.mail.ird.yahoo.com> References: <342765.45085.qm@web23109.mail.ird.yahoo.com> Message-ID: 2008/6/4 Erik Demming : > Here the shortcut version of what am I doing: > DataList = ets:tab2list(FinishedEts), > Data = term_to_binary(DataList), > gen_server:call(Pid, {data, Data}), Do you know which step here caused the segmentation fault? What data types are you storing in the ets table? Anything other than lists, tuples, numbers, and/or binaries? If term_to_binary succeeds, how big is Data when you have a segfault? From anders.nygren@REDACTED Thu Jun 5 06:22:07 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 4 Jun 2008 23:22:07 -0500 Subject: [erlang-bugs] ssh_sftp documentation Message-ID: In the documentation for ssh_sftp:pread/4 it says that Position = integer() I think the correct type is the same as in ssh_sftp:position Location = Offset | {bof, Offset} | {cur, Offset} | {eof, Offset} | bof | cur | eof Offset = int() /Anders From anders.nygren@REDACTED Thu Jun 5 06:37:33 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 4 Jun 2008 23:37:33 -0500 Subject: [erlang-bugs] ssh_sftp documentation Message-ID: In the documentation for ssh_sftp:pread/4 it says that Position = integer() I think the correct type is the same as in ssh_sftp:position Location = Offset | {bof, Offset} | {cur, Offset} | {eof, Offset} | bof | cur | eof Offset = int() /Anders From ingela@REDACTED Thu Jun 5 10:07:21 2008 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 05 Jun 2008 10:07:21 +0200 Subject: [erlang-bugs] ssh_sftp documentation In-Reply-To: References: Message-ID: <48479EB9.5080409@erix.ericsson.se> Hi! Thank you for reporting this and other issues in previous mails. We are in the process of refactoring the ssh-application and there is much room for improvement of the documentation, we will look over this. Regards Ingela - Erlang/OTP, Ericsson Anders Nygren wrote: > In the documentation for ssh_sftp:pread/4 it says that > Position = integer() > > I think the correct type is the same as in ssh_sftp:position > Location = Offset | {bof, Offset} | {cur, Offset} | {eof, Offset} | > bof | cur | eof > Offset = int() > > /Anders > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From erik_demming@REDACTED Thu Jun 5 10:23:35 2008 From: erik_demming@REDACTED (Erik Demming) Date: Thu, 5 Jun 2008 08:23:35 +0000 (GMT) Subject: [erlang-bugs] Segmentation fault in Erlang R12B In-Reply-To: Message-ID: <438954.25624.qm@web23108.mail.ird.yahoo.com> As you can see from the call-path in valgrind output, when sending a message the emulator tries to call copy_struct which leads to the problem a few warnings later. If we uncommented the gen_server:call no segfault emerged. Here is a modified example of what we store in ets and try to send. Output from ets:tab2list: [{106, binary(record)}, {84, binary(record)}, {77, binary(record),...}] A few tens of those records are normally stored until sending them. The records have following structure: {rec,1212578249037785004, 4, "192.168.2.1", 1212578249, 1212578249037785004,      1212578249037785004, 0, "www.somedomain.org", "/path/to/something", '', 0, 1, 0, '', 0, '', 0, '',      0, '', 0, '',     "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)",      2} Only IP, BIGNUMS, domain, path and user-agent changes on each record. We use term_to_binary(Rec) also term_to_binary(Rec, [{compressed,N}]) leads to same problem. Sorry, I cannot provide info for size of binary - tell me if you really need that I will provide that info later. --- Matthew Dempsky <matthew@REDACTED> schrieb am Mi, 4.6.2008: Von: Matthew Dempsky <matthew@REDACTED> Betreff: Re: [erlang-bugs] Segmentation fault in Erlang R12B An: erik_demming@REDACTED CC: erlang-bugs@REDACTED Datum: Mittwoch, 4. Juni 2008, 20:28 2008/6/4 Erik Demming <erik_demming@REDACTED>: > Here the shortcut version of what am I doing: > DataList = ets:tab2list(FinishedEts), > Data = term_to_binary(DataList), > gen_server:call(Pid, {data, Data}), Do you know which step here caused the segmentation fault? What data types are you storing in the ets table? Anything other than lists, tuples, numbers, and/or binaries? If term_to_binary succeeds, how big is Data when you have a segfault? __________________________________________________________ Gesendet von Yahoo! Mail. Dem pfiffigeren Posteingang. http://de.overview.mail.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From vlm@REDACTED Thu Jun 5 12:09:05 2008 From: vlm@REDACTED (Lev Walkin) Date: Thu, 05 Jun 2008 03:09:05 -0700 Subject: [erlang-bugs] OTP ssl server death Message-ID: <4847BB41.5020106@lionet.info> Hello, My erl-5.6.2 system dies with ssl server failure on FreeBSD system (which is known to produce certain error-codes like EPIPE quite unlike linux or ones): ================================================================= esock: Got connect request while PASSIVE =ERROR REPORT==== 2-Jun-2008::23:58:14 === ** Generic server ssl_server terminating ** Last message in was {'EXIT',#Port<0.200>,epipe} ** When Server state == {st,#Port<0.200>,36930,false, [{5,<0.112.0>,[]}], [{5,<0.21926.1528>, {<0.21926.1528>,#Ref<0.0.430.130623>}}], 60195,59,"OpenSSL 0.9.8g 19 Oct 2007", "OpenSSL 0.9.8g 19 Oct 2007", "DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA2 6-SHA:CAMELLIA256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AE 128-SHA:AES128-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:CAMELLIA128-SHA:IDEA-CBC-SHA:IDEA-CBC-MD5:RC2-CBC-MD :RC4-SHA:RC4-MD5:RC4-MD5:EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP-EDH-RSA-DES-CBC-SHA:EXP-ED -DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:EXP-RC4-MD5"} ** Reason for termination == ** epipe =CRASH REPORT==== 2-Jun-2008::23:58:14 === crasher: pid: <0.111.0> registered_name: ssl_server exception exit: epipe in function gen_server:terminate/6 initial call: gen:init_it(gen_server,<0.44.0>,<0.44.0>, {local,ssl_server}, ssl_server,[],[]) ancestors: [ssl_sup,<0.43.0>] messages: [] links: [<0.112.0>,<0.21926.1528>,<0.44.0>] dictionary: [] trap_exit: true status: running heap_size: 4181 stack_size: 23 reductions: 647269 neighbours: =SUPERVISOR REPORT==== 2-Jun-2008::23:58:14 === Supervisor: {local,ssl_sup} Context: child_terminated Reason: epipe Offender: [{pid,<0.111.0>}, {name,ssl_server}, {mfa,{ssl_server,start_link,[]}}, {restart_type,permanent}, {shutdown,2000}, {child_type,worker}] =ERROR REPORT==== 2-Jun-2008::23:58:14 === ** Generic server <0.112.0> terminating ** Last message in was {'EXIT',<0.111.0>,epipe} ** When Server state == {st,listener,<0.111.0>,<0.110.0>,<0.110.0>,5,false, [{mode,binary}, {ip,{0,0,0,0}}, {packet,http}, {active,false}, {nodelay,false}, {backlog,128}, {keyfile,"/key.pem"}, {certfile,"/cert.pem"}, {cacertfile,"/cert.pem"}, {verify,0}, {password,"jskit"}, {ciphers,"MEDIUM"}, {depth,1}], {sslsocket,5,<0.112.0>}, nil,nil,open,false,false} ** Reason for termination == ** epipe =CRASH REPORT==== 2-Jun-2008::23:58:14 === crasher: pid: <0.112.0> registered_name: [] exception exit: epipe in function gen_server:terminate/6 initial call: gen:init_it(gen_server,<0.45.0>,<0.45.0>,ssl_broker, [<0.110.0>,listener], []) ancestors: [ssl_broker_sup,ssl_sup,<0.43.0>] messages: [] links: [<0.110.0>,<0.45.0>] dictionary: [] trap_exit: true status: running heap_size: 610 stack_size: 23 reductions: 1222163 neighbours: =ERROR REPORT==== 2-Jun-2008::23:58:14 === yaws: Failed to accept - terminating: {error,epipe} ============================================================== ...and then YAWS fails in flames. Any suggestions and/or pointers? This happens from time to time on my machines, but not consistently reproducible. -- Lev Walkin vlm@REDACTED From paul-trapexit@REDACTED Sun Jun 8 06:59:42 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sat, 7 Jun 2008 21:59:42 -0700 (PDT) Subject: [erlang-bugs] documentation bug (?) Message-ID: the dets documentation about init_table says: "If the type of the table is set and there is more than one object with a given key, one of the objects is chosen. This is not necessarily the last object with the given key in the sequence of objects returned by the input functions. Extra objects should be avoided, or the file will be unnecessarily fragmented. This holds also for duplicated objects stored in tables of type duplicate_bag." having stared at this for a while, i think it should say: "... holds also for duplicated objects stored in tables of type bag".[1] even clearer would be: "... input functions. Duplicate keys should be avoided, or the file will be unnecessarily fragmented. This holds also for duplicated objects stored in tables of type bag." -- p From paul-trapexit@REDACTED Mon Jun 9 04:46:27 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Sun, 8 Jun 2008 19:46:27 -0700 (PDT) Subject: [erlang-bugs] ets:init_table/2 documentation bug Message-ID: i found a similar problem in the ets documentation. "If the type of the table is set and there is more than one object with a given key, one of the objects is chosen. This is not necessarily the last object with the given key in the sequence of objects returned by the input functions. This holds also for duplicated objects stored in tables of type duplicate_bag." i believe that should end with "... stored in tables of type bag" ... otherwise, why should any records be dropped in a table of type duplicate_bag ? -- p From hans.bolinder@REDACTED Tue Jun 10 14:05:14 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 10 Jun 2008 14:05:14 +0200 Subject: [erlang-bugs] documentation bug (?) In-Reply-To: References: Message-ID: <18510.28154.252495.521753@gargle.gargle.HOWL> [Paul Mineiro:] > the dets documentation about init_table says: > > "If the type of the table is set and there is more than one object with a > given key, one of the objects is chosen. This is not necessarily the last > object with the given key in the sequence of objects returned by the input > functions. Extra objects should be avoided, or the file will be > unnecessarily fragmented. This holds also for duplicated objects stored in > tables of type duplicate_bag." > > having stared at this for a while, i think it should say: "... holds also > for duplicated objects stored in tables of type bag".[1] > > even clearer would be: "... input functions. Duplicate keys > should be avoided, or the file will be unnecessarily fragmented. This > holds also for duplicated objects stored in tables of type bag." > i found a similar problem in the ets documentation. [...] Thanks! We will make the corrections in R12B-4. Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From opfer@REDACTED Thu Jun 12 16:24:36 2008 From: opfer@REDACTED (Christian Faulhammer) Date: Thu, 12 Jun 2008 16:24:36 +0200 Subject: [erlang-bugs] Build failure with glibc 2.8 (incl. proposed patch) Message-ID: <20080612162436.32e13179@gentoo.org> Hi, I forward this for a user who reported the problem on the Gentoo bug tracker: http://bugs.gentoo.org/show_bug.cgi?id=226063 -------- Original Message -------- Subject: Build failure with glibc 2.8 (incl. proposed patch) Date: Thu, 12 Jun 2008 15:53:52 +0200 From: Holger Hoffstaette Organization: The Fists of the White Lotus Newsgroups: gmane.comp.lang.erlang.patches Hi! Apologies if this shows up twice, but the bugs list apparently does not like me. :( I wrote: Trying to build 12B3 on Gentoo. Glad to see that Christian Faulhammer's patch for ssl and --as-needed was incorporated and works, but now something new came up when building with libtool 2.2.4 and glibc-2.8 (2.8_p20080602), either of which may be the culprit though I suspect glibc. This will likely affect Fedora too, which has the same glibc. This compilation warning: i686-pc-linux-gnu-gcc -pipe -march=pentium4 -mfpmath=sse -O3 -fomit-frame-pointer -I/var/tmp/portage/dev-lang/erlang-12.2.3/work/otp_src_R1 2B-3/erts/i686-pc-linux-gnu -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -DERTS_SMP -DHAVE_CONFIG_H -Wall -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -DUSE_THREADS -D_THREAD_SAFE -D_REENTRANT -D_POSIX_THREAD_SAFE_FUNCTIONS -Ibeam -Isys/un ix -Isys/common -Ii686-pc-linux-gnu/opt/smp -Ii686-pc-linux-gnu -Izlib -Ipcre -Ihipe -I../include/internal -I../include/internal/i686-pc-linux-gnu -c hipe/hipe_x86_signal.c -o obj/i686-pc-linux-gnu/opt/smp/hipe_x86_signal.o hipe/hipe_x86_signal.c: In function 'my_sigaction': hipe/hipe_x86_signal.c:221: warning: implicit declaration of function 'INIT' hipe/hipe_x86_signal.c:231: warning: implicit declaration of function '__next_sigaction' ..then of course fails at link time: i686-pc-linux-gnu-gcc -o /var/tmp/portage/dev-lang/erlang-12.2.3/work/otp_src_R12B-3/bin/i686-pc-linux-gnu/beam.smp \ -Wl,-O1,--as-needed,-z,now -Wl,-export-dynamic obj/i686-pc-linux-gnu/opt/smp/erl_main.o obj/i686-pc-linux-gnu/opt/smp/preload.o obj/i686-pc-linux-gnu/opt/smp/erl_pbifs.o obj/i686-pc-linux-gnu/opt/smp/benchmark.o obj/i686-pc-linux-gnu/opt/smp/erl_alloc.o obj/i686-pc-linux-gnu/opt/smp/erl_mtrace.o obj/i686-pc-linux-gnu/opt/smp/erl_alloc_util.o obj/i686-pc-linux-gnu/opt/smp/erl_goodfit_alloc.o obj/i686-pc-linux-gnu/opt/smp/erl_bestfit_alloc.o obj/i686-pc-linux-gnu/opt/smp/erl_afit_alloc.o obj/i686-pc-linux-gnu/opt/smp/erl_instrument.o obj/i686-pc-linux-gnu/opt/smp/erl_init.o obj/i686-pc-linux-gnu/opt/smp/erl_atom_table.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_table.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_ddll.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_guard.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_info.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_op.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_os.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_lists.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_trace.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_wrap.o obj/i686-pc-linux-gnu/opt/smp/erl_trace.o obj/i686-pc-linux-gnu/opt/smp/copy.o obj/i686-pc-linux-gnu/opt/smp/utils.o obj/i686-pc-linux-gnu/opt/smp/bif.o obj/i686-pc-linux-gnu/opt/smp/io.o obj/i686-pc-linux-gnu/opt/smp/erl_printf_term.o obj/i686-pc-linux-gnu/opt/smp/erl_debug.o obj/i686-pc-linux-gnu/opt/smp/erl_md5.o obj/i686-pc-linux-gnu/opt/smp/erl_message.o obj/i686-pc-linux-gnu/opt/smp/erl_process.o obj/i686-pc-linux-gnu/opt/smp/erl_process_dict.o obj/i686-pc-linux-gnu/opt/smp/erl_process_lock.o obj/i686-pc-linux-gnu/opt/smp/erl_port_task.o obj/i686-pc-linux-gnu/opt/smp/erl_arith.o obj/i686-pc-linux-gnu/opt/smp/time.o obj/i686-pc-linux-gnu/opt/smp/erl_time_sup.o obj/i686-pc-linux-gnu/opt/smp/external.o obj/i686-pc-linux-gnu/opt/smp/dist.o obj/i686-pc-linux-gnu/opt/smp/binary.o obj/i686-pc-linux-gnu/opt/smp/erl_db.o obj/i686-pc-linux-gnu/opt/smp/erl_db_util.o obj/i686-pc-linux-gnu/opt/smp/erl_db_hash.o obj/i686-pc-linux-gnu/opt/smp/erl_db_tree.o obj/i686-pc-linux-gnu/opt/smp/fix_alloc.o obj/i686-pc-linux-gnu/opt/smp/big.o obj/i686-pc-linux-gnu/opt/smp/hash.o obj/i686-pc-linux-gnu/opt/smp/index.o obj/i686-pc-linux-gnu/opt/smp/atom.o obj/i686-pc-linux-gnu/opt/smp/module.o obj/i686-pc-linux-gnu/opt/smp/export.o obj/i686-pc-linux-gnu/opt/smp/register.o obj/i686-pc-linux-gnu/opt/smp/break.o obj/i686-pc-linux-gnu/opt/smp/erl_async.o obj/i686-pc-linux-gnu/opt/smp/erl_lock_check.o obj/i686-pc-linux-gnu/opt/smp/erl_gc.o obj/i686-pc-linux-gnu/opt/smp/erl_nmgc.o obj/i686-pc-linux-gnu/opt/smp/erl_posix_str.o obj/i686-pc-linux-gnu/opt/smp/erl_bits.o obj/i686-pc-linux-gnu/opt/smp/erl_math.o obj/i686-pc-linux-gnu/opt/smp/erl_fun.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_port.o obj/i686-pc-linux-gnu/opt/smp/erl_term.o obj/i686-pc-linux-gnu/opt/smp/erl_node_tables.o obj/i686-pc-linux-gnu/opt/smp/erl_monitors.o obj/i686-pc-linux-gnu/opt/smp/erl_process_dump.o obj/i686-pc-linux-gnu/opt/smp/erl_obsolete.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_timer.o obj/i686-pc-linux-gnu/opt/smp/erl_drv_thread.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_chksum.o obj/i686-pc-linux-gnu/opt/smp/erl_bif_re.o obj/i686-pc-linux-gnu/opt/smp/beam_emu.o obj/i686-pc-linux-gnu/opt/smp/beam_opcodes.o obj/i686-pc-linux-gnu/opt/smp/beam_load.o obj/i686-pc-linux-gnu/opt/smp/beam_bif_load.o obj/i686-pc-linux-gnu/opt/smp/beam_debug.o obj/i686-pc-linux-gnu/opt/smp/beam_bp.o obj/i686-pc-linux-gnu/opt/smp/beam_catches.o obj/i686-pc-linux-gnu/opt/smp/sys.o obj/i686-pc-linux-gnu/opt/smp/driver_tab.o obj/i686-pc-linux-gnu/opt/smp/unix_efile.o obj/i686-pc-linux-gnu/opt/smp/gzio.o obj/i686-pc-linux-gnu/opt/smp/elib_malloc.o obj/i686-pc-linux-gnu/opt/smp/elib_memmove.o obj/i686-pc-linux-gnu/opt/smp/sys_float.o obj/i686-pc-linux-gnu/opt/smp/sys_time.o obj/i686-pc-linux-gnu/opt/smp/erl_poll.kp.o obj/i686-pc-linux-gnu/opt/smp/erl_check_io.kp.o obj/i686-pc-linux-gnu/opt/smp/erl_poll.nkp.o obj/i686-pc-linux-gnu/opt/smp/erl_check_io.nkp.o obj/i686-pc-linux-gnu/opt/smp/erl_mseg.o obj/i686-pc-linux-gnu/opt/smp/erl_unix_sys_ddll.o obj/i686-pc-linux-gnu/opt/smp/erl_mtrace_sys_wrap.o obj/i686-pc-linux-gnu/opt/smp/hipe_bif0.o obj/i686-pc-linux-gnu/opt/smp/hipe_bif1.o obj/i686-pc-linux-gnu/opt/smp/hipe_bif2.o obj/i686-pc-linux-gnu/opt/smp/hipe_debug.o obj/i686-pc-linux-gnu/opt/smp/hipe_gc.o obj/i686-pc-linux-gnu/opt/smp/hipe_mode_switch.o obj/i686-pc-linux-gnu/opt/smp/hipe_native_bif.o obj/i686-pc-linux-gnu/opt/smp/hipe_stack.o obj/i686-pc-linux-gnu/opt/smp/hipe_x86.o obj/i686-pc-linux-gnu/opt/smp/hipe_x86_glue.o obj/i686-pc-linux-gnu/opt/smp/hipe_x86_bifs.o obj/i686-pc-linux-gnu/opt/smp/hipe_x86_signal.o obj/i686-pc-linux-gnu/opt/smp/hipe_x86_stack.o obj/i686-pc-linux-gnu/opt/smp/efile_drv.o obj/i686-pc-linux-gnu/opt/smp/inet_drv.o obj/i686-pc-linux-gnu/opt/smp/zlib_drv.o obj/i686-pc-linux-gnu/opt/smp/ram_file_drv.o obj/i686-pc-linux-gnu/opt/smp/ttsl_drv.o -lutil -ldl -lm -lncurses -L../lib/internal/i686-pc-linux-gnu /var/tmp/portage/dev-lang/erlang-12.2.3/work/otp_src_R12B-3/erts/obj/i686-pc-linux-gnu/libz.a /var/tmp/portage/dev-lang/erlang-12.2.3/work/otp_src_R12B-3/erts/emulator/obj/i686-pc-linux-gnu/opt/libepcre.a -lethread -lpthread -lerts_internal_r -lrt obj/i686-pc-linux-gnu/opt/smp/hipe_x86_signal.o: In function `sigaction': hipe_x86_signal.c:(.text+0xa9): undefined reference to `INIT' hipe_x86_signal.c:(.text+0xff): undefined reference to `__next_sigaction' obj/i686-pc-linux-gnu/opt/smp/hipe_x86_signal.o: In function `hipe_signal_init': hipe_x86_signal.c:(.text+0x118): undefined reference to `INIT' hipe_x86_signal.c:(.text+0x148): undefined reference to `INIT' hipe_x86_signal.c:(.text+0x163): undefined reference to `__next_sigaction' hipe_x86_signal.c:(.text+0x190): undefined reference to `INIT' hipe_x86_signal.c:(.text+0x1d9): undefined reference to `__next_sigaction' collect2: ld returned 1 exit status From a quick look at the source of hipe_x86_signal.c it seems that the glibc version checks miss defining/overriding the correct INIT and __sigaction. Suggestions? If someone tells me what to try I will be happy to produce a patch. :) --snip-- I verified that this also happens with R12-2, so it is not a new bug. After analyzing the #ifdef zoo a bit more I tried to simply bump the glibc version check from 2.7 to 2.8, and lo! it builds & works. Patch: ---------------------------- patch ----------------------------- --- erts/emulator/hipe/hipe_x86_signal.c 2008-06-12 14:17:48.831373565 +0200 +++ erts/emulator/hipe/hipe_x86_signal_ok.c 2008-06-12 14:43:05.132064804 +0200 @@ -34,7 +34,7 @@ #endif #include "hipe_signal.h" -#if __GLIBC__ == 2 && (__GLIBC_MINOR__ >= 3 && __GLIBC_MINOR__ <= 7) +#if __GLIBC__ == 2 && (__GLIBC_MINOR__ >= 3 && __GLIBC_MINOR__ <= 8) /* See comment below for glibc 2.2. */ #ifndef __USE_GNU #define __USE_GNU /* to un-hide RTLD_NEXT */ ---------------------------- patch ----------------------------- I'm not too happy with the hardcoded version as this will probably happen again with glibc 2.9, but for now this does the trick. Holger -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From jdoran@REDACTED Thu Jun 12 19:43:31 2008 From: jdoran@REDACTED (Jeff Doran) Date: Thu, 12 Jun 2008 10:43:31 -0700 Subject: [erlang-bugs] Misleading ./configure error on Linux Message-ID: When trying to build otp_src_R12B-2 on a Centos Linux box I encountered an error during ./configure complaining about missing 'ncurses'. I had the ncurses.i386 libraries installed and was confused by this message. It turns out that the ncurses development libraries are also required. My problem was solved by installing ncurses-devel.i386. It would save a lot of time and frustration for users to mention that the development libraries are also required along with the normal shared libraries. This could either be a more informative error message from ./configure or some info added to the README file when listing dependencies. Thanks. - Jeff From mikpe@REDACTED Fri Jun 13 12:40:26 2008 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 13 Jun 2008 12:40:26 +0200 Subject: [erlang-bugs] Build failure with glibc 2.8 (incl. proposed patch) In-Reply-To: <20080612162436.32e13179@gentoo.org> References: <20080612162436.32e13179@gentoo.org> Message-ID: <18514.20122.725362.108330@harpo.it.uu.se> Christian Faulhammer writes: > Hi, > > I forward this for a user who reported the problem on the Gentoo bug > tracker: http://bugs.gentoo.org/show_bug.cgi?id=226063 > > > -------- Original Message -------- > Subject: Build failure with glibc 2.8 (incl. proposed patch) > Date: Thu, 12 Jun 2008 15:53:52 +0200 > From: Holger Hoffstaette > Organization: The Fists of the White Lotus > Newsgroups: gmane.comp.lang.erlang.patches > > Hi! > > Apologies if this shows up twice, but the bugs list apparently does not > like me. :( > > I wrote: > > Trying to build 12B3 on Gentoo. Glad to see that Christian Faulhammer's > patch for ssl and --as-needed was incorporated and works, but > now something new came up when building with libtool 2.2.4 and glibc-2.8 > (2.8_p20080602), either of which may be the culprit though I suspect > glibc. This will likely affect Fedora too, which has the same glibc. ... > obj/i686-pc-linux-gnu/opt/smp/hipe_x86_signal.o: In function > `sigaction': hipe_x86_signal.c:(.text+0xa9): undefined reference to > `INIT' hipe_x86_signal.c:(.text+0xff): undefined reference to > `__next_sigaction' obj/i686-pc-linux-gnu/opt/smp/hipe_x86_signal.o: In > function `hipe_signal_init': > hipe_x86_signal.c:(.text+0x118): undefined reference to `INIT' > hipe_x86_signal.c:(.text+0x148): undefined reference to `INIT' > hipe_x86_signal.c:(.text+0x163): undefined reference to > `__next_sigaction' hipe_x86_signal.c:(.text+0x190): undefined reference > to `INIT' hipe_x86_signal.c:(.text+0x1d9): undefined reference to > `__next_sigaction' collect2: ld returned 1 exit status > > From a quick look at the source of hipe_x86_signal.c it seems > that the glibc version checks miss defining/overriding the correct INIT > and __sigaction. Suggestions? If someone tells me what to try I will be > happy to produce a patch. :) > > --snip-- > > I verified that this also happens with R12-2, so it is not a new bug. > > After analyzing the #ifdef zoo a bit more I tried to simply bump the > glibc version check from 2.7 to 2.8, and lo! it builds & works. Patch: > > ---------------------------- patch ----------------------------- > > --- erts/emulator/hipe/hipe_x86_signal.c 2008-06-12 > 14:17:48.831373565 +0200 +++ > erts/emulator/hipe/hipe_x86_signal_ok.c 2008-06-12 > 14:43:05.132064804 +0200 @@ -34,7 +34,7 @@ > #endif > #include "hipe_signal.h" > > -#if __GLIBC__ == 2 && (__GLIBC_MINOR__ >= 3 && __GLIBC_MINOR__ <= 7) > +#if __GLIBC__ == 2 && (__GLIBC_MINOR__ >= 3 && __GLIBC_MINOR__ <= 8) > /* See comment below for glibc 2.2. */ > #ifndef __USE_GNU > #define __USE_GNU /* to un-hide RTLD_NEXT */ > > ---------------------------- patch ----------------------------- > > I'm not too happy with the hardcoded version as this will probably > happen again with glibc 2.9, but for now this does the trick. It's not a bug, it's a deliberate version check to prevent building against unverified glibc versions. In the past, running the wrong code on early glibc versions could result in obscure runtime failures. However, since glibc-2.3 there have been no relevant changes in this area, and now the version check while correct causes more problems than it solves. So I'll probably loosen the check to just be ">= 2.3". /Mikael From matt.handler@REDACTED Fri Jun 13 15:55:53 2008 From: matt.handler@REDACTED (Matt Handler) Date: Fri, 13 Jun 2008 09:55:53 -0400 Subject: [erlang-bugs] lists:dropwhile Message-ID: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> dropwhile does not work properly as defined in R12B-2: 01 dropwhile(Pred, [Hd|Tail]=Rest) -> 02 case Pred(Hd) of 03 true -> dropwhile(Pred, Tail); 04 false -> Rest 05 end; 06 dropwhile(Pred, []) when is_function(Pred, 1) -> []. it returns the entire list once it finds an element that doesn't match true. here's what i did instead: dropwhile(Fun, List) -> [Element || Element <- List, Fun(Element) =/= true]. thanks, -matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From bengt.kleberg@REDACTED Fri Jun 13 16:24:56 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Fri, 13 Jun 2008 16:24:56 +0200 Subject: [erlang-bugs] lists:dropwhile In-Reply-To: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> References: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> Message-ID: <1213367096.32317.1.camel@seasc0642.dyn.rnd.as.sw.ericsson.se> Greetings, The documentation of dropwhile/ 2 says: "Drops elements Elem from List1 while Pred(Elem) returns true and returns the remaining list." bengt On Fri, 2008-06-13 at 09:55 -0400, Matt Handler wrote: > dropwhile does not work properly as defined in R12B-2: > > 01 dropwhile(Pred, [Hd|Tail]=Rest) -> > 02 case Pred(Hd) of > 03 true -> dropwhile(Pred, Tail); > 04 false -> Rest > 05 end; > 06 dropwhile(Pred, []) when is_function(Pred, 1) -> []. > > it returns the entire list once it finds an element that doesn't match > true. > > here's what i did instead: > > dropwhile(Fun, List) -> > [Element || > Element <- List, > Fun(Element) =/= true]. > > thanks, > -matt > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From sverker@REDACTED Fri Jun 13 16:27:42 2008 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 13 Jun 2008 16:27:42 +0200 Subject: [erlang-bugs] lists:dropwhile In-Reply-To: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> References: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> Message-ID: <485283DE.9090902@erix.ericsson.se> No, that's the right semantics. Drop elements _while_ Pred returns true and then return the remaining list. That is, return the tail if the list starting with the first one that returns false. Compare with takewhile/2. Maybe the documentation isn't too obvious. /Sverker, Erlang/OTP Ericsson Matt Handler wrote: > dropwhile does not work properly as defined in R12B-2: > > 01 dropwhile(Pred, [Hd|Tail]=Rest) -> > 02 case Pred(Hd) of > 03 true -> dropwhile(Pred, Tail); > 04 false -> Rest > 05 end; > 06 dropwhile(Pred, []) when is_function(Pred, 1) -> []. > > it returns the entire list once it finds an element that doesn't match > true. > > here's what i did instead: > > dropwhile(Fun, List) -> > [Element || > Element <- List, > Fun(Element) =/= true]. > > thanks, > -matt > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From rvirding@REDACTED Fri Jun 13 16:28:04 2008 From: rvirding@REDACTED (Robert Virding) Date: Fri, 13 Jun 2008 16:28:04 +0200 Subject: [erlang-bugs] lists:dropwhile In-Reply-To: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> References: <49427c610806130655x31ba1b1bqa77c059dca777fa4@mail.gmail.com> Message-ID: <3dbc6d1c0806130728u7dd6638cmba777ed7494baee2@mail.gmail.com> It is *supposed* to drop the elements of a list as long as they evaluate the predicate to 'true'. As soon as the predicate evaluates to false then that element and the rest of the list are returned. It is *not* the equivalent of filter/2 with the inverse test. Robert 2008/6/13 Matt Handler : > dropwhile does not work properly as defined in R12B-2: > > 01 dropwhile(Pred, [Hd|Tail]=Rest) -> > 02 case Pred(Hd) of > 03 true -> dropwhile(Pred, Tail); > 04 false -> Rest > 05 end; > 06 dropwhile(Pred, []) when is_function(Pred, 1) -> []. > > it returns the entire list once it finds an element that doesn't match > true. > > here's what i did instead: > > dropwhile(Fun, List) -> > [Element || > Element <- List, > Fun(Element) =/= true]. > > thanks, > -matt > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From opfer@REDACTED Fri Jun 13 21:31:46 2008 From: opfer@REDACTED (Christian Faulhammer) Date: Fri, 13 Jun 2008 21:31:46 +0200 Subject: [erlang-bugs] Build failure with glibc 2.8 (incl. proposed patch) In-Reply-To: <18514.20122.725362.108330@harpo.it.uu.se> References: <20080612162436.32e13179@gentoo.org> <18514.20122.725362.108330@harpo.it.uu.se> Message-ID: <20080613213146.50063a7d@gentoo.org> Hi, Mikael Pettersson : > It's not a bug, it's a deliberate version check to prevent building > against unverified glibc versions. In the past, running the wrong > code on early glibc versions could result in obscure runtime failures. You should really think about a test suite for such runtime thingies. > However, since glibc-2.3 there have been no relevant changes in > this area, and now the version check while correct causes more > problems than it solves. So I'll probably loosen the check to > just be ">= 2.3". Thanks, the patch is used in Gentoo now, too. Along with 12B-3. V-Li -- Christian Faulhammer, Gentoo Lisp project , #gentoo-lisp on FreeNode -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 197 bytes Desc: not available URL: From vlm@REDACTED Sun Jun 15 05:16:56 2008 From: vlm@REDACTED (Lev Walkin) Date: Sat, 14 Jun 2008 20:16:56 -0700 Subject: [erlang-bugs] R11B-5 to R12B-3 forks beams eating 100% CPU Message-ID: <485489A8.50902@lionet.info> SYMPTOMS: A running, unstressed erlang system appears to spontaneously fork off BEAM processes (beam) several times an hour, each eating 100% CPU. (If there are more than one at a time, they split the CPU accordingly). INVESTIGATION: The BEAM processes forked appear to be truly separate processes. Killing them (-9) does not seem to harm the main VM, which continues to execute the necessary set of applications (kernel, stdlib, sasl, ssl, yaws, plus two inhouse ones). Disabling yaws application does not seem to have any effect on the rate of runaway beam creation. ktrace shows a total absence of any system calls in the runaway beam process, suggesting an infinite loop. Killing the process results in a single ktrace event: [root@REDACTED ~]# kdump 97445 beam PSIG SIGKILL SIG_DFL [root@REDACTED ~]# The R12B-3 has the following fix: OTP-7289 On Mac OS 10.5 (Leopard), sending to socket which the other end closes could cause the emulator to consume 100% CPU time. (Thanks to Matthias Radestock.) Since Mac OS is sufficiently similar to FreeBSD, I had hoped the OTP-7289 has direct relation to my runaway beam problem. Alas, R12B-3 behaves exactly the way R11B-5 and the latter versions of Erlang VM behave, that is, runaway beams are continuing to appear on a regular basis. WORKAROUND USED: Created an external process which periodically detects and kills the runaway beams. Ugly. CONFIGURATION: Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] [async-threads:0] [hipe] [kernel-poll:false] FreeBSD host 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:43:02 UTC 2008 root@REDACTED:/usr/obj/usr/src/sys/SMP amd64 However, the system was running all versions of erlang VM between R11B-5 and R12B-3 with the same results, so it is not version specific. Please suggest further steps to debug or eliminate the problem. -- Lev Walkin vlm@REDACTED From raimo+erlang-bugs@REDACTED Mon Jun 16 11:32:05 2008 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 16 Jun 2008 11:32:05 +0200 Subject: [erlang-bugs] Misleading ./configure error on Linux In-Reply-To: References: Message-ID: <20080616093205.GA6499@erix.ericsson.se> On Thu, Jun 12, 2008 at 10:43:31AM -0700, Jeff Doran wrote: > > When trying to build otp_src_R12B-2 on a Centos Linux box I encountered an > error during ./configure complaining about missing 'ncurses'. I had the > ncurses.i386 libraries installed and was confused by this message. > > It turns out that the ncurses development libraries are also required. My > problem was solved by installing ncurses-devel.i386. > > It would save a lot of time and frustration for users to mention that the > development libraries are also required along with the normal shared > libraries. This could either be a more informative error message from > ./configure or some info added to the README file when listing dependencies. OK. We will rephrase it. That particular section is from when there were no -devel versions of ncurses. The -devel packets has come in later years for Linux binary distros, and since it is a compile requirement is has always been obvious (for us) that it is the -devel packet is required. Some requirements has this updated already. But times has changed. It is now called -devel packets, no matter what oldtimers claim... Sigh! > > Thanks. > > > - Jeff > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From mog-lists@REDACTED Mon Jun 16 20:55:15 2008 From: mog-lists@REDACTED (mog) Date: Mon, 16 Jun 2008 13:55:15 -0500 Subject: [erlang-bugs] erlang shell does not have clear functionality Message-ID: <4856B713.6000904@rldn.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ^L does not clear the shell like in most other shells. Provided is a patch that allows for this behavior, there should probably also be a clear command that would be equally easy to write. Mog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVrcReq+tARrxhnsRAuuXAJ0X63Pvi96W2yPcSxO6zldf6oCKbACffTr6 E/b/hYIIQiJr0c7xgazDjbQ= =L+eq -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: ttsl_drv.c Type: text/x-csrc Size: 20197 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: user_drv.erl URL: From mog-lists@REDACTED Mon Jun 16 21:41:51 2008 From: mog-lists@REDACTED (mog) Date: Mon, 16 Jun 2008 14:41:51 -0500 Subject: [erlang-bugs] erlang shell does not have clear functionality In-Reply-To: <4856B713.6000904@rldn.net> References: <4856B713.6000904@rldn.net> Message-ID: <4856C1FF.2040003@rldn.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry for whole files here is a patch. Was a pain to make as there is no version control accessible and have to copy tarballs... Mog -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVsH+eq+tARrxhnsRApr1AJ4/u98HGDG0U/0qnSxFrd9/N3nvVACffB8p QByJjoDtnaLJUZnYOaH4P7s= =jGco -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-r12b3.diff Type: text/x-patch Size: 1939 bytes Desc: not available URL: From pedzsan@REDACTED Mon Jun 16 22:12:39 2008 From: pedzsan@REDACTED (Perry Smith) Date: Mon, 16 Jun 2008 15:12:39 -0500 Subject: [erlang-bugs] fmtq bug by inspection Message-ID: This looks like a bug to me: static char* fmtq(char* ptr, int* buf) { int c; switch((c=*ptr++)) { case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': c = c - '0'; if ((*ptr >= 0) && (*ptr <= 7)) { <<<<< c = (c << 3) | (*ptr - '0'); ptr++; if ((*ptr >= 0) && (*ptr <= 7)) { <<<<< c = (c << 3) | (*ptr - '0'); ptr++; } } break; } *buf = c; return ptr; } Shouldn't it be: case '0': case '1': case '2': case '3': case '4': case '5': case '6': case '7': c = c - '0'; if ((*ptr >= '0') && (*ptr <= '7')) { /* added single quotes */ c = (c << 3) | (*ptr - '0'); ptr++; if ((*ptr >= '0') && (*ptr <= '7')) { /* added single quotes */ c = (c << 3) | (*ptr - '0'); ptr++; } } I found this simply by looking at the compiler warnings. HTH Perry From vlm@REDACTED Tue Jun 17 08:25:17 2008 From: vlm@REDACTED (Lev Walkin) Date: Mon, 16 Jun 2008 23:25:17 -0700 Subject: [erlang-bugs] R11B-5 to R12B-3 forks beams eating 100% CPU In-Reply-To: <485489A8.50902@lionet.info> References: <485489A8.50902@lionet.info> Message-ID: <485758CD.2020801@lionet.info> correction: Disabling yaws application DOES seem to have effect on the rate of runaway beam creation. Lev Walkin wrote: > SYMPTOMS: > > A running, unstressed erlang system appears to spontaneously > fork off BEAM processes (beam) several times an hour, > each eating 100% CPU. (If there are more than one at a time, > they split the CPU accordingly). > > INVESTIGATION: > > The BEAM processes forked appear to be truly separate processes. > Killing them (-9) does not seem to harm the main VM, which > continues to execute the necessary set of applications > (kernel, stdlib, sasl, ssl, yaws, plus two inhouse ones). > > Disabling yaws application does not seem to have any effect on > the rate of runaway beam creation. > > ktrace shows a total absence of any system calls in the runaway > beam process, suggesting an infinite loop. Killing the process > results in a single ktrace event: > > [root@REDACTED ~]# kdump > 97445 beam PSIG SIGKILL SIG_DFL > [root@REDACTED ~]# > > The R12B-3 has the following fix: > > > OTP-7289 On Mac OS 10.5 (Leopard), sending to socket > which the other end closes could cause the > emulator to consume 100% CPU time. > (Thanks to Matthias Radestock.) > > Since Mac OS is sufficiently similar to FreeBSD, I had hoped > the OTP-7289 has direct relation to my runaway beam problem. > Alas, R12B-3 behaves exactly the way R11B-5 and the latter > versions of Erlang VM behave, that is, runaway beams > are continuing to appear on a regular basis. > > WORKAROUND USED: > > Created an external process which periodically detects > and kills the runaway beams. Ugly. > > CONFIGURATION: > > Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] > [async-threads:0] [hipe] [kernel-poll:false] > > FreeBSD host 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:43:02 > UTC 2008 root@REDACTED:/usr/obj/usr/src/sys/SMP amd64 > > However, the system was running all versions of erlang VM > between R11B-5 and R12B-3 with the same results, so > it is not version specific. > > > Please suggest further steps to debug or eliminate the problem. > > From vlm@REDACTED Tue Jun 17 12:57:06 2008 From: vlm@REDACTED (Lev Walkin) Date: Tue, 17 Jun 2008 03:57:06 -0700 Subject: [erlang-bugs] R11B-5 to R12B-3 forks beams eating 100% CPU In-Reply-To: <485758CD.2020801@lionet.info> References: <485489A8.50902@lionet.info> <485758CD.2020801@lionet.info> Message-ID: <48579882.9010304@lionet.info> Update: after all, it seems that yaws:call_cgi() is a culprit. It invokes the beam's fork(), which interacts badly with underlying threading library: 0x0000000800b8b8ca in pthread_sigmask () from /lib/libpthread.so.2 (gdb) bt #0 0x0000000800b8b8ca in pthread_sigmask () from /lib/libpthread.so.2 #1 0x0000000800b8b876 in sigprocmask () from /lib/libpthread.so.2 #2 0x0000000800b95809 in pthread_mutexattr_init () from /lib/libpthread.so.2 #3 0x0000000800b8883a in fork () from /lib/libpthread.so.2 #4 0x000000000052eea6 in fini_getenv_state () #5 0x0000000000482a1a in erts_open_driver () #6 0x00000000004f0e7d in port_get_data_1 () #7 0x00000000004eef88 in open_port_2 () #8 0x0000000000508e9c in process_main () #9 0x0000000000445701 in erl_start () #10 0x000000000042b39b in main () (gdb) c Continuing. no thread to satisfy query 0x0000000800b8b8ca in pthread_sigmask () from /lib/libpthread.so.2 It turned out that FreeBSD port adds --enable-threads to the erts configuration option. I tried two things: 1. Disabled threading in run time, by specifying +A 0 (my default was +A 32). This setting has no effect on the rating of runaway beams' creation. That is, new beams still sporadically pop out eating 100% CPU. 2. Disabling threading by removing the --enable-threads from the Erlang port's configuration. This appears to fix the issue. I firmly believe there should exist a more legitimate fix. Is there anyone willing to perform a consultant's job of fixing this hanging fork() issue under async-threading/FreeBSD/call_cgi, and receive money in exchange for their services? Lev Walkin wrote: > correction: > > Disabling yaws application DOES seem to have effect on > the rate of runaway beam creation. > > > Lev Walkin wrote: >> SYMPTOMS: >> >> A running, unstressed erlang system appears to spontaneously >> fork off BEAM processes (beam) several times an hour, >> each eating 100% CPU. (If there are more than one at a time, >> they split the CPU accordingly). >> >> INVESTIGATION: >> >> The BEAM processes forked appear to be truly separate processes. >> Killing them (-9) does not seem to harm the main VM, which >> continues to execute the necessary set of applications >> (kernel, stdlib, sasl, ssl, yaws, plus two inhouse ones). >> >> Disabling yaws application does not seem to have any effect on >> the rate of runaway beam creation. >> >> ktrace shows a total absence of any system calls in the runaway >> beam process, suggesting an infinite loop. Killing the process >> results in a single ktrace event: >> >> [root@REDACTED ~]# kdump >> 97445 beam PSIG SIGKILL SIG_DFL >> [root@REDACTED ~]# >> >> The R12B-3 has the following fix: >> >> >> OTP-7289 On Mac OS 10.5 (Leopard), sending to socket >> which the other end closes could cause the >> emulator to consume 100% CPU time. >> (Thanks to Matthias Radestock.) >> >> Since Mac OS is sufficiently similar to FreeBSD, I had hoped >> the OTP-7289 has direct relation to my runaway beam problem. >> Alas, R12B-3 behaves exactly the way R11B-5 and the latter >> versions of Erlang VM behave, that is, runaway beams >> are continuing to appear on a regular basis. >> >> WORKAROUND USED: >> >> Created an external process which periodically detects >> and kills the runaway beams. Ugly. >> >> CONFIGURATION: >> >> Erlang (BEAM) emulator version 5.6.3 [source] [64-bit] >> [async-threads:0] [hipe] [kernel-poll:false] >> >> FreeBSD host 6.3-RELEASE FreeBSD 6.3-RELEASE #0: Wed Jan 16 01:43:02 >> UTC 2008 root@REDACTED:/usr/obj/usr/src/sys/SMP amd64 >> >> However, the system was running all versions of erlang VM >> between R11B-5 and R12B-3 with the same results, so >> it is not version specific. >> >> >> Please suggest further steps to debug or eliminate the problem. >> >> > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From erlang-questions_efine@REDACTED Tue Jun 17 15:00:01 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Tue, 17 Jun 2008 09:00:01 -0400 Subject: [erlang-bugs] fmtq bug by inspection In-Reply-To: References: Message-ID: <6c2563b20806170600s6a334f38xfb0ddd6e9d35034f@mail.gmail.com> I think you are right, because the following line *requires* that *ptr be between '0' and '7'. It appears that this code is packing an octal representation of an ASCII digit into 3 bits. c = (c << 3) | (*ptr - '0'); On Mon, Jun 16, 2008 at 4:12 PM, Perry Smith wrote: > This looks like a bug to me: > > static char* fmtq(char* ptr, int* buf) > { > int c; > > switch((c=*ptr++)) { > > case '0': case '1': case '2': case '3': case '4': > case '5': case '6': case '7': > c = c - '0'; > if ((*ptr >= 0) && (*ptr <= 7)) { <<<<< > c = (c << 3) | (*ptr - '0'); > ptr++; > if ((*ptr >= 0) && (*ptr <= 7)) { <<<<< > c = (c << 3) | (*ptr - '0'); > ptr++; > } > } > break; > } > *buf = c; > return ptr; > } > > Shouldn't it be: > > case '0': case '1': case '2': case '3': case '4': > case '5': case '6': case '7': > c = c - '0'; > if ((*ptr >= '0') && (*ptr <= '7')) { /* added single quotes */ > c = (c << 3) | (*ptr - '0'); > ptr++; > if ((*ptr >= '0') && (*ptr <= '7')) { /* added single quotes */ > c = (c << 3) | (*ptr - '0'); > ptr++; > } > } > > I found this simply by looking at the compiler warnings. > > HTH > Perry > > _______________________________________________ > 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 Wed Jun 18 15:52:37 2008 From: rickard.s.green@REDACTED (Rickard Green) Date: Wed, 18 Jun 2008 15:52:37 +0200 Subject: [erlang-bugs] fmtq bug by inspection In-Reply-To: References: Message-ID: <48591325.5060100@ericsson.com> Hi Perry, Thanks for the bug report. I looked a little closer at it, and it turns out that the use of fmtq() should be removed. erts_printf will currently produce erroneous results when double backslashes are used in format strings. I wasn't able to find any format strings like that being passed to erts_printf in the emulator, i.e., the bug is currently completely harmless. The bug will be fixed in R12B-4, though. BR, Rickard, Erlang/OTP, Ericsson AB. Perry Smith wrote: > This looks like a bug to me: > > static char* fmtq(char* ptr, int* buf) > { > int c; > > switch((c=*ptr++)) { > > case '0': case '1': case '2': case '3': case '4': > case '5': case '6': case '7': > c = c - '0'; > if ((*ptr >= 0) && (*ptr <= 7)) { <<<<< > c = (c << 3) | (*ptr - '0'); > ptr++; > if ((*ptr >= 0) && (*ptr <= 7)) { <<<<< > c = (c << 3) | (*ptr - '0'); > ptr++; > } > } > break; > } > *buf = c; > return ptr; > } > > Shouldn't it be: > > case '0': case '1': case '2': case '3': case '4': > case '5': case '6': case '7': > c = c - '0'; > if ((*ptr >= '0') && (*ptr <= '7')) { /* added single quotes */ > c = (c << 3) | (*ptr - '0'); > ptr++; > if ((*ptr >= '0') && (*ptr <= '7')) { /* added single quotes */ > c = (c << 3) | (*ptr - '0'); > ptr++; > } > } > > I found this simply by looking at the compiler warnings. > > HTH > Perry > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From mog-lists@REDACTED Thu Jun 19 00:45:33 2008 From: mog-lists@REDACTED (mog) Date: Wed, 18 Jun 2008 17:45:33 -0500 Subject: [erlang-bugs] Pretty print and clear in the shell Message-ID: <4859900D.8030609@rldn.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all I thought it would be cool to have color printing like 1> io:format("\033[31m Hello \033[0m~n"). Hello ok (that would be in color if this wasn't plain text ^_^. However this is currently escaped over the shell and ssh. Also included in this patch is clear support for the shell. typing ^L clears the screen as does io:clear() or l(). Hope this helps Mog PS sorry for cross post. I was just hoping for more feedback. Now to go implement .erlang-history.... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIWZALeq+tARrxhnsRAvzLAJ4kxKuD/h78r1J7gS/LAs3i2xKmNwCgpayR xoPDYQzYWizmjvBlqDfKy0g= =YHY/ -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: print-clear.diff Type: text/x-patch Size: 6879 bytes Desc: not available URL: From anders.nygren@REDACTED Sun Jun 22 18:06:29 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Sun, 22 Jun 2008 11:06:29 -0500 Subject: [erlang-bugs] common_test.app missing Message-ID: Hi In R12B-2 and R12B-3 there is no .app file for common_test. Is that an error or is there some deeper reason for this? /Anders From anders.nygren@REDACTED Tue Jun 24 00:52:31 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Mon, 23 Jun 2008 17:52:31 -0500 Subject: [erlang-bugs] inets bad info message Message-ID: Hi When giving a bad HTTPOption in http:request I get this info message. I assume that I was supposed to be formatted differently. == 2008-06-23 17:04:43 === INFO =========================== <0.239.0> == {"Invalid option ignored ~p~n",[{http_timeout,20000}]} /Anders From bjorn@REDACTED Tue Jun 24 12:21:07 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 24 Jun 2008 12:21:07 +0200 Subject: [erlang-bugs] common_test.app missing In-Reply-To: References: Message-ID: "Anders Nygren" writes: > Hi > In R12B-2 and R12B-3 there is no .app file for common_test. > Is that an error or is there some deeper reason for this? .app files are needed if you want to use the release handler to include an application in an embedded system. We assumed that no-one would want to include common_test in an embedded system. If there is a good reason to include an .app file that we haven't thought of, we will of course include an .app file in R12B-4. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From anders.nygren@REDACTED Thu Jun 26 20:21:34 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Thu, 26 Jun 2008 13:21:34 -0500 Subject: [erlang-bugs] ASN.1 documentation bug Message-ID: Hi In the ASN.1 documentation it says about .set.asn files "The input files' names must be listed, within qoutation marks (""), one at each row in the file. If the input files are File1.asn, File2.asn and File3.asn the configuration file shall look like: File1.asn File2.asn File3.asn " Note that the filenames in the example are NOT quoted. /Anders From mj@REDACTED Fri Jun 27 14:57:26 2008 From: mj@REDACTED (Mikkel Jensen) Date: Fri, 27 Jun 2008 14:57:26 +0200 Subject: [erlang-bugs] Bug in xmerl Message-ID: It seems there is a bug in xmerl when loading elements that contain numeric character references followed by UTF-8 characters. Example: ? newline ? 1> element(1, xmerl_scan:string("\303\251 \303\251", [{encoding, 'utf-8'}])). {xmlElement,a,a,[], {xmlNamespace,[],[]}, [],1,[], [{xmlText,[{a,1}],1,[],"\303\251",text}, {xmlText,[{a,1}],2,[],[10,195,131,194,169],text}], [],"/",undeclared} Xmerl splits the parsed value around the newline character (strange but ok). However, the first part is encoded correctly while the second part is garbled! It's worth noticing that attribute values are encoded correctly: 2> element(1, xmerl_scan:string("", [{encoding, 'utf-8'}])). {xmlElement,a,a,[], {xmlNamespace,[],[]}, [],1, [{xmlAttribute,b,[],[],[],[],1,[],"\303\251 \303\251",false}], [],[],"/",undeclared} - Mikkel -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.nygren@REDACTED Fri Jun 27 19:09:28 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Fri, 27 Jun 2008 12:09:28 -0500 Subject: [erlang-bugs] ic documentation bug? Message-ID: In the ic reference man about the backend options. Any chance that this c_genserv Deprecated. Use c_client instead. should be c_genserv Deprecated. Use c_server instead. /Anders From saleyn@REDACTED Sat Jun 28 02:00:05 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Fri, 27 Jun 2008 20:00:05 -0400 Subject: [erlang-bugs] [erlang-questions] SNMP MIB compiler fix for R12B-2 Message-ID: <48657F05.1050101@gmail.com> The MIB compiler doesn't properly handle the REFERENCE part of a MIB definition. Judging by the implementation of the grammar it was intended to be supported but not fully implemented. Attached is a fix that's backward compatible. Passing a new option 'reference' | {reference, Boolean} to the compiler will enable the feature. Regards, Serge -------------- next part -------------- A non-text attachment was scrubbed... Name: snmpc.R12B-2.patch Type: application/octet-stream Size: 5387 bytes Desc: not available URL: From nick@REDACTED Mon Jun 30 11:08:13 2008 From: nick@REDACTED (Niclas Eklund) Date: Mon, 30 Jun 2008 11:08:13 +0200 (CEST) Subject: [erlang-bugs] ic documentation bug? In-Reply-To: References: Message-ID: Hello! The documentation actually is correct. I understand that it might be confusing, and probably the reason why c_genserv was deprecated a long time ago. Perhaps it's time to remove that option next time a new IC version will be released. Best regards, Niclas, Erlang/OTP On Fri, 27 Jun 2008, Anders Nygren wrote: > In the ic reference man about the backend options. Any chance > that this > > c_genserv > Deprecated. Use c_client instead. > > should be > > c_genserv > Deprecated. Use c_server instead. > > > /Anders > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From erlang-questions_efine@REDACTED Mon Jun 30 23:56:58 2008 From: erlang-questions_efine@REDACTED (Edwin Fine) Date: Mon, 30 Jun 2008 17:56:58 -0400 Subject: [erlang-bugs] Incorrect or misleading inets/http_server error message Message-ID: <6c2563b20806301456j5276f073q522ddb29470e2474@mail.gmail.com> Taking the example out of the document at http://www.erlang.org/doc/apps/inets/http_server.html: 2> {ok, Pid} = inets:start(httpd, [{port, 0}, 2> {server_name,"httpd_test"}, {server_root,"/tmp"}, 2> {document_root,"/tmp/htdocs"}, {bind_address, "localhost"}]). =ERROR REPORT==== 30-Jun-2008::17:47:18 === Failed initiating web server: undefined *{wrong_type,{document_root,"/tmp/htdocs"}}* ** exception error: no match of right hand side value {error,{shutdown,{child,undefined, {httpd_instance_sup,{0,0,0,0,0,0,0,1},59104}, {httpd_instance_sup,start_link, [[{port,59104}, {bind_address,{0,0,0,0,0,0,0,1}}, {server_name,"httpd_test"}, {server_root,"/tmp"}, {document_root,"/tmp/htdocs"}], 15000, {<0.50.0>,#Port<0.126>}, []]}, permanent,infinity,supervisor, [httpd_instance_sup]}}} The actual problem was that the "/tmp/htdocs" directory did not exist. I find having an error message of undefined *{wrong_type,{document_root,"/tmp/htdocs"}} *to be very misleading. I read it as "the value corresponding to document_root [i.e. "/tmp/htdocs", of type string] is of the wrong type". If not a string, what should it be, I wondered? When I created the directory and tried again, the message went away. I would have expected to see something like {does_not_exist,{document_root,"/tmp/htdocs"}}. 3> {ok, Pid} = inets:start(httpd, [{port, 0}, 3> {server_name,"httpd_test"}, {server_root,"/tmp"}, 3> {document_root,"/tmp/htdocs"}, {bind_address, "localhost"}]). {ok,<0.58.0>} 4> Regards, Edwin Fine -- The great enemy of the truth is very often not the lie -- deliberate, contrived and dishonest, but the myth, persistent, persuasive, and unrealistic. Belief in myths allows the comfort of opinion without the discomfort of thought. John F. Kennedy 35th president of US 1961-1963 (1917 - 1963) -------------- next part -------------- An HTML attachment was scrubbed... URL: