From bgustavsson@REDACTED Sun Feb 1 09:27:58 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Sun, 1 Feb 2009 09:27:58 +0100 Subject: [erlang-bugs] inet_gethost (small) memory leak In-Reply-To: References: Message-ID: <6672d0160902010027v6dab785fr537f501fe6e2064a@mail.gmail.com> On Fri, Jan 30, 2009 at 7:21 PM, Joseph Wecker wrote: > > I was running valgrind on my erlang program to find some memory leaks in > a port program. As expected, the erlang vm itself was very tight > (compared to some python that ended up getting profiled, my C program, > and even sed- throwing up memory leak errors all over the place). For > what it's worth though, there was one very small memory leak that > Erlang itself was generating. This may be a known problem already, or > it may be too small to care- but it's the only one I saw: > > ==31273== 21 bytes in 1 blocks are definitely lost in loss record 1 of 2 > ==31273== at 0x4025D2E: malloc (vg_replace_malloc.c:207) > ==31273== by 0x4025EAF: realloc (vg_replace_malloc.c:429) > ==31273== by 0x80497EE: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31273== by 0x804AF06: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31273== by 0x804BB34: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31273== by 0x4084684: (below main) (in > /lib/tls/i686/cmov/libc-2.8.90.so) > > > ==31275== > ==31275== 21 bytes in 1 blocks are definitely lost in loss record 1 of 2 > ==31275== at 0x4025D2E: malloc (vg_replace_malloc.c:207) > ==31275== by 0x4025EAF: realloc (vg_replace_malloc.c:429) > ==31275== by 0x80497EE: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31275== by 0x804AF06: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31275== by 0x804BB34: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31275== by 0x4084684: (below main) (in > /lib/tls/i686/cmov/libc-2.8.90.so) > > etc. > Wouldn't be surprised if it was coming from a system call- there may be > nothing you can do about it, but I thought I'd bring it up as I > couldn't find reference to this anywhere. Thanks for finding this! We will investigate. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From daniel@REDACTED Sun Feb 1 10:31:00 2009 From: daniel@REDACTED (Daniel Hedlund) Date: Sun, 1 Feb 2009 04:31:00 -0500 Subject: [erlang-bugs] 2#1 bsl N Crashes Erlang (x86_64) Message-ID: This bug affects x86_64 implementations. Not sure if it's OS specific or affects other 64-bit architectures. 2#1 bsl N crashes Erlang when N is larger than available memory but lower than 2^59. Above 2^59, a bad argument exception occurs. It appears there's supposed to be a check that prevents insanely large values of N, starting at 2^25-64 (64-bit) and 2^24-32 (32-bit); at this point it starts returning "a system limit has been reached". On 32-bit systems, this check works all the way up through the bad argument exception mentioned above. On 64-bit, this check stops working where 2^34 < N < 2^35; it begins attempting to allocate memory again, eventually crashing. Running Fedora 10 (x86_64). Both R12B-4 (via erlang-R12B-4.3.fc10.x86_64.rpm) and R12B-5 (latest source w/ OTP-7738 patch) affected: Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.5 (abort with ^G) 1> 2#1 bsl (trunc(math:pow(2,34))-1). ** exception error: a system limit has been reached in operator bsl/2 called as 1 bsl 17179869183 2> 2#1 bsl (trunc(math:pow(2,35))). Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 4454408120 bytes of memory (of type "heap"). Aborted ... Eshell V5.6.5 (abort with ^G) 1> 2#1 bsl trunc(math:pow(2,59)). ** exception error: bad argument in an arithmetic expression in operator bsl/2 called as 1 bsl 576460752303423488 2> 2#1 bsl (trunc(math:pow(2,59))-1). Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 72057594037928000 bytes of memory (of type "heap_frag"). Aborted Core dump available on request. Cheers, Daniel Hedlund daniel@REDACTED From rvirding@REDACTED Sun Feb 1 14:47:53 2009 From: rvirding@REDACTED (Robert Virding) Date: Sun, 1 Feb 2009 14:47:53 +0100 Subject: [erlang-bugs] core_lint:module/1 problem In-Reply-To: <6672d0160901270540r290b569by843ede5f14ccd53@mail.gmail.com> References: <497DAFE5.9010003@fi.upm.es> <6672d0160901270540r290b569by843ede5f14ccd53@mail.gmail.com> Message-ID: <3dbc6d1c0902010547p5a9de29fl1e846325a7741bd5@mail.gmail.com> Nice Bj?rn, but if you're not careful you will get people actually writing in Core. :-) Robert 2009/1/27 Bjorn Gustavsson > 2009/1/26 Lars-?ke Fredlund : > > Version: otp R12B-5 (not patched) > > Problem: > > Applying core_lint:module/1 to a core erlang module generated by > > compile:file(FileSpec,[to_core,binary] (without problems) > > results in the error message: > > *** Core Erlang ERROR in module schedule: illegal guard expression in > > reschedule/1 > > > > Source code and core erlang code for function attached. > > (apparently the checks for correct guards are too strict for try... > guards). > > Your source code is not complete, so I can't run it through the compiler. > > However, for the R13 release I have extended the test suites to also test > the > core_lint pass and I have fixed all bugs exposed in core_lint as a > result of that. > > /Bj?rn > > -- > Bj?rn Gustavsson, Erlang/OTP, Ericsson AB > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ad.sergey@REDACTED Mon Feb 2 12:22:53 2009 From: ad.sergey@REDACTED (Sergey S) Date: Mon, 2 Feb 2009 03:22:53 -0800 Subject: [erlang-bugs] Erlang can completely hang FreeBSD 7.1 Message-ID: Hello. I've found a serious bug which completely hangs your FreeBSD. I've been waiting for some time for confirmation that it can be posted in public mailing lists. Here is bug-report I wrote to BSD Secure Team some time ago: ----------------------------------8<--------------------------------- Hello. I think I've came across a way to completely freeze FreeBSD under a non-privileged user. The problem was reproduced on two different computers running FreeBSD 7.0. Here is what you need to do in order to reproduce the bug: 1. Install Erlang R12B5 using ports system 2. Run loop.sh (which in fact just starts escript.erl periodically) attached to this letter. 3. Wait until your system freezes WARNING: after that you won't be able to restart your system in a consistent manner using current login session or even connect via SSH. There is only one way to get back into the working system - hard reset. I've found that such a freeze is a result of the following Erlang call in the escript.erl: net_kernel:start([test_node, shortnames]) This call make it possible to do RPC's to another Erlang nodes from escript. This bug never happens under Linux to me (I used Archlinux for testing). I didn't write bug reports neither to Erlang public maillist nor to FreeBSD public maillist because of security purposes. Please let me know if it won't be harmful for FreeBSD to post such a bug report to public Erlang maillist. Contact me if necessary. Thanks for your work. ----------------------------------8<--------------------------------- When FreeBSD 7.1 came out, I tried to reproduce the bug on the fresh installed system - it hanged my system as with 7.0. I've made a simple shell-script (it's attached) causing the problem. Also I've hanged my system some times to ensure that it's easy for anybody to reproduce what I'm talking about. Copy of this letter was sent to freebsd-bugs mailing through FreeBSD PR system: http://lists.freebsd.org/pipermail/freebsd-bugs/2009-February/034016.html Of course the lair of the bug is in FreeBSD, not in Erlang, but I hope that something can be done on the Erlang side. Often it's much easer to update Erlang than to update the whole production system. Thanks. -- Sergey -------------- next part -------------- A non-text attachment was scrubbed... Name: loop.sh Type: application/x-sh Size: 151 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: escript.erl Type: application/octet-stream Size: 373 bytes Desc: not available URL: From raimo+erlang-bugs@REDACTED Mon Feb 2 14:26:35 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Mon, 2 Feb 2009 14:26:35 +0100 Subject: [erlang-bugs] inet_gethost (small) memory leak In-Reply-To: References: Message-ID: <20090202132635.GA9008@erix.ericsson.se> On Fri, Jan 30, 2009 at 11:21:57AM -0700, Joseph Wecker wrote: > > I was running valgrind on my erlang program to find some memory leaks in > a port program. As expected, the erlang vm itself was very tight > (compared to some python that ended up getting profiled, my C program, > and even sed- throwing up memory leak errors all over the place). For > what it's worth though, there was one very small memory leak that > Erlang itself was generating. This may be a known problem already, or > it may be too small to care- but it's the only one I saw: > > ==31273== 21 bytes in 1 blocks are definitely lost in loss record 1 of 2 > ==31273== at 0x4025D2E: malloc (vg_replace_malloc.c:207) > ==31273== by 0x4025EAF: realloc (vg_replace_malloc.c:429) > ==31273== by 0x80497EE: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31273== by 0x804AF06: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31273== by 0x804BB34: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31273== by 0x4084684: (below main) (in > /lib/tls/i686/cmov/libc-2.8.90.so) > > > ==31275== > ==31275== 21 bytes in 1 blocks are definitely lost in loss record 1 of 2 > ==31275== at 0x4025D2E: malloc (vg_replace_malloc.c:207) > ==31275== by 0x4025EAF: realloc (vg_replace_malloc.c:429) > ==31275== by 0x80497EE: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31275== by 0x804AF06: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31275== by 0x804BB34: (within > /usr/lib/erlang/erts-5.6.3/bin/inet_gethost) > ==31275== by 0x4084684: (below main) (in > /lib/tls/i686/cmov/libc-2.8.90.so) > > etc. > Wouldn't be surprised if it was coming from a system call- there may be > nothing you can do about it, but I thought I'd bring it up as I > couldn't find reference to this anywhere. > We have fixed a potential memory leak in our development branch for R13, so can you test tonights snapshot with valgrind if it was this memory leak we fixed... http://www.erlang.org/download/snapshots/otp_src_R13A-0.tar.gz > -Joseph > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs -- / Raimo Niskanen, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Tue Feb 3 10:07:48 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Tue, 3 Feb 2009 10:07:48 +0100 Subject: [erlang-bugs] 2#1 bsl N Crashes Erlang (x86_64) In-Reply-To: References: Message-ID: <6672d0160902030107k25667d67p10a39de97daf4eac@mail.gmail.com> On Sun, Feb 1, 2009 at 10:31 AM, Daniel Hedlund wrote: > This bug affects x86_64 implementations. Not sure if it's OS specific > or affects other 64-bit architectures. 2#1 bsl N crashes Erlang when > N is larger than available memory but lower than 2^59. Above 2^59, a > bad argument exception occurs. > > It appears there's supposed to be a check that prevents insanely large > values of N, starting at 2^25-64 (64-bit) and 2^24-32 (32-bit); at > this point it starts returning "a system limit has been reached". On > 32-bit systems, this check works all the way up through the bad > argument exception mentioned above. On 64-bit, this check stops > working where 2^34 < N < 2^35; it begins attempting to allocate memory > again, eventually crashing. > Thanks for the bug report. The problem was that memory was allocated before attempting to evaluate the 'bsl' operation. I have now added an additional test to generate an exception before the allocation if the amount is clearly too much. We also discovered a few additional minor bugs when examining the code. The corrections will be included in R13. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Wed Feb 4 10:12:24 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 4 Feb 2009 10:12:24 +0100 Subject: [erlang-bugs] Erlang can completely hang FreeBSD 7.1 In-Reply-To: References: Message-ID: <6672d0160902040112jd58f561x790f85974dda7fbb@mail.gmail.com> 2009/2/2 Sergey S : > Hello. > > I've found a serious bug which completely hangs your FreeBSD. I've > been waiting for some time for confirmation that it can be posted in > public mailing lists. Thanks! It does seem that the problem is in FreeBSD. We currently don't run any regular tests on FreeBSD, but we plan to do so in the future (hopefully before the R13 release). /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bgustavsson@REDACTED Wed Feb 4 14:42:36 2009 From: bgustavsson@REDACTED (Bjorn Gustavsson) Date: Wed, 4 Feb 2009 14:42:36 +0100 Subject: [erlang-bugs] Typo in gen_event docs In-Reply-To: <4935150C.2080002@erlang-consulting.com> References: <4935150C.2080002@erlang-consulting.com> Message-ID: <6672d0160902040542t3754fff4x495cccf5df152986@mail.gmail.com> On Tue, Dec 2, 2008 at 11:59 AM, Oscar Hellstr?m wrote: > Hi, > > In the table where relationships between the behaviour functions and the > callback functions are illustrated gen_event:add_sup_handler is written > gen_event:add_suphandler Thanks! It will be corrected in R13A. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From kenji.rikitake@REDACTED Thu Feb 5 02:37:31 2009 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 5 Feb 2009 10:37:31 +0900 Subject: [erlang-bugs] Erlang can completely hang FreeBSD 7.1 In-Reply-To: References: Message-ID: <20090205013731.GA29069@k2r.org> The hanging bug was confirmed on FreeBSD 7.1-RELEASE on Panasonic CF-Y5, with: CPU: Genuine Intel(R) CPU L2400 @ 1.66GHz (1662.51-MHz 686-class CPU) This bug was reproducible either Erlang R12B5 port was built on gcc-3.4.6 (port gcc34) and gcc-4.2.1 (stock cc for 7.x), with HiPE. The system hangs with no response, no crash dump, only powercycling helps. Kenji Rikitake In the message dated Mon, Feb 02, 2009 at 03:22:29AM -0800, Sergey S writes: > I've found that such a freeze is a result of the following Erlang call > in the escript.erl: > > net_kernel:start([test_node, shortnames]) > > This call make it possible to do RPC's to another Erlang nodes from escript. > > This bug never happens under Linux to me (I used Archlinux for testing). From kenji.rikitake@REDACTED Thu Feb 5 04:27:15 2009 From: kenji.rikitake@REDACTED (Kenji Rikitake) Date: Thu, 5 Feb 2009 12:27:15 +0900 Subject: [erlang-bugs] Erlang can completely hang FreeBSD 7.1 In-Reply-To: <20090205013731.GA29069@k2r.org> References: <20090205013731.GA29069@k2r.org> Message-ID: <20090205032715.GA31184@k2r.org> Building Erlang R12B5 WITHOUT SMP support (i.e., NO --enable-smp-support) no longer causes crash on my machine. (w/port gcc34, HiPE enabled.) FYI Kenji Rikitake In the message <20090205013731.GA29069@REDACTED> dated Thu, Feb 05, 2009 at 10:37:07AM +0900, Kenji Rikitake writes: > The hanging bug was confirmed on FreeBSD 7.1-RELEASE on Panasonic CF-Y5, with: > CPU: Genuine Intel(R) CPU L2400 @ 1.66GHz (1662.51-MHz 686-class CPU) > > This bug was reproducible either Erlang R12B5 port was built on > gcc-3.4.6 (port gcc34) and gcc-4.2.1 (stock cc for 7.x), with HiPE. > > The system hangs with no response, no crash dump, only powercycling > helps. > > Kenji Rikitake > > In the message > dated Mon, Feb 02, 2009 at 03:22:29AM -0800, > Sergey S writes: > > I've found that such a freeze is a result of the following Erlang call > > in the escript.erl: > > > > net_kernel:start([test_node, shortnames]) > > > > This call make it possible to do RPC's to another Erlang nodes from escript. > > > > This bug never happens under Linux to me (I used Archlinux for testing). From ad.sergey@REDACTED Thu Feb 5 11:46:08 2009 From: ad.sergey@REDACTED (Sergey S) Date: Thu, 5 Feb 2009 02:46:08 -0800 Subject: [erlang-bugs] Erlang can completely hang FreeBSD 7.1 In-Reply-To: <20090205032715.GA31184@k2r.org> References: <20090205013731.GA29069@k2r.org> <20090205032715.GA31184@k2r.org> Message-ID: Hello. On Wed, Feb 4, 2009 at 7:27 PM, Kenji Rikitake wrote: > Building Erlang R12B5 WITHOUT SMP support (i.e., NO --enable-smp-support) > no longer causes crash on my machine. (w/port gcc34, HiPE enabled.) My Erlang is also built with --enable-smp-support option enabled. I've forgotten to mention it in my bug-report. It looks like you've found the key to reproduce it. Thanks! That is what I've been looking for during the last two days. There is one interesting things to note: yesterday, I reproduced this bug by issuing "erl -sname bilbo -setcookie abc". But I have to say, that it's much easer to hang system using loop.sh/escript.erl. -- Sergey From mclaughlin77@REDACTED Fri Feb 6 21:49:09 2009 From: mclaughlin77@REDACTED (Kelly McLaughlin) Date: Fri, 6 Feb 2009 13:49:09 -0700 Subject: [erlang-bugs] Bug in http:request(): No port set in automatically-added "Host:" header Message-ID: <208c9bd70902061249q3f43b03cjb181394495be6cb7@mail.gmail.com> I submitted a simple patch to fix this to the erlang-patches list. Here's the lnk: http://www.erlang.org/pipermail/erlang-patches/2009-February/000372.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From richardc@REDACTED Sat Feb 7 13:37:28 2009 From: richardc@REDACTED (Richard Carlsson) Date: Sat, 07 Feb 2009 13:37:28 +0100 Subject: [erlang-bugs] code:load_abs/1 fails for packaged modules In-Reply-To: <495800C5.6050709@laposte.net> References: <495800C5.6050709@laposte.net> Message-ID: <498D8088.9060504@it.uu.se> cyril Romain wrote: > _StepToReproduce_: > Let's assume you have /home/me/project/src/test/mymodule.erl and > '-module(test.mymodule)' defined in mymodule.erl. > And the corresponding beam file: /home/me/project/ebin/test/mymodule.beam. > Run Erlang from the project directory with 'erl -pa ebin'. > Now in Erlang code:load_abs("/home/me/project/ebin/test/mymodule") fails > with the following error report: > > _ErrorReport_: > =ERROR REPORT==== 28-Dec-2008::22:12:10 === > beam/beam_load.c(1035): Error loading module mymodule: > module name in object code is test.mymodule > > _Problem_: > In kernel-2.12.5/src/code_server.erl in load_abs/3 the try_load_module/4 > call can fail if Mod0 is [] and if the module is a packaged module (i.e. > a module within a namespace). > It is worth noting that code:load_abs/2 succeed though. Indeed > code:load_abs("/home/me/project/ebin/test/mymodule", test.mymodule) > returns {module,'test.mymodule'}. > > Unfortunately I'm in a case where I only know the file name and not the > module name. FYI, I'm trying to fix dialyzer to support packaged module. > Dialyzer assumes the module name is the filename:basename, which is > wrong for packaged modules. And dialyzer cannot guess the module name > without loading the beam file, hence the load_abs/1 call. I think that the correct thing in this case is to use beam_lib:info() to extract the actual module name from the beam file. To avoid reading the file several times, you could use file:read_file() to fetch the binary data, then call beam_lib:info() on it, and code:load_binary() to perform the actual load, using the name found in the beam info. Arguably, load_abs/1 should do this automatically. After all, if it is supposed to load a module given only a path, it should be responsible for getting the actual name right. But I think that the "try prepending the parent directory name" approach feels wrong. /Richard -- "Having users is like optimization: the wise course is to delay it." -- Paul Graham From steven.charles.davis@REDACTED Mon Feb 9 15:36:21 2009 From: steven.charles.davis@REDACTED (Steve Davis) Date: Mon, 09 Feb 2009 08:36:21 -0600 Subject: [erlang-bugs] Validation of SSL cert files is incorrect in inets httpd_conf Message-ID: <49903F65.4090406@gmail.com> The checks on the existence of ssl_ca_certificate_file and ssl_certificate_key_file actually (re)check for ssl_certificate_file (this looks like a trivial copy/paste bug) These errors are in httpd_conf:validate_config_params/1 at lines 484 and 504 respectively. /s From Gabriele.Luculli@REDACTED Wed Feb 11 12:34:17 2009 From: Gabriele.Luculli@REDACTED (Gabriele Luculli) Date: Wed, 11 Feb 2009 12:34:17 +0100 Subject: [erlang-bugs] Erlang Compiler Crash Message-ID: <94337A8C30958B45AEB07E6F4D899BD32B0AF7741B@AOIEXMB01.AOI.LAN> Hi! It is the first time this happened to me, the erlc compiler crashed! I tried to write the same code in different ways and erlc still crashes. Hereafter is the error message I got. Can anyone help on this ? Any suggestion ? Kind Regards, Gabriele erlc +debug_info +native -W mequ2.erl /home/luculli/Desktop/erlang/mequ2/src/mequ2.erl:none: internal error in native_compile; crash reason: {{case_clause, {error,function_clause, [{hipe_amd64_assemble,resolve_sse2_binop_args, [{x86_imm,150},{x86_temp,0,double,true}]}, {hipe_amd64_assemble,resolve_sse2_fmove_args,2}, {hipe_amd64_assemble,translate_insn,3}, {hipe_amd64_assemble,translate_insns,6}, {hipe_amd64_assemble,translate_mfas,4}, {hipe_amd64_assemble,assemble,4}, {hipe,finalize,5}, {hipe,compile_finish,3}]}}, [{compile,native_compile_1,1}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]} PS: configuration: "Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:4] [async-threads:0] [hipe] [kernel-poll:false]" -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpe@REDACTED Wed Feb 11 13:01:30 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Wed, 11 Feb 2009 13:01:30 +0100 Subject: [erlang-bugs] Erlang Compiler Crash In-Reply-To: <94337A8C30958B45AEB07E6F4D899BD32B0AF7741B@AOIEXMB01.AOI.LAN> References: <94337A8C30958B45AEB07E6F4D899BD32B0AF7741B@AOIEXMB01.AOI.LAN> Message-ID: <18834.48666.624931.238074@harpo.it.uu.se> Gabriele Luculli writes: > Hi! > > It is the first time this happened to me, the erlc compiler crashed! I tried to write the same > code in different ways and erlc still crashes. Hereafter is the error message I got. Can anyone > help on this ? Any suggestion ? > > Kind Regards, > Gabriele > > erlc +debug_info +native -W mequ2.erl > /home/luculli/Desktop/erlang/mequ2/src/mequ2.erl:none: internal error in native_compile; > crash reason: {{case_clause, > {error,function_clause, > [{hipe_amd64_assemble,resolve_sse2_binop_args, > [{x86_imm,150},{x86_temp,0,double,true}]}, > {hipe_amd64_assemble,resolve_sse2_fmove_args,2}, > {hipe_amd64_assemble,translate_insn,3}, > {hipe_amd64_assemble,translate_insns,6}, > {hipe_amd64_assemble,translate_mfas,4}, > {hipe_amd64_assemble,assemble,4}, > {hipe,finalize,5}, > {hipe,compile_finish,3}]}}, > [{compile,native_compile_1,1}, > {compile,'-internal_comp/4-anonymous-1-',2}, > {compile,fold_comp,3}, > {compile,internal_comp,4}, > {compile,internal,3}]} > > > PS: configuration: "Erlang (BEAM) emulator version 5.6.5 [source] [64-bit] [smp:4] [async-threads:0] [hipe] [kernel-poll:false]" 1. Is this OTP R12B-5? 2. Show us the erlang source code that triggers this. From anders.nygren@REDACTED Fri Feb 13 19:31:01 2009 From: anders.nygren@REDACTED (Anders Nygren) Date: Fri, 13 Feb 2009 12:31:01 -0600 Subject: [erlang-bugs] More ssh bugs Message-ID: Hi In ssh-1.0.2, 1, If the shell option is given Options in ssh:daemon/1,2,3, it will be added again before the call to start_daemon. I don't think it causes any errors but it is unnecessary. 2, If HostAddr is not given in ssh:daemon it will use inet:getaddr/2 to get ONE address for the host and only listen on that address. I may be wrong but I expected it to listen on ALL addresses on the host, like it used to do in ssh-0.9.9.6. /Anders From colm.dougan@REDACTED Fri Feb 13 22:27:14 2009 From: colm.dougan@REDACTED (Colm Dougan) Date: Fri, 13 Feb 2009 21:27:14 +0000 Subject: [erlang-bugs] Deadlock when doing gen_tcp:send on Win32 Message-ID: <24d4f39c0902131327p163ec1b0v802e6d0f88fa1482@mail.gmail.com> Hi, I have encountered a problem when doing gen_tcp:send on Win32. The problem is easy to replicate on my setup. I suspect this is a bug in erlang on Win32 but I can't be sure I have unfortunately been unable to replicate this in a stand-alone program I can send you but I have rebuilt erlang (12B-5) and added some extra trace. Here is what I know about the problem : * it seems to occur when there is a fast sender * it seems to *only* occur when gen_tcp:send on a large payload represented as an iolist (in this case the output of calling zlib:deflate on a fairly uncompressible 60k binary). When I call iolist_to_binary before calling gen_tcp:send I can't seem to replicate the problem. I can't explain why the iolist_to_binary helps. Here is the output of some extra trace I added into erts/emulator/drivers/common/inet_drv.c : tcp_sendv(4113): s=61333, len=2080 Send failed, queuing tcp_sendv(4113): sz=0, ev->size=61333, desc->high=8192 tcp_sendv(4113): s=61598, len=2080 Send failed, queuing tcp_sendv(4113): sz=0, ev->size=61598, desc->high=8192 tcp_sendv(4113): s=2080, len=61570 sender forced busy tcp_sendv(4113): sz=1598, ev->size=61570, desc->high=8192 My connection just hangs at that point. On the erlang side the gen_tcp:send call never returns. It just blocks forever. When I do iolist_to_binary on the iolist before calling gen_tcp:send I get similar output but it never hangs. I realize this is a bit sketchy but the app is fairly involved and I can't seem to boil the problem down to a self-contained replication scenario. I'd be happy to work with anyone who wants me to add more trace or to look at my setup (via VPN access or whatever). Also, if this rings any bells at all I'd be grateful for any clues people can give me so I can try to track it down further. A question: I've mentioned that the work-around seems to be to call iolist_to_binary before calling gen_tcp:send. I'm more than happy with that as a work-around as long as it won't be too expensive. Do people think it would be expensive to call iolist_to_binary on an iolist of (approx) 15 x 4000 byte binaries before calling gen_tcp:send when there are many connections in the mix (hundreds or possibly thousands of connections) *or* does calling erlang:port_command do essentially the same work anyway before passing it down to inet_drv? Thanks, Colm From ad.sergey@REDACTED Fri Feb 13 23:20:32 2009 From: ad.sergey@REDACTED (Sergey S) Date: Fri, 13 Feb 2009 14:20:32 -0800 Subject: [erlang-bugs] Parameterized modules aren't correct treated by HiPE Message-ID: Hello. While playing with parameterized modules, I found that they aren't completely supported by HiPE. It was expressed that my HiPE compiled server involving parameterized modules crashed, when I started it. Details are below. I know that parameterized modules we have in R12B5 is an experimental feature, but if it's going to be an official part of the language this bug report may be helpful to make it more stable than it is now. I've just written a sample to be used as a demonstration of this issue. Here is shell session, illustrating how to reproduce it in three steps. The same steps without involving HiPE don't lead to crash: % -------------------------------------------------------------- Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] [async-threads:0] [hipe] [kernel-poll:false] Eshell V5.6.5 (abort with ^G) 1> c(srv, [native]), c(req). {ok,req} 2> srv:start(). <0.53.0> 3> srv ! doit. =ERROR REPORT==== 13-Feb-2009::23:08:52 === Error in process <0.53.0> with exit value: {badarg,[{srv,handler,1},{srv,loop,1},{io,format,2}]} doit % -------------------------------------------------------------- And two modules you need to repeat above steps: % -srv.erl------------------------------------------------- -module(srv). -export([start/0]). start() -> spawn(fun() -> register(?MODULE, self()), loop(fun handler/1) end). handler(Req) -> io:format("# ~p~n", [Req:get_time()]). loop(Handler) -> receive doit -> Handler(req:new(time())), loop(Handler); stop -> ok end. % -------------------------------------------------- % -req.erl------------------------------------------------- -module(req, [Time]). -export([get_time/0]). get_time() -> Time. % -------------------------------------------------- Actually this is more or less how Mochiweb passes its request data (socket, headers etc) to internal funcions through a callback one. It seems that Mochiweb has been using parameterized modules to hide request representation from an user since its first versions. So it becomes impossible to compile such a http-handler using HiPE :( -- Sergey From mikpe@REDACTED Fri Feb 13 23:34:51 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 13 Feb 2009 23:34:51 +0100 Subject: [erlang-bugs] Parameterized modules aren't correct treated by HiPE In-Reply-To: References: Message-ID: <18837.62859.431334.678240@harpo.it.uu.se> Sergey S writes: > Hello. > > While playing with parameterized modules, I found that they aren't > completely supported by HiPE. It was expressed that my HiPE compiled > server involving parameterized modules crashed, when I started it. > Details are below. > > I know that parameterized modules we have in R12B5 is an experimental > feature, but if it's going to be an official part of the language this > bug report may be helpful to make it more stable than it is now. > > I've just written a sample to be used as a demonstration of this issue. > > Here is shell session, illustrating how to reproduce it in three > steps. The same steps without involving HiPE don't lead to crash: > > % -------------------------------------------------------------- > Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.6.5 (abort with ^G) > 1> c(srv, [native]), c(req). > {ok,req} > 2> srv:start(). > <0.53.0> > 3> srv ! doit. > > =ERROR REPORT==== 13-Feb-2009::23:08:52 === > Error in process <0.53.0> with exit value: > {badarg,[{srv,handler,1},{srv,loop,1},{io,format,2}]} > > doit > % -------------------------------------------------------------- > > And two modules you need to repeat above steps: > > % -srv.erl------------------------------------------------- > -module(srv). > -export([start/0]). > > start() -> > spawn(fun() -> register(?MODULE, self()), loop(fun handler/1) end). > > handler(Req) -> > io:format("# ~p~n", [Req:get_time()]). > > loop(Handler) -> > receive > doit -> > Handler(req:new(time())), > loop(Handler); > stop -> > ok > end. > % -------------------------------------------------- > > % -req.erl------------------------------------------------- > -module(req, [Time]). > -export([get_time/0]). > > get_time() -> Time. > % -------------------------------------------------- > > Actually this is more or less how Mochiweb passes its request data > (socket, headers etc) to internal funcions through a callback one. It > seems that Mochiweb has been using parameterized modules to hide > request representation from an user since its first versions. So it > becomes impossible to compile such a http-handler using HiPE :( Thanks for reporting this problem. I'll take a look it it. /Mikael From ingela@REDACTED Mon Feb 16 09:10:23 2009 From: ingela@REDACTED (Ingela Anderton Andin) Date: Mon, 16 Feb 2009 09:10:23 +0100 Subject: [erlang-bugs] More ssh bugs In-Reply-To: References: Message-ID: <49991F6F.1070902@erix.ericsson.se> Hi! Anders Nygren wrote: > Hi > In ssh-1.0.2, > 1, If the shell option is given Options in ssh:daemon/1,2,3, it will > be added > again before the call to start_daemon. I don't think it causes any > errors but it > is unnecessary. > Agreed it is unnecessary, it should not cause you any problems though. > 2, If HostAddr is not given in ssh:daemon it will use inet:getaddr/2 > to get ONE > address for the host and only listen on that address. > I may be wrong but I expected it to listen on ALL addresses on the > host, like it > used to do in ssh-0.9.9.6. > > > That has already been fixed in the latest released ssh, ssh-1.1. Regards Ingela Erlang/OTP - Ericssson From matyas.markovics@REDACTED Tue Feb 17 18:04:24 2009 From: matyas.markovics@REDACTED (Matyas Markovics) Date: Tue, 17 Feb 2009 17:04:24 +0000 Subject: [erlang-bugs] (please review) hanging http_transport:connect/3 call. Message-ID: <499AEE18.8010901@erlang-consulting.com> Hi, I have found some interesting timeout problems in inets and ssl. 1. Http request timeout is ignored for the period of setting up the tcp connection. 2. Ssl connection timeout is only used as a gen_server timeout when calling ssl_server (ssl_broker process init and handle_call-s are ignored). This way of timeout handling becomes critical when calling inet:getaddr/2. This call can hang (i.e. in case of DNS issues) since the timeout is 'infinity'/unset. I've blundered into hidden infinity timeouts in http_transport:connect/3 (if IPv6 support enabled) and in ssl_broker:connect_prim/8. Both of these functions call inet:getaddr/2. I have seen cases where there were no {error, timeout} returned from http:request/4. I reviewed the code of http_client in inets. It seems to me that the only secure way of using http:request/4 is pure tcp connection (no ssl) with ipv6 disabled. However it is still faulty. As I mentioned above the Timeout that can be set in http:request/4 is only activated once the TCP/SSL connection is established and the HTTP request is sent. I need to use https so I'll have to find a solution. In my understanding the correct way of fixing this issues would be to handle timeouts with external timers. For example activate timeout in httpc_handler:send_first_request/3 before establishing the connection. I am not sure about how the ssl:connect/3 should be fixed though. I would appreciate any idea and suggestion. Thx. BTW the source that I was looking at is R11B3. //Matyas -------------- next part -------------- A non-text attachment was scrubbed... Name: matyas_markovics.vcf Type: text/x-vcard Size: 279 bytes Desc: not available URL: From getyourcontacts@REDACTED Wed Feb 18 17:00:05 2009 From: getyourcontacts@REDACTED (Scott Zhang) Date: Thu, 19 Feb 2009 00:00:05 +0800 Subject: [erlang-bugs] [erlang-questions] ibrowse compile error In-Reply-To: <4535f6cd0902180739x4b09a47by756226ff58e0e644@mail.gmail.com> References: <4535f6cd0902170721j61f34565kd978c43177e6a351@mail.gmail.com> <4535f6cd0902170842s56871d0bl44d2cc23c194e0b4@mail.gmail.com> <4535f6cd0902172259k410032a8r86631a731d47f407@mail.gmail.com> <499BBA0C.4060109@charpi.net> <4535f6cd0902172358s4a9096basd916f32669e653ec@mail.gmail.com> <4535f6cd0902180006v3caa5918h781791e397b575a@mail.gmail.com> <4535f6cd0902180011y62e9780as4cf787d251ffe95b@mail.gmail.com> <4535f6cd0902180519p74b693bbrd32d74f9c6da599@mail.gmail.com> <4535f6cd0902180739x4b09a47by756226ff58e0e644@mail.gmail.com> Message-ID: <4535f6cd0902180800g33f017f4qb74747b8ce0b5b92@mail.gmail.com> > Hi. All.I am not sure who I am going to report to. > > Today, I used erlang http client on window 2003 server R2 version to > download a page. This page have a very long url. > I found the http client hung each time I try to download a page. But it > works fine on linux machine. > > Let me know if I can help. > > Regards. > Scott > > ---------- Forwarded message ---------- > From: Kenneth Lundin > Date: Wed, Feb 18, 2009 at 11:20 PM > Subject: Re: [erlang-questions] ibrowse compile error > To: Scott Zhang > Cc: erlang-questions > > > You can post the bug report preferably on the erlang-bugs mailing list > but then you must provide > more detailed info where you point at the actual error in the code or > even provide a patch. > Another option is to provide a minimal program example which shows the > bug when run. > > /Kenneth Erlang/OTP Ericsson > > On Wed, Feb 18, 2009 at 2:19 PM, Scott Zhang > wrote: > > Hi. All. and kenneth. > > > > Just tested on my Linux machine. Both http client and ibrowse work. So > the > > issue only happen on window. > > > > " windows 2003 server R2 " > > > > As I observed, seems erl's low level tcp can't detect tcp shutdown or > things > > like. As tracked by wireshark, the tcp has been closed, But erlang > hungs > > there. This only happen on windows server 2003 R2. (I tested on my 2 > servers > > as I talked previously) > > > > I guess it is a bug in windows binary release. > > > > Where can we post a bug? > > > > Regards. > > > > scott > > > > On Wed, Feb 18, 2009 at 4:11 PM, Scott Zhang > > wrote: > >> > >> wireshare screenshot. > >> Any idea? > >> > >> On Wed, Feb 18, 2009 at 4:06 PM, Scott Zhang > > >> wrote: > >>> > >>> Actually I tried on 2 server one in China and one in US. Both of them > are > >>> not working. > >>> And more, I have to use wireshark to track the package for this http > >>> session. I saw when I was using firefox and .NET program to get this > url. I > >>> saw the correct GET + many many continueous and at end, it get an > Response > >>> Code 200. Then everything is fine. > >>> When I am using http client and ibrowse, I saw the correct GET + many > >>> many continueous > >>> 30821 2503.516971 67.55.101.167 192.168.1.101 TCP [TCP segment of a > >>> reassembled PDU] > >>> > >>> then > >>> sometimes, I never saw the Response Code 200. Sometimes, I saw the > >>> response Code 200 but the erlang program is still blinking there? > >>> I have another question, is there a possibility erlang's low level TCP > >>> implement has flaw to make it unable to detect tcp shutdown or > keepalive? If > >>> not why http client and ibrowse can't run correct? > >>> > >>> Regards. > >>> Scott > >>> > >>> > >>> On Wed, Feb 18, 2009 at 3:58 PM, Scott Zhang < > getyourcontacts@REDACTED> > >>> wrote: > >>>> > >>>> Hi. Nicolas. > >>>> Please check my attachment. > >>>> I did exactly what you told. It is still not working. I'm glad if I > can > >>>> get a no proc error instead a endless blinking. > >>>> Regards. > >>>> Scott > >>>> On Wed, Feb 18, 2009 at 3:34 PM, Nicolas Charpentier > >>>> wrote: > >>>>> > >>>>> Hi, > >>>>> > >>>>> Scott Zhang wrote: > >>>>>> > >>>>>> Hi. All. Another big issue with http client within erlang > distribution > >>>>>> and ibrowse. That makes me start to wonder is ibrowse/http client > really > >>>>>> working? > >>>>>> > >>>>>> Please try following url. > >>>>>> > http://www.cisworldwide.com/xweb/xweb_parser.php?premiumredirect=http%3A%2F%2Fwww.cisworldwide.com%2Fxweb%2Fpremiumsearches%2FxmlNewBackgroundSearch.php%3Fatype%3Dcaps%26fname%3Dscott%26middle_initial%3D%26lname%3Dzhang%26city%3D%26state%3D%26zip%3D%26client_reference%3Dplutux%40harbork.%26cisrestype%3Dunlimited_background&code=11111111&cemail=macromarship@REDACTED > >>>>>> ... > >>>>>> But whether I use http client or ibrowse, they never returns, just > >>>>>> hang there, even I wait for 10 minutes. > >>>>> > >>>>> > ... > >>>>> > >>>>>> 1. http client > >>>>>> get_url(Url) -> > >>>>>> case http:request(get, {Url, []}, [], []) of > >>>>>> {ok, {{Version, 200, ReasonPhrase}, Headers, Body}} -> > >>>>>> Body; > >>>>>> _ -> sleep(500),get_url(Url) > >>>>>> end. > >>>>> > >>>>> It tried inets http client with your url and it works for me. > >>>>> Looking at your code, there is an infinite loop if the response isn't > >>>>> ok (and response code 2000). Did you tried just this ? > >>>>> > >>>>> 1> inets:start(). > >>>>> 2> Url = "your long url". > >>>>> 3> http:request(get, {Url, []}, [], []). > >>>>> > >>>>> > >>>>> The inets application must be started before the request otherwise > >>>>> you'll get an noproc error (I thing that it's your case). > >>>>> > >>>>> > >>>>> Regards, > >>>>> ----- > >>>>> Nicolas Charpentier > >>>>> http://charpi.net > >>>> > >>> > >> > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From xingdong.bian@REDACTED Wed Feb 18 19:18:47 2009 From: xingdong.bian@REDACTED (Xingdong Bian) Date: Wed, 18 Feb 2009 18:18:47 +0000 Subject: [erlang-bugs] xmerl problem Message-ID: <499C5107.2090600@erlang-consulting.com> Hi all, There is an issue with xmerl, or at least the xmerl documentation. The record definition in xmerl.hrl claims that the 'value' element of the xmlText record is an IOlist() (which is defined as IOlist = [char() | binary() | IOlist]). However, when parsing a character reference [1] the unicode code point is included in the list, even if it is not a valid char(). It makes sense to return the unicode code point rather than guessing which caracter set the application wants it translated to, but in this case the documentation should state this. Another approach would be to translate it to the character set of the XML document, but I'm not sure that's very useful, and would require some code to be written for xmerl. The attached xml document should cause an invalid IOlist() to be returned in the xmlText record. [1] http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-references Record definition from xmerl.hrl: %% plain text %% IOlist = [char() | binary () | IOlist] -record(xmlText,{ parents = [], % [{atom(),integer()}] pos, % integer() language = [],% inherits the element's language value, % IOlist() type = text % atom() one of (text|cdata) }). Thanks Xingdong -------------- next part -------------- A non-text attachment was scrubbed... Name: test.xml Type: text/xml Size: 58 bytes Desc: not available URL: From bertil.karlsson@REDACTED Thu Feb 19 10:00:05 2009 From: bertil.karlsson@REDACTED (Bertil Karlsson) Date: Thu, 19 Feb 2009 10:00:05 +0100 Subject: [erlang-bugs] xmerl problem In-Reply-To: <499C5107.2090600@erlang-consulting.com> References: <499C5107.2090600@erlang-consulting.com> Message-ID: <499D1F95.20405@ericsson.com> Hi, you are right about this. Xmerl transforms all parsed code to unicode code points. This should have been clearly stated in the documentation and I will fix it in the next release. For ascii or latin1 this is no problem, but you will get an invalid IOlist() if you have a character sets with unicode code points bigger than 255. /Bertil Xingdong Bian wrote: > Hi all, > > There is an issue with xmerl, or at least the xmerl documentation. The > record definition in xmerl.hrl claims that the 'value' element of the > xmlText record is an IOlist() (which is defined as IOlist = [char() | > binary() | IOlist]). However, when parsing a character reference [1] the > unicode code point is included in the list, even if it is not a valid > char(). It makes sense to return the unicode code point rather than > guessing which caracter set the application wants it translated to, but > in this case the documentation should state this. Another approach would > be to translate it to the character set of the XML document, but I'm not > sure that's very useful, and would require some code to be written for > xmerl. > > The attached xml document should cause an invalid IOlist() to be > returned in the xmlText record. > > [1] http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-references > > Record definition from xmerl.hrl: > %% plain text > %% IOlist = [char() | binary () | IOlist] > -record(xmlText,{ > parents = [], % [{atom(),integer()}] > pos, % integer() > language = [],% inherits the element's language > value, % IOlist() > type = text % atom() one of (text|cdata) > }). > > Thanks > Xingdong > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From mikpe@REDACTED Fri Feb 20 10:24:16 2009 From: mikpe@REDACTED (Mikael Pettersson) Date: Fri, 20 Feb 2009 10:24:16 +0100 Subject: [erlang-bugs] Parameterized modules aren't correct treated by HiPE In-Reply-To: References: Message-ID: <18846.30400.492953.260887@harpo.it.uu.se> Sergey S writes: > Hello. > > While playing with parameterized modules, I found that they aren't > completely supported by HiPE. It was expressed that my HiPE compiled > server involving parameterized modules crashed, when I started it. > Details are below. > > I know that parameterized modules we have in R12B5 is an experimental > feature, but if it's going to be an official part of the language this > bug report may be helpful to make it more stable than it is now. > > I've just written a sample to be used as a demonstration of this issue. > > Here is shell session, illustrating how to reproduce it in three > steps. The same steps without involving HiPE don't lead to crash: > > % -------------------------------------------------------------- > Erlang (BEAM) emulator version 5.6.5 [source] [smp:2] > [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.6.5 (abort with ^G) > 1> c(srv, [native]), c(req). > {ok,req} > 2> srv:start(). > <0.53.0> > 3> srv ! doit. > > =ERROR REPORT==== 13-Feb-2009::23:08:52 === > Error in process <0.53.0> with exit value: > {badarg,[{srv,handler,1},{srv,loop,1},{io,format,2}]} > > doit > % -------------------------------------------------------------- > > And two modules you need to repeat above steps: > > % -srv.erl------------------------------------------------- > -module(srv). > -export([start/0]). > > start() -> > spawn(fun() -> register(?MODULE, self()), loop(fun handler/1) end). > > handler(Req) -> > io:format("# ~p~n", [Req:get_time()]). > > loop(Handler) -> > receive > doit -> > Handler(req:new(time())), > loop(Handler); > stop -> > ok > end. > % -------------------------------------------------- > > % -req.erl------------------------------------------------- > -module(req, [Time]). > -export([get_time/0]). > > get_time() -> Time. > % -------------------------------------------------- > > Actually this is more or less how Mochiweb passes its request data > (socket, headers etc) to internal funcions through a callback one. It > seems that Mochiweb has been using parameterized modules to hide > request representation from an user since its first versions. So it > becomes impossible to compile such a http-handler using HiPE :( This has now been fixed and the fix will be included in R13B. Below you'll find the patch fixing this for R12B-5. /Mikael --- otp_src_R12B-5/lib/hipe/rtl/hipe_rtl_primops.erl.~1~ 2008-06-10 14:47:40.000000000 +0200 +++ otp_src_R12B-5/lib/hipe/rtl/hipe_rtl_primops.erl 2009-02-20 09:22:18.000000000 +0100 @@ -896,6 +896,19 @@ gen_enter_apply(Args=[_M,_F,_AppArgs]) - %% gen_apply_N(Dst, Arity, [M,F|CallArgs], Cont, Fail) -> + MM = hipe_rtl:mk_new_var(), + NotModuleLbl = hipe_rtl:mk_new_label(), + NotModuleLblName = hipe_rtl:label_name(NotModuleLbl), + Tuple = M, + TupleInfo = [], + Index = hipe_rtl:mk_imm(1), + IndexInfo = 1, + [hipe_tagscheme:element(MM, Index, Tuple, NotModuleLblName, TupleInfo, IndexInfo), + gen_apply_N_common(Dst, Arity+1, MM, F, CallArgs++[M], Cont, Fail), + NotModuleLbl, + gen_apply_N_common(Dst, Arity, M, F, CallArgs, Cont, Fail)]. + +gen_apply_N_common(Dst, Arity, M, F, CallArgs, Cont, Fail) -> CallLabel = hipe_rtl:mk_new_label(), CodeAddress = hipe_rtl:mk_new_reg(), [hipe_rtl:mk_call([CodeAddress], find_na_or_make_stub, From pfisher@REDACTED Tue Feb 24 02:56:22 2009 From: pfisher@REDACTED (Paul Fisher) Date: Mon, 23 Feb 2009 19:56:22 -0600 Subject: [erlang-bugs] Strange bus error 7 with HiPE R12B-5 + patch Message-ID: <49A353C6.5060302@alertlogic.net> We have been having strange core dumps happen occasionally in our environment, most of which end up with a stack trace like the following: (gdb) where #0 0x0000000045050b39 in ?? () #1 0x00002aaaabe25922 in ?? () #2 0x000000000000078f in ?? () #3 0x0000000000000000 in ?? () This happens on thread 1... the one that ends up running erts_sys_main_thread(). Pretty weird. Today, i got a core dump on the same thread, while it was running gensweep_nstack(). What follows is my brief trolling through the dump and just following things until it was clear how we ended up at the problem. I would love if someone could help further the diagnosis beyond this point, because I'm not sure where to look beyond this. Without HiPE compilation (which we do on most of our modules) these problems do not occur, so it does seem to point to a HiPE related issue. The environment is a 4 core, Core 2 Q6600, 4 G ECC memory with the emulator running SMP and running 64-bit. cluster-14:/var/alertlogic# uname -a Linux cluster-14 2.6.24-etchnhalf.1-amd64 #1 SMP Fri Dec 26 03:26:12 UTC 2008 x86_64 GNU/Linux Anyway, here is the gdb session: Core was generated by `/usr/lib/erlang/erts-5.6.5/bin/beam.smp -Ktrue -W w -A 32 -a 128 -d -- -root /u'. Program terminated with signal 7, Bus error. #0 gensweep_nstack (p=0x2aaaade37808, ptr_old_htop=0x44048b28, ptr_n_htop=0x44048b20) at hipe/hipe_stack.h:70 70 if (likely(sdesc->bucket.hvalue == ra)) (gdb) where #0 gensweep_nstack (p=0x2aaaade37808, ptr_old_htop=0x44048b28, ptr_n_htop=0x44048b20) at hipe/hipe_stack.h:70 #1 0x00000000004bfc35 in minor_collection (p=0x2aaaade37808, need=2, objv=0x0, nobj=0, recl=0x44048e68) at beam/erl_gc.c:893 #2 0x00000000004c0761 in erts_garbage_collect (p=0x2aaaade37808, need=2, objv=0x0, nobj=0) at beam/erl_gc.c:374 #3 0x000000000050ae1f in hipe_gc (p=0x1b9b860, need=46912528116752) at hipe/hipe_native_bif.c:69 #4 0x000000000050be74 in nbif_gc_1 () at x86_64-unknown-linux-gnu/opt/smp/hipe_amd64_bifs.S:540 #5 0x00002aaaade37808 in ?? () #6 0x00002aaaade37a80 in ?? () #7 0x0000000000000007 in ?? () #8 0x00002aaaaaaed9c0 in ?? () #9 0x00002aaaabe8f0c8 in ?? () #10 0x00002aaaabe937d8 in ?? () #11 0x00002aaaabe937d8 in ?? () #12 0x0000000000509ce4 in hipe_mode_switch (p=0x2aaaade37808, cmd=2895309840, reg=0x2aaaaaaed9c0) at hipe/hipe_x86_glue.h:196 #13 0x00000000004dd97b in process_main () at beam/beam_emu.c:4681 #14 0x000000000048100f in sched_thread_func (vesdp=) at beam/erl_process.c:752 #15 0x0000000000549f24 in thr_wrapper (vtwd=) ---Type to continue, or q to quit--- at common/ethread.c:474 #16 0x00002afcecf9ef1a in start_thread () from /lib/libpthread.so.0 #17 0x00002afced2815d2 in sysctl () from /lib/libc.so.6 #18 0x0000000000000000 in ?? () (gdb) p ra $1 = 1159839139 (gdb) p *sdesc Cannot access memory at address 0x7d337b25097d327b (gdb) list 65 66 static __inline__ const struct sdesc *hipe_find_sdesc(unsigned long ra) 67 { 68 unsigned int i = (ra >> HIPE_RA_LSR_COUNT) & hipe_sdesc_table.mask; 69 const struct sdesc *sdesc = hipe_sdesc_table.bucket[i]; 70 if (likely(sdesc->bucket.hvalue == ra)) 71 return sdesc; 72 do { 73 sdesc = sdesc->bucket.next; 74 } while (sdesc->bucket.hvalue != ra); (gdb) p i $2 = 1 (gdb) p hipe_sdesc_table $3 = { log2size = 16, mask = 65535, used = 26215, bucket = 0x2aaaadc35010 } (gdb) p hipe_sdesc_table.bucket[1] $4 = (struct sdesc *) 0x8f2c50 (gdb) p *hipe_sdesc_table.bucket[1] $5 = { bucket = { hvalue = 1159004161, next = 0x85ab30 }, summary = 2048, livebits = {14} } (gdb) p *hipe_sdesc_table.bucket[1]->bucket.next $6 = { bucket = { hvalue = 1158348801, next = 0x819410 }, summary = 1536, livebits = {1} } (gdb) p *hipe_sdesc_table.bucket[1]->bucket.next->bucket.next $7 = { bucket = { hvalue = 1158283265, next = 0x0 }, summary = 2048, livebits = {0} } (gdb) p *hipe_sdesc_table.bucket[1]->bucket.next->bucket.next->bucket.next Cannot access memory at address 0x0 (gdb) i threads 40 process 24151 0x00002afced27aa96 in getdomainname () from /lib/libc.so.6 39 process 24153 0x00002afcecfa41bf in __read_nocancel () from /lib/libpthread.so.0 38 process 24156 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 37 process 24158 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 36 process 24159 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 35 process 24160 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 34 process 24161 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 33 process 24162 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 32 process 24163 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 31 process 24164 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 30 process 24165 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 29 process 24166 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 ---Type to continue, or q to quit--- 28 process 24167 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 27 process 24168 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 26 process 24169 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 25 process 24170 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 24 process 24171 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 23 process 24172 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 22 process 24173 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 21 process 24174 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 20 process 24175 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 19 process 24176 0x00002afcecfa412f in __write_nocancel () from /lib/libpthread.so.0 18 process 24177 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 17 process 24178 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () ---Type to continue, or q to quit--- from /lib/libpthread.so.0 16 process 24179 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 15 process 24180 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 14 process 24181 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 13 process 24182 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 12 process 24183 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 11 process 24184 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 10 process 24185 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 9 process 24186 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 8 process 24187 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 7 process 24188 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 6 process 24189 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 ---Type to continue, or q to quit--- 5 process 24190 0x00002afcecfa500f in waitpid () from /lib/libpthread.so.0 4 process 24197 0x00002afcecfa1b3a in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 3 process 24199 0x00002afced2819ac in capset () from /lib/libc.so.6 2 process 24200 0x00002afced22b90d in memmove () from /lib/libc.so.6 * 1 process 24198 gensweep_nstack (p=0x2aaaade37808, ptr_old_htop=0x44048b28, ptr_n_htop=0x44048b20) at hipe/hipe_stack.h:70 (gdb) t 19 [Switching to thread 19 (process 24176)]#0 0x00002afcecfa412f in __write_nocancel () from /lib/libpthread.so.0 (gdb) where #0 0x00002afcecfa412f in __write_nocancel () from /lib/libpthread.so.0 #1 0x00000000004f7757 in efile_writev (errInfo=0x7d9e24, flags=, fd=34, iov=0x7c2098, iovcnt=1, size=229146) at drivers/unix/unix_efile.c:1109 #2 0x000000000051769a in invoke_writev (data=) at drivers/common/efile_drv.c:1175 #3 0x00000000004be255 in async_main (arg=) at beam/erl_async.c:242 #4 0x0000000000549f24 in thr_wrapper (vtwd=) at common/ethread.c:474 #5 0x00002afcecf9ef1a in start_thread () from /lib/libpthread.so.0 #6 0x00002afced2815d2 in sysctl () from /lib/libc.so.6 #7 0x0000000000000000 in ?? () -- paul From paul-trapexit@REDACTED Wed Feb 25 20:07:18 2009 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Wed, 25 Feb 2009 11:07:18 -0800 (PST) Subject: [erlang-bugs] release_handler_1 still broken Message-ID: Hey. I just upgraded to r12b5. Thanks and kudos. Unfortunately I noticed that release_handler_1 still fails on dynamic child specifications. Here's a patch (the patch says sasl-2.1.5.1 but it works with r12b5 as well; the file does not appear to have changed). Cheers. -- p --- /usr/lib/erlang/lib/sasl-2.1.5.1/src/release_handler_1.erl 2007-08-05 08:48:53.000000000 -0700 +++ release_handler_1.erl 2008-03-25 19:39:29.000000000 -0700 @@ -505,7 +505,7 @@ application:which_applications())). get_procs([{Name, Pid, worker, dynamic} | T], Sup) when is_pid(Pid) -> - Mods = get_dynamic_mods(Name), + Mods = get_dynamic_mods(Pid), [{Sup, Name, Pid, Mods} | get_procs(T, Sup)]; get_procs([{Name, Pid, worker, Mods} | T], Sup) when is_pid(Pid), is_list(Mods) -> [{Sup, Name, Pid, Mods} | get_procs(T, Sup)]; In an artificial world, only extremists live naturally. -- Paul Graham From ulf.wiger@REDACTED Thu Feb 26 14:30:22 2009 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Thu, 26 Feb 2009 13:30:22 +0000 Subject: [erlang-bugs] erlang:memory(processes_used) returns 0 Message-ID: <49A6996E.9070300@erlang-consulting.com> Presumably, this is a bug: Eshell V5.6.5 (abort with ^G) 1> {erlang:memory(processes_used), proplists:get_value(processes_used,erlang:memory())}. {0,404208} This was produced on a fresh install of R12B-5 on Windows, but the same behaviour is seen on Linux. BR, Ulf W -- Ulf Wiger CTO, Erlang Training & Consulting Ltd http://www.erlang-consulting.com From raimo+erlang-bugs@REDACTED Fri Feb 27 12:47:37 2009 From: raimo+erlang-bugs@REDACTED (Raimo Niskanen) Date: Fri, 27 Feb 2009 12:47:37 +0100 Subject: [erlang-bugs] : : TXT record decoding bug in inet_dns In-Reply-To: References: <20081009082753.GA28156@erix.ericsson.se> Message-ID: <20090227114737.GC13190@erix.ericsson.se> On Fri, Feb 27, 2009 at 01:54:08AM +0100, Geoff Cant wrote: > > Hi there, I noticed this patch didn't make it into R12B5 - any chance of > it making R13? Well it stumbled on the finish line, but I have already applied it to the dev version of R13A. In the process I corrected for SPF records too; I attach that patch. > > I've updated the OTP git repository here > (http://github.com/mfoemmel/erlang-otp/tree/dns_fix). I think the patch > still applies cleanly. > > Cheers, > --Geoff > > Raimo Niskanen writes: > > > Thank you for your patch. > > > > We will take a look at it and if it does not break > > anything it will most probably be accepted. > > > > > > > > On Tue, Oct 07, 2008 at 02:28:06PM +0200, Geoff Cant wrote: > >> "Matthew Dempsky" writes: > >> > >> > 2008/10/6 Geoff Cant : > >> >> inet_dns incorrectly decodes the RData for TXT records as RData instead > >> >> of [Length | Text] = RData, Text. (The RData for TXT records is encoded > >> >> as <>). > >> > > >> > RDATA for TXT records allows more than one character string. > >> > >> Good point - in which case txt records should decode to a list of > >> strings. Updated patch attached (encoding and decoding) against R12B-4 > >> (supercedes previous patches). > >> > > > >> diff --git a/lib/kernel/src/inet_dns.erl b/lib/kernel/src/inet_dns.erl > >> index b99b774..6bd7867 100644 > >> --- a/lib/kernel/src/inet_dns.erl > >> +++ b/lib/kernel/src/inet_dns.erl > >> @@ -400,11 +400,20 @@ decode_data(?S_MX, _, [P1,P0 | Dom], Buffer) -> > >> { ?i16(P1,P0), decode_domain(Dom, Buffer) }; > >> decode_data(?S_SRV, _, [P1,P0, W1,W0, Po1,Po0 | Dom], Buffer) -> > >> { ?i16(P1,P0), ?i16(W1,W0), ?i16(Po1,Po0), decode_domain(Dom, Buffer) }; > >> -decode_data(?S_TXT, _, Data, _Buffer) -> Data; > >> +decode_data(?S_TXT, _, Data, _Buffer) -> > >> + decode_txt(Data); > >> %% sofar unknown or non standard > >> decode_data(_, _, Data, _Buffer) -> > >> Data. > >> > >> +decode_txt_data(List) -> > >> + decode_txt_data(List, []). > >> + > >> +decode_txt_data([], Acc) -> Acc; > >> +decode_txt_data([Len | Data], Acc) -> > >> + {Str,Rest} = lists:split(Len, Data), > >> + decode_txt(Rest, Acc ++ [Str]). > >> + > >> decode_domain(Data, Buffer) -> > >> case dn_expand(Data, Buffer) of > >> error -> error; > >> @@ -498,7 +507,8 @@ encode_data(?S_MX, in, {Pref, Exch}, Ptrs, L) -> > >> encode_data(?S_SRV, in, {Prio, Weight, Port, Target}, Ptrs, L) -> > >> {EDom, NPtrs} = dn_compress(Target, Ptrs, [], L), > >> {?int16(Prio) ++ ?int16(Weight) ++ ?int16(Port) ++ EDom, NPtrs}; > >> -encode_data(?S_TXT, in, Data, Ptrs, _) -> {Data, Ptrs}; > >> +encode_data(?S_TXT, in, Data, Ptrs, _) -> > >> + {[[length(Str) | Str] || Str <- Data], Ptrs}; > >> %% sofar unknown or non standard > >> encode_data(_, _, Data, Ptrs, _) -> {Data, Ptrs}. > >> -- / Raimo Niskanen, Erlang/OTP, Ericsson AB -------------- next part -------------- A non-text attachment was scrubbed... Name: inet_dns.diff Type: text/x-patch Size: 3441 bytes Desc: not available URL: From vinoski@REDACTED Fri Feb 27 21:26:19 2009 From: vinoski@REDACTED (Steve Vinoski) Date: Fri, 27 Feb 2009 15:26:19 -0500 Subject: [erlang-bugs] inets HTTP stream bugs Message-ID: <65b2728e0902271226y11bde54bi94e34007d97c96e3@mail.gmail.com> The following problems were found in R12B-5 by my colleague Matt Evans, and he created and tested the attached patches for them. The inets HTTP code does not handle HTTP status code 206 (Partial Content) responses when using streaming. Handling this is required when a server streams only part of a file (i.e., a range) and thus returns 206 rather than 200. Without this fix, on Linux the client would just block and eat 100% of the CPU. The patches also include a new feature, httpc_response:user_action/4, which passes HTTP status codes other than 200 or 206 back to the client's receive loop for handling. This allows for the handling of redirects, for example. This adds a user_action message to the existing stream_start, stream, stream_end, etc. message types the client can handle. Without this addition it doesn't seem possible for the client to fully know what the server is doing. hope this helps, --steve -------------- next part -------------- A non-text attachment was scrubbed... Name: inets_http_patches.txt.gz Type: application/x-gzip Size: 1277 bytes Desc: not available URL: