From ingela@REDACTED Thu Oct 6 09:57:06 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Thu, 6 Oct 2011 09:57:06 +0200 Subject: [erlang-bugs] SSH public key authentication only works on the first key of authorized_keys In-Reply-To: References: Message-ID: <4E8D5F52.8040503@erix.ericsson.se> Hi! Thank you for the patch. We will look into including it for R15, if you could provide a git-patch with a test case it would speed things up. See https://github.com/erlang/otp/wiki/submitting-patches Regards Ingela Erlang/OTP team - Ericsson AB Ferenc Holzhauser wrote: > Hi, > > Today I stumbled into this old bug (found a post from 2008 about it). > Since I need a working SFTP server, I made a simple patch to solve it. > It is based on the released R14B03 source. > > Perhaps it is useful for someone else too. > > Kind Regards > Ferenc > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From daniel.goertzen@REDACTED Thu Oct 6 19:28:48 2011 From: daniel.goertzen@REDACTED (Daniel Goertzen) Date: Thu, 6 Oct 2011 12:28:48 -0500 Subject: [erlang-bugs] "werl.exe -detached" crashes Message-ID: "werl.exe -detached" crashes if its full path is not specified on the command line. For example, this works... C:\>c:\erlang\bin\werl.exe -detached ... but this does not (PATH includes c:\erlang\bin) .... C:\>werl.exe -detached A dialog pops up saying "Failed to execute C:\erlang\ERTS-5~1.4\bin\beam.smp.dll: The system cannot find the file specified". The problem is that in common/erlexec.c, argv[0] is used as the basis for a call to spawnv(). spawnv() does not search PATHs, so this fails when argv[0] is just "werl.exe". Regards, Dan. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Mon Oct 10 13:13:11 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 10 Oct 2011 13:13:11 +0200 Subject: [erlang-bugs] send_timeout doesn't work In-Reply-To: References: <4D7F7618.4040305@gmail.com> Message-ID: Has this patch ever made it to production? On Mon, Mar 21, 2011 at 3:07 PM, wrote: > Hi! > > Very good test program, it's obviously something wrong here, and that's the > handling of timeouts when we are in active mode. It's broken. > > Please try the attached (very simple) patch, it should fix the problem. > It's still not tested in our daily builds, but it will soon be. Any feedback > is welcome! > > Cheers, > /Patrik > > > On Tue, 15 Mar 2011, Evgeniy Khramtsov wrote: > > It seems like there is a bug in send_timeout option of a TCP socket: the >> timeout is completely ignored (at least in active-once mode). >> The code to reproduce: http://kuku.jabber.ru/~xram/**lock.erl >> Just compile it and start lock:listen() in one shell and lock:send() in >> another: over a time you will see that the receiving process is locked in >> prim_inet:send/3 and doesn't process current message in the mailbox. You can >> also play with PORT and SEND_TIMEOUT macros if needed. >> >> Versions tested: R13B02 and R14B01 (on Debian 2.6.32-5-amd64 SMP). >> >> -- >> Regards, >> Evgeniy Khramtsov, ProcessOne. >> xmpp:xram@REDACTED >> >> >> ______________________________**______________________________**____ >> erlang-bugs (at) erlang.org mailing list. >> See http://www.erlang.org/faq.html >> To unsubscribe; mailto:erlang-bugs-**unsubscribe@REDACTED >> > > > ________________________________________________________________ > erlang-bugs (at) erlang.org mailing list. > See http://www.erlang.org/faq.html > To unsubscribe; mailto:erlang-bugs-unsubscribe@REDACTED > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From xramtsov@REDACTED Mon Oct 10 13:17:22 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Mon, 10 Oct 2011 21:17:22 +1000 Subject: [erlang-bugs] send_timeout doesn't work In-Reply-To: References: <4D7F7618.4040305@gmail.com> Message-ID: <4E92D442.5040607@gmail.com> On 10.10.2011 21:13, Ahmed Omar wrote: > Has this patch ever made it to production? The patch works just great for me (2 servers in production holding ~10k TCP connections each). -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From spawn.think@REDACTED Mon Oct 10 13:20:01 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 10 Oct 2011 13:20:01 +0200 Subject: [erlang-bugs] send_timeout doesn't work In-Reply-To: <4E92D442.5040607@gmail.com> References: <4D7F7618.4040305@gmail.com> <4E92D442.5040607@gmail.com> Message-ID: Great. Has it been included in any Erlang release yet? On Mon, Oct 10, 2011 at 1:17 PM, Evgeniy Khramtsov wrote: > On 10.10.2011 21:13, Ahmed Omar wrote: > >> Has this patch ever made it to production? >> > > The patch works just great for me (2 servers in production holding ~10k TCP > connections each). > > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:xram@REDACTED > > ______________________________**_________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/**listinfo/erlang-bugs > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From xramtsov@REDACTED Mon Oct 10 13:40:42 2011 From: xramtsov@REDACTED (Evgeniy Khramtsov) Date: Mon, 10 Oct 2011 21:40:42 +1000 Subject: [erlang-bugs] send_timeout doesn't work In-Reply-To: References: <4D7F7618.4040305@gmail.com> <4E92D442.5040607@gmail.com> Message-ID: <4E92D9BA.4090002@gmail.com> On 10.10.2011 21:20, Ahmed Omar wrote: > Great. Has it been included in any Erlang release yet? Yes, AFAIR. -- Regards, Evgeniy Khramtsov, ProcessOne. xmpp:xram@REDACTED From spawn.think@REDACTED Mon Oct 10 13:50:23 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Mon, 10 Oct 2011 13:50:23 +0200 Subject: [erlang-bugs] send_timeout doesn't work In-Reply-To: <4E92D9BA.4090002@gmail.com> References: <4D7F7618.4040305@gmail.com> <4E92D442.5040607@gmail.com> <4E92D9BA.4090002@gmail.com> Message-ID: Thanks , found it in R14B03 http://www.erlang.org/download/otp_src_R14B03.readme OTP-9145 The send_timeout option in gen_tcp did not work properly in active mode or with {active,once} options. This is now corrected. On Mon, Oct 10, 2011 at 1:40 PM, Evgeniy Khramtsov wrote: > On 10.10.2011 21:20, Ahmed Omar wrote: > >> Great. Has it been included in any Erlang release yet? >> > > Yes, AFAIR. > > > -- > Regards, > Evgeniy Khramtsov, ProcessOne. > xmpp:xram@REDACTED > > ______________________________**_________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/**listinfo/erlang-bugs > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From rene.kijewski@REDACTED Mon Oct 10 22:49:26 2011 From: rene.kijewski@REDACTED (Rene Kijewski) Date: Mon, 10 Oct 2011 22:49:26 +0200 Subject: [erlang-bugs] Lengthy subfunctions in Core Erlang code crash the compiler if inlining is turned on Message-ID: <20111010224926.375fc484@lappy-ng.localdomain> Hello, (I first asked this question in Stackoverflow but was hinted that this ML is a better place for such questions.) I wanted to test the inlining capabilities of the compiler and wrote a method containing three lengthy subfunctions. (See attachment.) Compiling it without a 'inline' flag works as expected but supplying it renders a crash: > $ erlc +verbose +from_core +inline lengthySubfun.core > Inlining: inline_size=24 inline_effort=150 > Function: test/6 > ./lengthySubfun.core:none: internal error in core_dsetel_module; > crash reason: {{badmatch,error}, > [{sys_core_dsetel,visit,2}, > {lists,mapfoldl,3}, > {sys_core_dsetel,visit,2}, > {sys_core_dsetel,visit,2}, > {sys_core_dsetel,visit,2}, > {sys_core_dsetel,visit,2}, > {sys_core_dsetel,'-visit_def_list/2-anonymous-0-',2}, > {lists,mapfoldl,3}]} unless I specify an insanely high value in range of 10 000 for both inline_effort and inline_size. The method can be called like that: > lengthySubfun:test(fun () -> 1 end, fun () -> 2 end, fun (X) -> X end, > fun (X) -> X end, fun () -> true end, fun (X) -> X end). My Erlang/OTP version is: > Erlang R14B04 (erts-5.8.5) [source] [64-bit] [smp:2:2] [rq:2] > [async-threads:0] [hipe] [kernel-poll:false] Compiled from: > 68c96ca855821adb42a25ced5b69446ae7ccc635 Best regards Ren? -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: lengthySubfun.core Type: application/x-core Size: 33895 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From bgustavsson@REDACTED Tue Oct 11 07:54:39 2011 From: bgustavsson@REDACTED (=?UTF-8?Q?Bj=C3=B6rn_Gustavsson?=) Date: Tue, 11 Oct 2011 07:54:39 +0200 Subject: [erlang-bugs] Lengthy subfunctions in Core Erlang code crash the compiler if inlining is turned on In-Reply-To: <20111010224926.375fc484@lappy-ng.localdomain> References: <20111010224926.375fc484@lappy-ng.localdomain> Message-ID: On Mon, Oct 10, 2011 at 10:49 PM, Rene Kijewski wrote: > Hello, > > (I first asked this question in Stackoverflow but was hinted that this ML > is a better place for such questions.) > > I wanted to test the inlining capabilities of the compiler and wrote a > method containing three lengthy subfunctions. (See attachment.) > > Compiling it without a 'inline' flag works as expected but supplying it > renders a crash: > >> $ erlc +verbose +from_core +inline lengthySubfun.core >> Inlining: inline_size=24 inline_effort=150 >> Function: test/6 >> ./lengthySubfun.core:none: internal error in core_dsetel_module; >> crash reason: {{badmatch,error}, >> ? ? ? ? ? ? ? ?[{sys_core_dsetel,visit,2}, >> ? ? ? ? ? ? ? ? {lists,mapfoldl,3}, >> ? ? ? ? ? ? ? ? {sys_core_dsetel,visit,2}, >> ? ? ? ? ? ? ? ? {sys_core_dsetel,visit,2}, >> ? ? ? ? ? ? ? ? {sys_core_dsetel,visit,2}, >> ? ? ? ? ? ? ? ? {sys_core_dsetel,visit,2}, >> ? ? ? ? ? ? ? ? {sys_core_dsetel,'-visit_def_list/2-anonymous-0-',2}, >> ? ? ? ? ? ? ? ? {lists,mapfoldl,3}]} > > unless I specify an insanely high value in range of 10 000 for both > inline_effort and inline_size. > I am not sure whether this should be classified as a bug or not. The case statement in the "sub-function" continue/1 only contains one clause: case of <{V250}> when 'true' -> ... end The Core Erlang specification says that the behavior is undefined if no clause can be selected in a case. Looking at only at the case statement itself, it is impossible to tell whether the clause will always be selected. Only by looking at the entire program can it been seen that the clause will indeed always be selected. The inliner assumes that the compiler has generated code similar to this: case of <{V250}> when 'true' -> ... when 'true' -> primop 'function_clause' end so that it can clearly be clearly seen looking just at the case statement that one of the clauses is guaranteed to be selected. I am not sure yet whether we will attempt to fix this problem in the inliner, since it can only happen when compiling from Core Erlang code, never from Erlang code. /Bj?rn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From rene.kijewski@REDACTED Wed Oct 12 09:31:53 2011 From: rene.kijewski@REDACTED (Rene Kijewski) Date: Wed, 12 Oct 2011 09:31:53 +0200 Subject: [erlang-bugs] Lengthy subfunctions in Core Erlang code crash the compiler if inlining is turned on In-Reply-To: References: <20111010224926.375fc484@lappy-ng.localdomain> Message-ID: <20111012093153.58660dbb@lappy-ng.localdomain> Am Tue, 11 Oct 2011 07:54:39 +0200 schrieb Bj?rn Gustavsson : > I am not sure whether this should be classified as a bug or not. Hello, thank you for the answer! Your explanation was right. Inserting when 'true' -> primop 'match_fail' ({'function_clause', Some}) into the case block fixes the problem. > The Core Erlang specification says that the behavior is undefined > if no clause can be selected in a case. Looking at only at the > case statement itself, it is impossible to tell whether the clause > will always be selected. Only by looking at the entire program can > it been seen that the clause will indeed always be selected. > > I am not sure yet whether we will attempt to fix this > problem in the inliner, since it can only happen when > compiling from Core Erlang code, never from Erlang > code. I assumed a match_fail was inserted automatically if absent, but that was only a guess, I -- accidentally -- proved wrong. So: no bug. Best regards Ren? -- () ascii ribbon campaign - against HTML e-mail /\ www.asciiribbon.org - against proprietary attachments -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From carlsson.richard@REDACTED Wed Oct 12 10:20:25 2011 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 12 Oct 2011 10:20:25 +0200 Subject: [erlang-bugs] Lengthy subfunctions in Core Erlang code crash the compiler if inlining is turned on In-Reply-To: <20111012093153.58660dbb@lappy-ng.localdomain> References: <20111010224926.375fc484@lappy-ng.localdomain> <20111012093153.58660dbb@lappy-ng.localdomain> Message-ID: <4E954DC9.7060203@gmail.com> On 10/12/2011 09:31 AM, Rene Kijewski wrote: > Am Tue, 11 Oct 2011 07:54:39 +0200 > schrieb Bj?rn Gustavsson: > >> I am not sure whether this should be classified as a bug or not. > > Hello, thank you for the answer! > > Your explanation was right. Inserting > when 'true' -> primop 'match_fail' ({'function_clause', Some}) > into the case block fixes the problem. > >> The Core Erlang specification says that the behavior is undefined >> if no clause can be selected in a case. Looking at only at the >> case statement itself, it is impossible to tell whether the clause >> will always be selected. Only by looking at the entire program can >> it been seen that the clause will indeed always be selected. >> >> I am not sure yet whether we will attempt to fix this >> problem in the inliner, since it can only happen when >> compiling from Core Erlang code, never from Erlang >> code. > > I assumed a match_fail was inserted automatically if absent, but that > was only a guess, I -- accidentally -- proved wrong. > > So: no bug. > > Best regards > Ren? I think that the inliner should still not crash on this, so I'll put it in my list of open issues, but it's got pretty low priority. /Richard From mmzeeman@REDACTED Fri Oct 14 15:32:43 2011 From: mmzeeman@REDACTED (mmzeeman@REDACTED) Date: Fri, 14 Oct 2011 15:32:43 +0200 Subject: [erlang-bugs] inets httpc auto_redirect problem Message-ID: <634ce87a7c9227ed1c3b5fac20fcb68d.squirrel@webmail.xs4all.nl> Hello, When I do a request with auto_redirect enabled I would really like to know from what the uri of the response is. There could have been multiple redirects. Currently there is no way to tell this. It would be really helpful if the abs_uri from the request record was included in the response. Kind regards, MM Zeeman From systemio@REDACTED Fri Oct 14 15:56:29 2011 From: systemio@REDACTED (=?UTF-8?B?c3lzdGVtaW8gc3lzdGVtaW8=?=) Date: Fri, 14 Oct 2011 17:56:29 +0400 Subject: [erlang-bugs] =?utf-8?q?Erlang_crashes_when_time_changes?= Message-ID: hi, i've found a strange behaviour. I change OS(win xp sp3) time to some 2055 and start werl.exe (R14B04) and it crashes always. GoodLuck! -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric.pailleau@REDACTED Sun Oct 16 10:41:35 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Oct 2011 10:41:35 +0200 Subject: [erlang-bugs] Erlang crashes when time changes In-Reply-To: References: Message-ID: <4E9A98BF.3090601@wanadoo.fr> Le 14/10/2011 15:56, systemio systemio a ?crit : > hi, > i've found a strange behaviour. I change OS(win xp sp3) time to some > 2055 and start werl.exe (R14B04) and it crashes always. > GoodLuck! hello, could this be related to the "Year 2038 problem" for Unix timestamp ? (timestamp represented as an unsigned 32 bit ). Does Erlang safe against this problem ? Regards. From eric.pailleau@REDACTED Sun Oct 16 10:45:14 2011 From: eric.pailleau@REDACTED (PAILLEAU Eric) Date: Sun, 16 Oct 2011 10:45:14 +0200 Subject: [erlang-bugs] Erlang crashes when time changes In-Reply-To: <4E9A98BF.3090601@wanadoo.fr> References: <4E9A98BF.3090601@wanadoo.fr> Message-ID: <4E9A999A.6060708@wanadoo.fr> Le 16/10/2011 10:41, PAILLEAU Eric a ?crit : > could this be related to the "Year 2038 problem" for Unix timestamp ? > (timestamp represented as an unsigned 32 bit ). Sorry, read 'signed 32 bit'. From kruskakli@REDACTED Tue Oct 18 14:28:09 2011 From: kruskakli@REDACTED (etnt) Date: Tue, 18 Oct 2011 14:28:09 +0200 Subject: [erlang-bugs] ssl badarith Message-ID: Hi, We are getting lots of error messages like this: == 18-Oct-2011::14:11:00 == ERROR - emulator Error in process <0.27172.1216> on node 'xxx@REDACTED' with exit value: {badarith,[{ssl_session,valid_session,2},{ssl_manager,validate_session,3},{ssl_manager,session_validation,2},{lists,foldl,3},{ets,do_foldl,4},{ets,foldl,3}]} That 'badarith' doesn't look good. We are running R14B03. Cheers, K. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Tue Oct 18 15:50:05 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Tue, 18 Oct 2011 15:50:05 +0200 Subject: [erlang-bugs] ssl badarith In-Reply-To: References: Message-ID: Hi, I didn't dig into it, but R14B04 included some fixes regarding the way sessions are validated and cleaned up, so it might worth upgrading and checking if the same problem still there. On Tue, Oct 18, 2011 at 2:28 PM, etnt wrote: > Hi, > > We are getting lots of error messages like this: > > == 18-Oct-2011::14:11:00 == ERROR - emulator > Error in process <0.27172.1216> on node 'xxx@REDACTED' with exit value: > {badarith,[{ssl_session,valid_session,2},{ssl_manager,validate_session,3},{ssl_manager,session_validation,2},{lists,foldl,3},{ets,do_foldl,4},{ets,foldl,3}]} > > That 'badarith' doesn't look good. > We are running R14B03. > > Cheers, K. > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From ingela@REDACTED Wed Oct 19 08:53:37 2011 From: ingela@REDACTED (Ingela Anderton Andin) Date: Wed, 19 Oct 2011 08:53:37 +0200 Subject: [erlang-bugs] ssl badarith In-Reply-To: References: Message-ID: <4E9E73F1.3070708@erix.ericsson.se> Hi! It is always good to check if the problem is in the latest release (R14B03 was alas not a very good ssl-release). If the problem should still be there could you use the following trace commands dbg:tracer(). dbg:p(all, [call]). dbg:tpl(ssl_session, x). to see if you can get some more information. Regards Ingela Erlang OTP/team -Ericsson AB etnt wrote: > Hi, > > We are getting lots of error messages like this: > > == 18-Oct-2011::14:11:00 == ERROR - emulator > Error in process <0.27172.1216> on node 'xxx@REDACTED' with exit value: > {badarith,[{ssl_session,valid_session,2},{ssl_manager,validate_session,3},{ssl_manager,session_validation,2},{lists,foldl,3},{ets,do_foldl,4},{ets,foldl,3}]} > > That 'badarith' doesn't look good. > We are running R14B03. > > Cheers, K. > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From anthony.shipman@REDACTED Wed Oct 19 08:33:35 2011 From: anthony.shipman@REDACTED (anthony.shipman@REDACTED) Date: Wed, 19 Oct 2011 17:33:35 +1100 Subject: [erlang-bugs] beam_lib:strip() removes native code Message-ID: <201110191733.35867.anthony.shipman@symstream.com> This is still a bug in R14B04. -- Anthony Shipman | Will take your health responsibility Anthony.Shipman@REDACTED | by the superlative quality From tomasz.pastuch@REDACTED Fri Oct 21 16:38:32 2011 From: tomasz.pastuch@REDACTED (Tomasz Pastuch) Date: Fri, 21 Oct 2011 16:38:32 +0200 Subject: [erlang-bugs] ERLANG VM crashed Message-ID: Hello, during using ttb module, erlang VM sometimes dumps core. Probably during ttb:stop() - but it seems to be randomly. We using R13B03 version. Please find a call stack from core: #0 0x00000000004529be in erts_ddll_proc_dead (p=0x2aaab9fb17f0, plocks=1) at beam/erl_bif_ddll.c:1054 #1 0x00000000004a5217 in continue_exit_process (p=0x2aaab9fb17f0, pix_lock=0x88c920) at beam/erl_process.c:7522 #2 0x00000000004a570a in erts_do_exit_process (p=0x2aaab9fb17f0, reason=148811) at beam/erl_process.c:7451 #3 0x00000000005227a6 in handle_error (c_p=0x2aaab9fb17f0, pc=0x19fd69e8, reg=0x2b16ce9ec2c0, bf=0x0) at beam/beam_emu.c:5633 #4 0x000000000052957d in process_main () at beam/beam_emu.c:3273 #5 0x000000000049c8bb in sched_thread_func (vesdp=) at beam/erl_process.c:3789 #6 0x000000000059df0c in thr_wrapper (vtwd=) at pthread/ethread.c:106 #7 0x0000003020e06367 in start_thread () from /lib64/libpthread.so.0 #8 0x00000030202d30ad in clone () from /lib64/libc.so.6 I've checked the erl_bif_ddll.c file and it seems that the problem lies in: prt->drv_ptr->handle ^^^^^^^^ drv_ptr is NULL. I don't know how exactly it should work, but for me it should look sth like this: if (!(prt->status & FREE_PORT_FLAGS) && prt->drv_ptr && prt->drv_ptr->handle == dh) I've checked the sources for B04 version and it seems that this problem is not fixed there. Here you have more debugs: (gdb) p *prt $2 = {sched = {next = 0x0, prev = 0x0, taskq = 0x0, exe_taskq = 0x0}, timeout_task = {counter = 0}, refc = {counter = 2}, lock = 0x1a000ab0, xports = 0x0, run_queue = {counter = 47376955437248}, state_lck = {slck = {lock = 1}}, id = 259319, connected = 51, caller = 18446744073709551611, data = 971, bp = 0x0, nlinks = 0x0, monitors = 0x0, bytes_in = 7, bytes_out = 63, ptimer = 0x0, tracer_proc = 18446744073709551611, trace_flags = 0, ioq = {size = 0, v_start = 0x0, v_end = 0x0, v_head = 0x0, v_tail = 0x0, v_small = {{ iov_base = 0x1a056671, iov_len = 4}, {iov_base = 0x1a04ed38, iov_len = 81}, {iov_base = 0x1a04edc1, iov_len = 61}, {iov_base = 0x0, iov_len = 0}, {iov_base = 0x0, iov_len = 0}}, b_start = 0x0, b_end = 0x0, b_head = 0x0, b_tail = 0x0, b_small = {0x0, 0x0, 0x0, 0x0, 0x0}}, dist_entry = 0x0, name = 0x19ffd3b8 "efile", drv_ptr = 0x0, drv_data = 437074800, suspended = 0x0, linebuf = 0x0, status = 4096, control_flags = 0, snapshot = 0, reg = 0x0, port_data_lock = 0x0, psd = 0x0} (gdb) p prt->drv_ptr $4 = (erts_driver_t *) 0x0 best regards ---------------------------------------------------------------- Zarabiaj nawet o 3 tys. wiecej! http://linkint.pl/f2a59 From ulf.wiger@REDACTED Sat Oct 22 07:04:25 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 22 Oct 2011 07:04:25 +0200 Subject: [erlang-bugs] typo in diameter_service.erl? Message-ID: In https://github.com/erlang/otp/blob/master/lib/diameter/src/app/diameter_service.erl#L2028 fa(Rec, FailedAvp, Dict) -> try {'Failed-AVP', [FailedAvp]} catch error: _ -> Avps = Dict:'get-'('AVP', Rec), A = #diameter_avp{name = 'Failed-AVP', value = FailedAvp}, {'AVP', [A|Avps]} end. Shouldn't that be Avps = Dict:'#get-'('AVP', Rec)? This is just from visual inspection of the code. I haven't tried actually executing the exception clause. BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From nox@REDACTED Sat Oct 22 11:56:43 2011 From: nox@REDACTED (Anthony Ramine) Date: Sat, 22 Oct 2011 11:56:43 +0200 Subject: [erlang-bugs] typo in diameter_service.erl? In-Reply-To: References: Message-ID: <17A48606-0EEA-4606-B7EE-4FF566E0EB28@dev-extend.eu> Le 22 oct. 2011 ? 07:04, Ulf Wiger a ?crit : > > In https://github.com/erlang/otp/blob/master/lib/diameter/src/app/diameter_service.erl#L2028 > > fa(Rec, FailedAvp, Dict) -> > try > {'Failed-AVP', [FailedAvp]} > catch > error: _ -> > Avps = Dict:'get-'('AVP', Rec), > A = #diameter_avp{name = 'Failed-AVP', > value = FailedAvp}, > {'AVP', [A|Avps]} > end. > > Shouldn't that be > > Avps = Dict:'#get-'('AVP', Rec)? > > This is just from visual inspection of the code. I haven't tried actually executing the exception clause. > > BR, > Ulf W By the way, how could the exception clause could ever be executed as the tried expression {'Failed-AVP', [FailedAvp]} should never fail? -- Anthony Ramine / @nokusu Dev:Extend ? http://dev-extend.eu/ So as I pray, ?Unlimited Erlang Works? From ulf.wiger@REDACTED Sat Oct 22 13:15:14 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sat, 22 Oct 2011 13:15:14 +0200 Subject: [erlang-bugs] typo in diameter_service.erl? In-Reply-To: <17A48606-0EEA-4606-B7EE-4FF566E0EB28@dev-extend.eu> References: <17A48606-0EEA-4606-B7EE-4FF566E0EB28@dev-extend.eu> Message-ID: <42C84587-0753-439A-AF6E-FF1DDECA3C0A@erlang-solutions.com> On 22 Oct 2011, at 11:56, Anthony Ramine wrote: > By the way, how could the exception clause could ever be executed as the tried expression {'Failed-AVP', [FailedAvp]} should never fail? ?and there is that too, of course. :) BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ulf.wiger@REDACTED Sun Oct 23 14:10:52 2011 From: ulf.wiger@REDACTED (Ulf Wiger) Date: Sun, 23 Oct 2011 14:10:52 +0200 Subject: [erlang-bugs] erl_pp having problems with typed record defs Message-ID: <7CEBA21F-110F-4594-B4B3-6E0D8DD3CD91@erlang-solutions.com> I noticed that erl_pp gets very unhappy with typed records. Example: -module(trec). -export([f/0]). -record(r, {i = 0 :: integer()}). f() -> #r{}. uwbook:src uwiger$ erlc -W +debug_info trec.erl uwbook:src uwiger$ pp trec.beam -file("./trec.erl", 1). -module(trec). -export([f/0]). -record(r,{i = 0}). -type {record,r}() :: INVALID-FORM:[{typed_record_field,{record_field,4,{atom,4,i},{integer,4,0}},{type,4,integer,[]}}]:. f() -> #r{}. I'm using OTP R14B04. alias pp='escript /Users/uwiger/ETC/git/parse_trans/ebin/parse_trans_pp.beam' where parse_trans_pp basically does: io_lib:fwrite("~s~n", [lists:flatten( [erl_pp:form(Form) || Form <- AC])]) It seems to me as if the issue is that the typed record spec gets broken up in two different forms, and erl_pp:form/1 obviously can't put them together again, as it gets one form at a time. Any suggestions on how to get around this? BR, Ulf W Ulf Wiger, CTO, Erlang Solutions, Ltd. http://erlang-solutions.com From robert.virding@REDACTED Sun Oct 23 15:46:12 2011 From: robert.virding@REDACTED (Robert Virding) Date: Sun, 23 Oct 2011 14:46:12 +0100 (BST) Subject: [erlang-bugs] erl_pp having problems with typed record defs In-Reply-To: <7CEBA21F-110F-4594-B4B3-6E0D8DD3CD91@erlang-solutions.com> Message-ID: <1b308acc-b7ec-4cbd-8600-b20297d2f05c@knuth> Don't use types. :-) Robert ----- Original Message ----- > > I noticed that erl_pp gets very unhappy with typed records. > > Example: > > -module(trec). > -export([f/0]). > > -record(r, {i = 0 :: integer()}). > > f() -> > #r{}. > > > uwbook:src uwiger$ erlc -W +debug_info trec.erl > uwbook:src uwiger$ pp trec.beam > -file("./trec.erl", 1). > -module(trec). > -export([f/0]). > -record(r,{i = 0}). > -type {record,r}() :: > INVALID-FORM:[{typed_record_field,{record_field,4,{atom,4,i},{integer,4,0}},{type,4,integer,[]}}]:. > f() -> > #r{}. > > > I'm using OTP R14B04. > alias pp='escript > /Users/uwiger/ETC/git/parse_trans/ebin/parse_trans_pp.beam' > > where parse_trans_pp basically does: > > io_lib:fwrite("~s~n", [lists:flatten( > [erl_pp:form(Form) || > Form <- AC])]) > > It seems to me as if the issue is that the typed record spec gets > broken up in two different forms, and erl_pp:form/1 obviously can't > put them together again, as it gets one form at a time. > > Any suggestions on how to get around this? > > BR, > Ulf W > > Ulf Wiger, CTO, Erlang Solutions, Ltd. > http://erlang-solutions.com > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From hans.bolinder@REDACTED Mon Oct 24 08:22:24 2011 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Mon, 24 Oct 2011 08:22:24 +0200 Subject: [erlang-bugs] erl_pp having problems with typed record defs In-Reply-To: <7CEBA21F-110F-4594-B4B3-6E0D8DD3CD91@erlang-solutions.com> References: <7CEBA21F-110F-4594-B4B3-6E0D8DD3CD91@erlang-solutions.com> Message-ID: <20133.1056.263202.477767@ornendil.otp.ericsson.se> [Ulf Wiger:] > I noticed that erl_pp gets very unhappy with typed records. ... > where parse_trans_pp basically does: > > io_lib:fwrite("~s~n", [lists:flatten( > [erl_pp:form(Form) || > Form <- AC])]) ... > Any suggestions on how to get around this? Form <- epp:restore_typed_record_fields(AC) Best regards, Hans Bolinder, Erlang/OTP team, Ericsson From pan@REDACTED Tue Oct 25 14:23:30 2011 From: pan@REDACTED (pan@REDACTED) Date: Tue, 25 Oct 2011 14:23:30 +0200 Subject: [erlang-bugs] Erlang crashes when time changes In-Reply-To: <4E9A98BF.3090601@wanadoo.fr> References: <4E9A98BF.3090601@wanadoo.fr> Message-ID: Yes, you are absolutely right. The windows port uses a 32bit time_t.?That will be corrected in R15 when the windows time code is cleaned up to work with 64bit windows. Cheers, /Patrik On Sun, 16 Oct 2011, PAILLEAU Eric wrote: > Le 14/10/2011 15:56, systemio systemio a ?crit : >> hi, >> i've found a strange behaviour. I change OS(win xp sp3) time to some >> 2055 and start werl.exe (R14B04) and it crashes always. >> GoodLuck! > > hello, > could this be related to the "Year 2038 problem" for Unix timestamp ? > (timestamp represented as an unsigned 32 bit ). > > Does Erlang safe against this problem ? > > Regards. > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From systemio@REDACTED Thu Oct 27 09:57:50 2011 From: systemio@REDACTED (=?UTF-8?B?c3lzdGVtaW8gc3lzdGVtaW8=?=) Date: Thu, 27 Oct 2011 11:57:50 +0400 Subject: [erlang-bugs] =?utf-8?q?file=3Awrite=5Ffile=5Finfo_incorrect_beha?= =?utf-8?q?vior?= Message-ID: try to change access time using file:write_file_info("file.txt",#file_info{atime={date(),time()}}). but modify time is also changed to the same value. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spawn.think@REDACTED Thu Oct 27 15:30:30 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 27 Oct 2011 15:30:30 +0200 Subject: [erlang-bugs] file:write_file_info incorrect behavior In-Reply-To: References: Message-ID: If there's no special reason for this behavior, this fix should do the job https://github.com/spawnthink/otp/compare/fix_atime_mtime.patch On Thu, Oct 27, 2011 at 9:57 AM, systemio systemio wrote: > try to change access time using > file:write_file_info("file.txt",#file_info{atime={date(),time()}}). > but modify time is also changed to the same value. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From eurekafag@REDACTED Thu Oct 27 16:14:02 2011 From: eurekafag@REDACTED (eurekafag) Date: Thu, 27 Oct 2011 18:14:02 +0400 Subject: [erlang-bugs] httpc messing with headers Message-ID: I wrote a simple multiprocess gallery downloader on Erlang: http://pastebin.com/bY3cVceH It implements workers pool which get jobs and save files using httpc:request. If I run 10 or more processes after some files downloaded I'm getting errors like this: ** Reason for termination == ** {bad_return_value,{error,{invalid_version,"Ranges:"}}} The string may be anything else but it always looks like a part of HTTP header. Sometimes it's a today date, just an empty string [], a block of data or even "st-modified:" ("Last-modified:" header part). The easiest way to get a bunch of those errors is to start main/1 like this: galdl:main(["http://ru.fishki.net/picsw/042011/13/bonus/kostumi/~3..0w.jpg", "1", "160", "10"]). Arguments are strings for starting the program with erl -run. First 20-30 pictures are downloaded ok but then errors come up. I tried limiting keep-alive, sessions and pipelining to no avail. Looking tcpdump reports I've found that headers of those files are in the middle of packet not in the beginning. That's why I think it's something wrong with persistent connections handling. Googling revealed almost nothing (a couple of reports in 2009 and a patch which I already have in R14B03 and an advice to use ibrowse). From systemio@REDACTED Thu Oct 27 17:54:36 2011 From: systemio@REDACTED (=?UTF-8?B?c3lzdGVtaW8gc3lzdGVtaW8=?=) Date: Thu, 27 Oct 2011 19:54:36 +0400 Subject: [erlang-bugs] =?utf-8?q?erlang_crashes_after_file=3Achange=5Ftime?= Message-ID: erlang craches after using file:change_time("file.txt",{date(),time()},{undefined,undefined}). From iostres@REDACTED Thu Oct 27 18:14:35 2011 From: iostres@REDACTED (Ivan Ostres) Date: Thu, 27 Oct 2011 18:14:35 +0200 Subject: [erlang-bugs] Mac OSX Snow Leopard - configure sets arch to be i386 when running 64bit kernel In-Reply-To: References: Message-ID: Hi all! On Snow Leopard running 64bit kernel, configure set's architecture to be i386: [ivan]/opt/otp_src_R14B04 > uname -a Darwin MacBook-Pro.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_X86_64 x86_64 [ivan]/opt/otp_src_R14B04 > ./configure checking build system type... i386-apple-darwin10.8.0 checking host system type... i386-apple-darwin10.8.0 This is definitely wrong. The problem might be this: [ivan]/opt/otp_src_R14B04 > uname -p i386 [ivan]/opt/otp_src_R14B04 > uname -m x86_64 Please advise, Ivan From jared@REDACTED Thu Oct 27 18:21:23 2011 From: jared@REDACTED (Jared Morrow) Date: Thu, 27 Oct 2011 10:21:23 -0600 Subject: [erlang-bugs] Mac OSX Snow Leopard - configure sets arch to be i386 when running 64bit kernel In-Reply-To: References: Message-ID: Erlang can be built for 32bit or 64bit on a 64bit OSX machine. It defaults to 32bit as you found. Simply pass '--enable-darwin-64bit' to the './configure' line and that will build it for 64bit. This is similar for all other BSD's and Solaris/OpenSolaris OS's I've tried, you must force the 64bit build. -Jared On Thu, Oct 27, 2011 at 10:14 AM, Ivan Ostres wrote: > Hi all! > > On Snow Leopard running 64bit kernel, configure set's architecture to be > i386: > > [ivan]/opt/otp_src_R14B04 > uname -a > Darwin MacBook-Pro.local 10.8.0 Darwin Kernel Version 10.8.0: Tue Jun 7 > 16:32:41 PDT 2011; root:xnu-1504.15.3~1/RELEASE_**X86_64 x86_64 > > [ivan]/opt/otp_src_R14B04 > ./configure > checking build system type... i386-apple-darwin10.8.0 > checking host system type... i386-apple-darwin10.8.0 > > This is definitely wrong. The problem might be this: > > [ivan]/opt/otp_src_R14B04 > uname -p > i386 > [ivan]/opt/otp_src_R14B04 > uname -m > x86_64 > > Please advise, > Ivan > ______________________________**_________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/**listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jared.flatow@REDACTED Thu Oct 27 18:43:47 2011 From: jared.flatow@REDACTED (jared.flatow@REDACTED) Date: Thu, 27 Oct 2011 16:43:47 +0000 Subject: [erlang-bugs] httpc messing with headers In-Reply-To: References: Message-ID: <0E860D5B-7762-47EE-B728-EC73E496A242@nokia.com> We are having the exact same issue currently. At first I was using ibrowse, due to Google saying that httpc is basically unusable, but found that ibrowse had even more serious issues with process leaks. After switching to httpc, things work much better, except for this issue (its not a showstopper since we anyway retry errors), and a memory leak that I can't track down. I'm wondering now though if this might actually be related to the memory leak? jared On Oct 27, 2011, at 7:14 AM, ext eurekafag wrote: > I wrote a simple multiprocess gallery downloader on Erlang: > http://pastebin.com/bY3cVceH It implements workers pool which get jobs > and save files using httpc:request. If I run 10 or more processes > after some files downloaded I'm getting errors like this: > > ** Reason for termination == > ** {bad_return_value,{error,{invalid_version,"Ranges:"}}} > > The string may be anything else but it always looks like a part of > HTTP header. Sometimes it's a today date, just an empty string [], a > block of data or even "st-modified:" ("Last-modified:" header part). > The easiest way to get a bunch of those errors is to start main/1 like > this: > > galdl:main(["http://ru.fishki.net/picsw/042011/13/bonus/kostumi/~3..0w.jpg", > "1", "160", "10"]). > > Arguments are strings for starting the program with erl -run. First > 20-30 pictures are downloaded ok but then errors come up. I tried > limiting keep-alive, sessions and pipelining to no avail. Looking > tcpdump reports I've found that headers of those files are in the > middle of packet not in the beginning. That's why I think it's > something wrong with persistent connections handling. Googling > revealed almost nothing (a couple of reports in 2009 and a patch which > I already have in R14B03 and an advice to use ibrowse). > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs From eurekafag@REDACTED Thu Oct 27 19:37:51 2011 From: eurekafag@REDACTED (eurekafag) Date: Thu, 27 Oct 2011 21:37:51 +0400 Subject: [erlang-bugs] httpc messing with headers In-Reply-To: <0E860D5B-7762-47EE-B728-EC73E496A242@nokia.com> References: <0E860D5B-7762-47EE-B728-EC73E496A242@nokia.com> Message-ID: I'm glad I'm not the only one. However, this issue is reproduced only on my home computer but not on my servers. One of them has much better speed (about 100 Mbit up/down) than me (about 5.5 Mbit) and it downloads everything in a second without a problem. Another server has poor speed (1-2 Mbit) and the program also works fine there. I tried R14A which is on those servers but that changed nothing. Also, I used compiled .beam there so it's not a compiler problem, maybe some race condition as others mentioned. I suggest using tcpdump to narrow the problem down and find the request which leads to the failure. For now I have one case (reusing the connection with HTTP response header placed in the middle of TCP packet) maybe you'll find any other. Just for completeness sake here's the full error message: http://pastebin.com/tyYTKjZw Regarding Tino's suggestion: well, I think it's better to use standart library if you can. Just because it's standart and it works out of the box. I'm not asking something advanced, just requesting urls and saving the data into files. It's just weird that language made for writing distributed and parallel programs fails processing parallel plain HTTP requests and gets confused with persistent connections. It's ok if the library lacks some functions but not if it glitches 2011/10/27 : > We are having the exact same issue currently. At first I was using ibrowse, due to Google saying that httpc is basically unusable, but found that ibrowse had even more serious issues with process leaks. After switching to httpc, things work much better, except for this issue (its not a showstopper since we anyway retry errors), and a memory leak that I can't track down. I'm wondering now though if this might actually be related to the memory leak? > > jared From jared.flatow@REDACTED Thu Oct 27 20:21:53 2011 From: jared.flatow@REDACTED (jared.flatow@REDACTED) Date: Thu, 27 Oct 2011 18:21:53 +0000 Subject: [erlang-bugs] httpc messing with headers In-Reply-To: <104C7E9D-4CFE-411D-9D87-DC0CA93B1C06@erlang-solutions.com> References: <0E860D5B-7762-47EE-B728-EC73E496A242@nokia.com> <104C7E9D-4CFE-411D-9D87-DC0CA93B1C06@erlang-solutions.com> Message-ID: Hi Tino, Yes I looked at it, but after my experience with ibrowse, and the fact that there is even less documentation for it than httpc, I was a little uncomfortable. Also, its difficult to see who has been using it and maintaining it. I'm trying it out now and it seems to work pretty nicely though. I agree with Eureka it would be good if the version in the std library worked (I know you probably agree). Anyway, lhttpc indeed appears to be a good solution, I'll follow up here if I do run into any issues :) Thanks! jared On Oct 27, 2011, at 10:25 AM, ext Tino Breddin wrote: > Hi Jared, > > I've not come across the error in question. But I'm wondering whether you've looked at using lhttpc [1] instead of ibrowse and httpc, and if so why you chose to not use it. > > Cheers, > Tino > > [1] https://github.com/esl/lhttpc > > On Oct 27, 2011, at 6:43 PM, wrote: > >> We are having the exact same issue currently. At first I was using ibrowse, due to Google saying that httpc is basically unusable, but found that ibrowse had even more serious issues with process leaks. After switching to httpc, things work much better, except for this issue (its not a showstopper since we anyway retry errors), and a memory leak that I can't track down. I'm wondering now though if this might actually be related to the memory leak? >> >> jared >> >> On Oct 27, 2011, at 7:14 AM, ext eurekafag wrote: >> >>> I wrote a simple multiprocess gallery downloader on Erlang: >>> http://pastebin.com/bY3cVceH It implements workers pool which get jobs >>> and save files using httpc:request. If I run 10 or more processes >>> after some files downloaded I'm getting errors like this: >>> >>> ** Reason for termination == >>> ** {bad_return_value,{error,{invalid_version,"Ranges:"}}} >>> >>> The string may be anything else but it always looks like a part of >>> HTTP header. Sometimes it's a today date, just an empty string [], a >>> block of data or even "st-modified:" ("Last-modified:" header part). >>> The easiest way to get a bunch of those errors is to start main/1 like >>> this: >>> >>> galdl:main(["http://ru.fishki.net/picsw/042011/13/bonus/kostumi/~3..0w.jpg", >>> "1", "160", "10"]). >>> >>> Arguments are strings for starting the program with erl -run. First >>> 20-30 pictures are downloaded ok but then errors come up. I tried >>> limiting keep-alive, sessions and pipelining to no avail. Looking >>> tcpdump reports I've found that headers of those files are in the >>> middle of packet not in the beginning. That's why I think it's >>> something wrong with persistent connections handling. Googling >>> revealed almost nothing (a couple of reports in 2009 and a patch which >>> I already have in R14B03 and an advice to use ibrowse). >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs > From spawn.think@REDACTED Thu Oct 27 21:47:02 2011 From: spawn.think@REDACTED (Ahmed Omar) Date: Thu, 27 Oct 2011 21:47:02 +0200 Subject: [erlang-bugs] erlang crashes after file:change_time In-Reply-To: References: Message-ID: Added a fix for that : https://github.com/spawnthink/otp/commit/cbe886c1fdb9db4a639aa911f9c691b4d86ec48b Will submit it to erlang-patches On Thu, Oct 27, 2011 at 5:54 PM, systemio systemio wrote: > erlang craches after using > file:change_time("file.txt",{date(),time()},{undefined,undefined}). > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > -- Best Regards, - Ahmed Omar http://nl.linkedin.com/in/adiaa Follow me on twitter @spawn_think -------------- next part -------------- An HTML attachment was scrubbed... URL: From daimon@REDACTED Fri Oct 28 07:03:56 2011 From: daimon@REDACTED (Masatake Daimon) Date: Fri, 28 Oct 2011 14:03:56 +0900 Subject: [erlang-bugs] Memory leakage regarding enif_alloc_env() and iolists Message-ID: <4EAA37BC.9020708@ymir.co.jp> Hello, I found a memory leakage regarding enif_alloc_env() and iolists. The function enif_inspect_iolist_as_binary() (and sometimes enif_inspect_binary()) allocates a temporary object to be retained by ((ErlNifEnv*)env)->tmp_obj_list. This is OK for ordinary process-dependent environments as such objects will later be deallocated by either erts_post_nif() or post_nif_noproc(). But for process-independent ones allocated by enif_alloc_env(), neither enif_clear_env() nor enif_free_env() calls free_tmp_objs() so temporary objects will never be freed, hence the memory leak. So I attempted to fix the problem by applying the attached patch. The patch seemingly cleared away the leakage but unfortunately it induced the runtime system to randomly crash on the call of enif_free_env(): > Program terminated with signal 11, Segmentation fault. > #0 0x000000000044275a in destroy_carrier (allctr=0x791440, blk=0x2b1776d98030) > at beam/erl_alloc_util.c:636 > 636 beam/erl_alloc_util.c: No such file or directory. > in beam/erl_alloc_util.c > (gdb) bt > #0 0x000000000044275a in destroy_carrier (allctr=0x791440, blk=0x2b1776d98030) > at beam/erl_alloc_util.c:636 > #1 0x0000000000443d67 in erts_alcu_free_thr_spec (type=, > extra=, p=0x2b1776d98038) > at beam/erl_alloc_util.c:2898 > #2 0x000000000051a6cd in enif_free_env (env=0x823c78) at beam/erl_nif.c:145 > << snip >> > #7 0x000000000052b186 in process_main () at beam/beam_emu.c:3321 > #8 0x000000000049d5db in sched_thread_func (vesdp=) > at beam/erl_process.c:3782 > #9 0x000000000059f589 in thr_wrapper (vtwd=) > at pthread/ethread.c:106 > #10 0x00002b1777345143 in start_thread () from /lib64/libpthread.so.0 > #11 0x00002b177761e52d in clone () from /lib64/libc.so.6 > #12 0x0000000000000000 in ?? () The Erlang/OTP version I'm using is R14B04 while I highly suspect that the leakage still remains in the Git repository's master branch. I'd be glad if someone familiar with the internals of beam finds a proper way to fix the problem. Regards, Masatake Daimon -- ?? ?? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-nif-env-memleak.patch URL: From sverker@REDACTED Fri Oct 28 10:37:02 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Fri, 28 Oct 2011 10:37:02 +0200 Subject: [erlang-bugs] Memory leakage regarding enif_alloc_env() and iolists In-Reply-To: <4EAA37BC.9020708@ymir.co.jp> References: <4EAA37BC.9020708@ymir.co.jp> Message-ID: <4EAA69AE.7080308@erix.ericsson.se> Yes, you are right. The enif_inspect_io_list_as_binary() does not work well with process independent environments. The same goes for enif_inspect_binary(), but only if the input binary is not byte aligned. I quick and dirty fix on top of your patch could be to replace the first four occurrences of ERTS_ALC_T_TMP with ERTS_ALC_T_NIF in erl_nif.c. I'll write a ticket for R15. Thanks for reporting /Sverker, Erlang/OTP Ericsson Masatake Daimon wrote: > Hello, > > I found a memory leakage regarding enif_alloc_env() and iolists. The > function enif_inspect_iolist_as_binary() (and sometimes > enif_inspect_binary()) allocates a temporary object to be retained by > ((ErlNifEnv*)env)->tmp_obj_list. This is OK for ordinary > process-dependent environments as such objects will later be > deallocated by either erts_post_nif() or post_nif_noproc(). But for > process-independent ones allocated by enif_alloc_env(), neither > enif_clear_env() nor enif_free_env() calls free_tmp_objs() so > temporary objects will never be freed, hence the memory leak. > > So I attempted to fix the problem by applying the attached patch. The > patch seemingly cleared away the leakage but unfortunately it induced > the runtime system to randomly crash on the call of enif_free_env(): > >> Program terminated with signal 11, Segmentation fault. >> #0 0x000000000044275a in destroy_carrier (allctr=0x791440, >> blk=0x2b1776d98030) >> at beam/erl_alloc_util.c:636 >> 636 beam/erl_alloc_util.c: No such file or directory. >> in beam/erl_alloc_util.c >> (gdb) bt >> #0 0x000000000044275a in destroy_carrier (allctr=0x791440, >> blk=0x2b1776d98030) >> at beam/erl_alloc_util.c:636 >> #1 0x0000000000443d67 in erts_alcu_free_thr_spec (type=> optimized out>, >> extra=, p=0x2b1776d98038) >> at beam/erl_alloc_util.c:2898 >> #2 0x000000000051a6cd in enif_free_env (env=0x823c78) at >> beam/erl_nif.c:145 >> << snip >> >> #7 0x000000000052b186 in process_main () at beam/beam_emu.c:3321 >> #8 0x000000000049d5db in sched_thread_func (vesdp=> out>) >> at beam/erl_process.c:3782 >> #9 0x000000000059f589 in thr_wrapper (vtwd=) >> at pthread/ethread.c:106 >> #10 0x00002b1777345143 in start_thread () from /lib64/libpthread.so.0 >> #11 0x00002b177761e52d in clone () from /lib64/libc.so.6 >> #12 0x0000000000000000 in ?? () > > The Erlang/OTP version I'm using is R14B04 while I highly suspect that > the leakage still remains in the Git repository's master branch. I'd > be glad if someone familiar with the internals of beam finds a proper > way to fix the problem. > > Regards, > Masatake Daimon > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From eurekafag@REDACTED Fri Oct 28 16:56:23 2011 From: eurekafag@REDACTED (eurekafag) Date: Fri, 28 Oct 2011 18:56:23 +0400 Subject: [erlang-bugs] httpc messing with headers In-Reply-To: <4EAAAE08.1060806@erix.ericsson.se> References: <0E860D5B-7762-47EE-B728-EC73E496A242@nokia.com> <4EAAAE08.1060806@erix.ericsson.se> Message-ID: Hello, I get 404s, too, and of course it's not what we're talking about. I tried R14B04 and R14B03 (currently I'm on it because it's in Debian testing which I use) with no difference. Fortunately, HTTP/1.0 in http_options "solved" this (worked around actually) and I have no crashes using it. I tried at least two different servers and both of them sent headers in the stream after some data related to the previous file I guess. I mentioned before that this failure occures only on one computer of three I have nearby which is kind of strange. I install OTP from debian repo and now I have no 3rd-party libraries. Maybe it's something wrong with content length because judging by the output it looks like httpc searches for the header ahead of the real one. I checked saved files and found that header saved in the preceding one in the end of it. So httpc just saves too much. It's not a problem with a non-persistent connection but if it is then httpc just lose the stream and parses garbage (the body of the file instead of the header) or the header but from the wrong line. This funny guy contains the bug (in the end of the file there's a header for the next file which hapenned to be 092.jpg in my case) http://eureka7.ru/tmp/087.jpg Maybe this will help a little. 2011/10/28 Micael Karlberg : > Hi, > > Never seen this before. > I tried your test-program, but encountered no crashes > (we are behind a proxy, which might effect the test). > I got some 404s, but I assume that is not what you are > looking for. > > I assume you are using the latest version of OTP (R14B04)? > > Either the server sends us crap or we have a problem with > our chunked decoding (that's the only case a server should > send headers "in" a body). > > Try using version HTTP/1.0 instead (of 1.1). In that case > the server MUST NOT use transfer codings. > > Also we did find the bug causing the unexpected crash, the > decode problem should not cause *this* crash. Instead the > handler process should perform a controlled stop (it was > an un-catched throw that got all the way to the gen_server). > Here is a diff for that problem: > > diff --git a/lib/inets/src/http_client/httpc_handler.erl > b/lib/inets/src/http_client/httpc_handler.erl > index 587e24c..bb3b5bd 100644 > --- a/lib/inets/src/http_client/httpc_handler.erl > +++ b/lib/inets/src/http_client/httpc_handler.erl > @@ -507,8 +507,14 @@ handle_info({Proto, _Socket, Data}, > ? ? ? ? ? ? ? ?ClientErrMsg = httpc_response:error(Request, ClientReason), > ? ? ? ? ? ? ? ?NewState ? ? = answer_request(Request, ClientErrMsg, State), > ? ? ? ? ? ? ? ?{stop, normal, NewState}; > - ? ? ? ? ? error:_Error -> > - ? ? ? ? ? ? ? ?hcrd("data processing error", [{error, _Error}]), > + ? ? ? ? ? ? throw:Error -> > + ? ? ? ? ? ? ? ?hcrd("data processing error", [{throw, Error}]), > + ? ? ? ? ? ? ? ClientReason = {could_not_parse_as_http, Data}, > + ? ? ? ? ? ? ? ClientErrMsg = httpc_response:error(Request, ClientReason), > + ? ? ? ? ? ? ? NewState ? ? = answer_request(Request, ClientErrMsg, State), > + ? ? ? ? ? ? ? {stop, normal, NewState}; > + ? ? ? ? ? ? error:Error -> > + ? ? ? ? ? ? ? ?hcrd("data processing error", [{error, Error}]), > ? ? ? ? ? ? ? ?ClientReason = {could_not_parse_as_http, Data}, > ? ? ? ? ? ? ? ?ClientErrMsg = httpc_response:error(Request, ClientReason), > ? ? ? ? ? ? ? ?NewState ? ? = answer_request(Request, ClientErrMsg, State), > > > /Regards, > ? ? ? ?/BMK > From jonas.boberg@REDACTED Fri Oct 28 19:08:11 2011 From: jonas.boberg@REDACTED (Jonas Boberg) Date: Fri, 28 Oct 2011 19:08:11 +0200 Subject: [erlang-bugs] ets deadlock only with write_concurrency? Message-ID: Hi, >From the release notes for R14B04: --- OTP-9423 Fix emulator deadlock in ets:delete on tables with write_concurrency caused by race with concurrent process that tries to do other operation on the same table. Does not apply to ordered_set. Bug exist since R14B. --- Is there any remote possibility that this issue could affect tables without the 'write_concurrency' option set to true? We are experiencing something that looks like an ets deadlock with R14B03, but we don't have any tables with write_concurrency, only read_concurrency. Regards Jonas From smith.winston.101@REDACTED Mon Oct 31 00:43:51 2011 From: smith.winston.101@REDACTED (Winston Smith) Date: Sun, 30 Oct 2011 19:43:51 -0400 Subject: [erlang-bugs] Mac OSX Snow Leopard - configure sets arch to be i386 when running 64bit kernel In-Reply-To: References: Message-ID: On Thu, Oct 27, 2011 at 12:14 PM, Ivan Ostres wrote: > On Snow Leopard running 64bit kernel, configure set's architecture to be > i386: FYI: It does the same on OS X Lion which always has a 64-bit kernel (I believe you now need a Core 2 Duo or better for Lion). You can still compile 32-bit apps, but not by default. $ uname -a Darwin themac.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug 9 20:54:00 PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64 $ uname -m x86_64 $ uname -p i386 From sverker@REDACTED Mon Oct 31 12:05:01 2011 From: sverker@REDACTED (Sverker Eriksson) Date: Mon, 31 Oct 2011 12:05:01 +0100 Subject: [erlang-bugs] ets deadlock only with write_concurrency? In-Reply-To: References: Message-ID: <4EAE80DD.8020903@erix.ericsson.se> Jonas Boberg wrote: > Hi, > > >From the release notes for R14B04: > --- > OTP-9423 Fix emulator deadlock in ets:delete on tables with write_concurrency > caused by race with concurrent process that tries to do > other operation on the same table. Does not apply to ordered_set. > Bug exist since R14B. > --- > Is there any remote possibility that this issue could affect tables > without the 'write_concurrency' option set to true? > We are experiencing something that looks like an ets deadlock with > R14B03, but we don't have any tables with write_concurrency, only > read_concurrency. Not any known "remote possibility". No. The bug as we saw and understood it needed write_concurrency to trigger. /Sverker, Erlang/OTP