From mattevans123@REDACTED Fri Jun 3 19:24:12 2016 From: mattevans123@REDACTED (Matthew Evans) Date: Fri, 3 Jun 2016 13:24:12 -0400 Subject: [erlang-bugs] [erlang-questions] beam core file R17 In-Reply-To: References: , , <22347.4371.901213.18449@gargle.gargle.HOWL>, , , , , Message-ID: For what it's worth here's a gdb with symbols: (gdb) bt #0 sweep_off_heap (p=0x7faeb8fc5488, fullsweep=-1295963664) at beam/erl_gc.c:2353 #1 0x00000000004b77d1 in do_minor (p=0x7faeb8fc5488, new_sz=, objv=, nobj=) at beam/erl_gc.c:1166 #2 0x00000000004b8479 in minor_collection (recl=, nobj=, objv=, need=, p=) at beam/erl_gc.c:876 #3 erts_garbage_collect (p=0x7faeb8fc5488, need=, objv=, nobj=) at beam/erl_gc.c:450 #4 0x00000000004e1374 in process_main () at beam/beam_emu.c:1858 #5 0x000000000048071d in sched_thread_func (vesdp=) at beam/erl_process.c:7719 #6 0x0000000000549f89 in thr_wrapper (vtwd=) at pthread/ethread.c:106 #7 0x00007faeba32ba30 in ?? () #8 0x0000000000000000 in ?? () From: mattevans123@REDACTED To: garazdawi@REDACTED Date: Sun, 29 May 2016 21:32:58 -0400 CC: erlang-questions@REDACTED; erlang-bugs@REDACTED Subject: Re: [erlang-questions] [erlang-bugs] beam core file R17 Thanks, Fortunately our latest release has moved all the NIF logic to a separate CNODE based process. I am leaning towards the NIF as the cause since the VM itself has proven to be very stable. Date: Sun, 29 May 2016 21:23:15 +0200 Subject: Re: [erlang-bugs] beam core file R17 From: garazdawi@REDACTED To: mattevans123@REDACTED CC: erlang-questions@REDACTED sweep_off_heap is run when collecting refc binaries (among other things), so if you by mistake have decremented the reference count of a binary in a nif too much, this error will happen when the GC is inspecting the binary. I'd recommend looking for something like that in any nifs you have. On Sun, May 29, 2016 at 6:04 PM, Matthew Evans wrote: Thanks, this software does use nifs Sent from my iPhone > On May 29, 2016, at 11:56 AM, Mikael Pettersson wrote: > > Matthew Evans writes: >> Hi, >> This core was found on a live system (R17): >> >> >> >> >> >> >> >> >> 10:16:38:# erl >> Erlang/OTP 17 [erts-6.2] [source] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false] >> >> >> Eshell V6.2 (abort with ^G) >> 1> >> >> ........ >> >> >> >> >> >> >> >> >> May 28 22:18:56 [info ] plexxi kernel: [1235119.885465] beam.smp[2267] general protection ip:4b698a sp:7faeb6a7d650 error:0 in beam.smp[400000+1ac000] >> warning: Can't read pathname for load map: Input/output error.[Thread debugging using libthread_db enabled]Using host libthread_db library "/lib/libthread_db.so.1".Core was generated by `/usr/lib/erlang/erts-6.2/bin/beam.smp -K true -A 24 -P 350000 -- -root /usr/lib'.Program terminated with signal 11, Segmentation fault.#0 0x00000000004b698a in sweep_off_heap ()(gdb) bt#0 0x00000000004b698a in sweep_off_heap ()#1 0x00000000004b77d1 in do_minor ()#2 0x00000000004b8479 in erts_garbage_collect ()#3 0x00000000004e1374 in process_main ()#4 0x000000000048071d in sched_thread_func ()#5 0x0000000000549f89 in thr_wrapper ()#6 0x00007faeba32ba30 in start_thread () from /lib/libpthread.so.0#7 0x00007faeb9e8a53d in clone () from /lib/libc.so.6 > > It looks like your beam.smp binary lacks debugging information, so we only know the general > area where it crashed (sweep_off_heap() as called from do_minor()). Crashes here would usually > be due to memory corruption, which could be caused by: > - a bug in the VM > - a bug in a NIF > - a bug in HiPE > - a bug in the C compiler used to compile the VM (I've seen that happen at least 3 times) > - a HW error (though you'd then also find e.g. machine check events logged) > > If you want to debug this, you should first ensure that your beam.smp gets built and installed > with full debugging information (just attach gdb, bt, and list to verify). You should also try > without NIFs or native code, if those are used and you can configure them not to be. _______________________________________________ erlang-bugs mailing list erlang-bugs@REDACTED http://erlang.org/mailman/listinfo/erlang-bugs _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: From garret.smith@REDACTED Fri Jun 3 21:43:53 2016 From: garret.smith@REDACTED (Garret Smith) Date: Fri, 3 Jun 2016 12:43:53 -0700 Subject: [erlang-bugs] R19-rc2 compilation error on FreeBSD 10.3-p4 in unix_efile Message-ID: Going back, this error was present in rc1 as well. I'm on FreeBSD 10.3-p4, trying to compile with both GCC 4.8 and clang 3.4. I get the same error with both compilers compile command (clang) ./otp_build setup -a --prefix=/home/gsmith --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config compile command (gcc) env CC=gcc48 CXX=g++48 ./otp_build setup -a --prefix=/home/gsmith --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config error message: In file included from beam/sys.h:105:0, from drivers/unix/unix_efile.c:32: sys/unix/erl_unix_sys.h: In function 'erts_check_fpe_thorough': sys/unix/erl_unix_sys.h:424:5: error: implicit declaration of function 'finite' [-Werror=implicit-function-declaration] return erts_check_fpe(fp_exception, f) || !isfinite(f); ^ In file included from beam/erl_threads.h:268:0, from beam/erl_smp.h:28, from beam/sys.h:467, from drivers/unix/unix_efile.c:32: beam/erl_term.h: At top level: beam/erl_term.h:57:8: error: #error Hipe on 64-bit needs a real mmap as it does not support the literal tag # error Hipe on 64-bit needs a real mmap as it does not support the literal tag ^ cc1: some warnings being treated as errors x86_64-unknown-freebsd10.3/Makefile:697: recipe for target 'obj/x86_64-unknown-freebsd10.3/opt/smp/unix_efile.o' failed I'll be happy to assist in testing out patches if necessary. -Garret Smith From mikpelinux@REDACTED Sun Jun 5 11:05:39 2016 From: mikpelinux@REDACTED (Mikael Pettersson) Date: Sun, 5 Jun 2016 11:05:39 +0200 Subject: [erlang-bugs] R19-rc2 compilation error on FreeBSD 10.3-p4 in unix_efile In-Reply-To: References: Message-ID: <22355.60259.610527.127377@gargle.gargle.HOWL> Garret Smith writes: > Going back, this error was present in rc1 as well. > I'm on FreeBSD 10.3-p4, trying to compile with both GCC 4.8 and clang > 3.4. I get the same error with both compilers > > compile command (clang) > > ./otp_build setup -a --prefix=/home/gsmith > --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config > > compile command (gcc) > > env CC=gcc48 CXX=g++48 ./otp_build setup -a --prefix=/home/gsmith > --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config > > error message: > > In file included from beam/sys.h:105:0, > from drivers/unix/unix_efile.c:32: > sys/unix/erl_unix_sys.h: In function 'erts_check_fpe_thorough': > sys/unix/erl_unix_sys.h:424:5: error: implicit declaration of function > 'finite' [-Werror=implicit-function-declaration] > return erts_check_fpe(fp_exception, f) || !isfinite(f); > ^ There is a configuration-time check for having isfinite() or finite(), and I'd be very surprised of a recent FreeBSD didn't have at least one of them. However, the check is a linkage check, so it's possible that finite() isn't declared, which would trigger the above warning. The code in erts/emulator/sys/unix/erl_unix_sys.h to choose which one to use (finite or isfinite) is a bit convoluted, and it's possible it makes the wrong choice sometimes. > In file included from beam/erl_threads.h:268:0, > from beam/erl_smp.h:28, > from beam/sys.h:467, > from drivers/unix/unix_efile.c:32: > beam/erl_term.h: At top level: > beam/erl_term.h:57:8: error: #error Hipe on 64-bit needs a real mmap > as it does not support the literal tag > # error Hipe on 64-bit needs a real mmap as it does not support > the literal tag > ^ This means that ERTS_HAVE_OS_PHYSICAL_MEMORY_RESERVATION isn't set in your environment. Can you check if FreeBSD's has MAP_FIXED and MAP_NORESERVE, perhaps with slightly different names? As far as I can tell from git log, this change is due to some changes in erts and not directly caused by HiPE (as the messages would imply). > cc1: some warnings being treated as errors > x86_64-unknown-freebsd10.3/Makefile:697: recipe for target > 'obj/x86_64-unknown-freebsd10.3/opt/smp/unix_efile.o' failed > > I'll be happy to assist in testing out patches if necessary. You may be able to silence both errors by configuring with --disable-hipe, but the real problem isn't in HiPE but in the areas I described above. From essen@REDACTED Sun Jun 5 15:44:08 2016 From: essen@REDACTED (=?UTF-8?Q?Lo=c3=afc_Hoguin?=) Date: Sun, 5 Jun 2016 15:44:08 +0200 Subject: [erlang-bugs] Tiny documentation bug Message-ID: <57542CA8.2040506@ninenines.eu> Hello, It seems the docs incorrectly count the number of arguments to functions in some cases, for example this one: http://erlang.org/doc/man/httpd_util.html#rfc1123_date-2 The URL and the link description in the sidebar are both wrong, since this function only takes one argument. The issue also appears in the doc search, where it returns httpd_util:rfc1123_date/2 instead of /1. Cheers, -- Lo?c Hoguin http://ninenines.eu Author of The Erlanger Playbook, A book about software development using Erlang From garret.smith@REDACTED Mon Jun 6 20:49:27 2016 From: garret.smith@REDACTED (Garret Smith) Date: Mon, 6 Jun 2016 11:49:27 -0700 Subject: [erlang-bugs] R19-rc2 compilation error on FreeBSD 10.3-p4 in unix_efile In-Reply-To: <22355.60259.610527.127377@gargle.gargle.HOWL> References: <22355.60259.610527.127377@gargle.gargle.HOWL> Message-ID: Should we take this discussion to bugs.erlang.org? More inline... On Sun, Jun 5, 2016 at 2:05 AM, Mikael Pettersson wrote: > Garret Smith writes: > > Going back, this error was present in rc1 as well. > > I'm on FreeBSD 10.3-p4, trying to compile with both GCC 4.8 and clang > > 3.4. I get the same error with both compilers > > > > compile command (clang) > > > > ./otp_build setup -a --prefix=/home/gsmith > > --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config > > > > compile command (gcc) > > > > env CC=gcc48 CXX=g++48 ./otp_build setup -a --prefix=/home/gsmith > > --with-wx-config=/usr/local/bin/wxgtk2u-3.0-config > > > > error message: > > > > In file included from beam/sys.h:105:0, > > from drivers/unix/unix_efile.c:32: > > sys/unix/erl_unix_sys.h: In function 'erts_check_fpe_thorough': > > sys/unix/erl_unix_sys.h:424:5: error: implicit declaration of function > > 'finite' [-Werror=implicit-function-declaration] > > return erts_check_fpe(fp_exception, f) || !isfinite(f); > > ^ > > There is a configuration-time check for having isfinite() or finite(), > and I'd be very surprised of a recent FreeBSD didn't have at least one > of them. > FreeBSD has the "isfinite" call, but not "finite". Some comments in erl_unix_sys.h mention that gcc emits assembler for calls to "finite" which is "significantly faster". The configure logs for clang show that "finite" is present, and the generated "erl_compile_flags.h" confirms this with both HAVE_FINITE 1 and HAVE_ISFINITE 1. Seems to me that HAVE_FINITE should be 0, and HAVE_ISFINITE should be 1 in order to trigger the appropriate behavior from the IFDEF chain in erl_unix_sys.h Any pointers for how to figure out where the configure script or the make_compiler_flags is going wrong? > However, the check is a linkage check, so it's possible that finite() > isn't declared, which would trigger the above warning. > > The code in erts/emulator/sys/unix/erl_unix_sys.h to choose which one to > use (finite or isfinite) is a bit convoluted, and it's possible it makes > the wrong choice sometimes. > > > In file included from beam/erl_threads.h:268:0, > > from beam/erl_smp.h:28, > > from beam/sys.h:467, > > from drivers/unix/unix_efile.c:32: > > beam/erl_term.h: At top level: > > beam/erl_term.h:57:8: error: #error Hipe on 64-bit needs a real mmap > > as it does not support the literal tag > > # error Hipe on 64-bit needs a real mmap as it does not support > > the literal tag > > ^ > > This means that ERTS_HAVE_OS_PHYSICAL_MEMORY_RESERVATION isn't set in your > environment. Can you check if FreeBSD's has MAP_FIXED and > MAP_NORESERVE, perhaps with slightly different names? My /usr/include/sys/mman.h has: #define MAP_FIXED 0x0010 /* map addr must be exactly as requested */ #define MAP_NORESERVE 0x0040 /* Sun: don't reserve needed swap area */ > > As far as I can tell from git log, this change is due to some changes in > erts and not directly caused by HiPE (as the messages would imply). > Agree, the HiPE error is only the latest error in the log. The error appears a few times in the compilation. Hoping to get this fixed generally, since it seems to affect more than HiPE. > > cc1: some warnings being treated as errors > > x86_64-unknown-freebsd10.3/Makefile:697: recipe for target > > 'obj/x86_64-unknown-freebsd10.3/opt/smp/unix_efile.o' failed > > > > I'll be happy to assist in testing out patches if necessary. > > You may be able to silence both errors by configuring with --disable-hipe, > but the real problem isn't in HiPE but in the areas I described above. From daniel.goertzen@REDACTED Mon Jun 13 22:45:57 2016 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Mon, 13 Jun 2016 20:45:57 +0000 Subject: [erlang-bugs] No string escaping for SNMP config files Message-ID: Config files written by the SNMP application lack string escaping as shown in the example below. This goes especially badly when there's a quote character in the string (config file becomes unreadable). I plan on doing a PR for this, but I thought I'd mention it here first. -sh-4.3# cat agent.conf %% This file was generated by snmpa_conf (version-5.2) 2016-05-26 ... {intAgentIpAddress, [0,0,0,0]}. {intAgentUDPPort, 161}. {snmpEngineMaxMessageSize, 484}. {snmpEngineID, "?c?0"$?"}. -------------- next part -------------- An HTML attachment was scrubbed... URL: