From gunilla@REDACTED Fri Mar 2 09:08:17 2007 From: gunilla@REDACTED (Gunilla Arendt) Date: Fri, 02 Mar 2007 09:08:17 +0100 Subject: [erlang-bugs] http client bug while getting zero-length response In-Reply-To: <87vehnbr0n.fsf@yandex-team.ru> References: <87vehnbr0n.fsf@yandex-team.ru> Message-ID: <45E7DB71.6010907@erix.ericsson.se> Thanks for the bug report. We'll take a look at it as soon as possible. Regards, Gunilla, Erlang/OTP team Igor Goryachev wrote: > Hello everyone. > > I've just found a bug in inets http-client (or somewhere in chunk decode > routines). It is reproduced when a remote http-server sends zero-length > response: > > > goryachev@REDACTED:~% erl > Erlang (BEAM) emulator version 5.5.3 [source] [async-threads:0] [hipe] [kernel-poll:false] > > Eshell V5.5.3 (abort with ^G) > 1> http:request(get, {"http://www.goryachev.org/", []}, [], []). > > =INFO REPORT==== 27-Feb-2007::17:04:20 === > The inets application was not started. Has now been started as a temporary application. > {error,session_remotly_closed} > 2> > =ERROR REPORT==== 27-Feb-2007::17:05:36 === > ** Generic server <0.41.0> terminating > ** Last message in was {tcp_closed,#Port<0.114>} > ** When Server state == {state, > {request, > #Ref<0.0.0.68>, > <0.29.0>, > 0, > http, > {"www.goryachev.org",80}, > "/", > [], > get, > {http_request_h, > undefined, > "keep-alive", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > "www.goryachev.org", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > [], > undefined, > undefined, > undefined, > undefined, > "0", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > []}, > {[],[]}, > {http_options,infinity,true,[],undefined,false}, > "http://www.goryachev.org/", > [], > none, > []}, > {tcp_session, > {{"www.goryachev.org",80},<0.41.0>}, > false, > http, > #Port<0.114>, > 1}, > {"HTTP/1.1",200,"OK"}, > {http_response_h, > undefined, > "keep-alive", > "Tue, 27 Feb 2007 14:03:13 GMT", > undefined, > undefined, > "chunked", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > "nginx/0.5.11", > "Accept-Encoding, Cookie", > undefined, > undefined, > undefined, > undefined, > "-1", > undefined, > undefined, > undefined, > "text/html; charset=utf-8", > undefined, > undefined, > []}, > undefined, > {http_chunk, > decode_data, > [0, > <<"\r\n">>, > {nolimit, > <<>>, > 0, > nolimit, > {200, > {request, > #Ref<0.0.0.68>, > <0.29.0>, > 0, > http, > {"www.goryachev.org",80}, > "/", > [], > get, > {http_request_h, > undefined, > "keep-alive", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > "www.goryachev.org", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > [], > undefined, > undefined, > undefined, > undefined, > "0", > undefined, > undefined, > undefined, > undefined, > undefined, > undefined, > []}, > {[],[]}, > {http_options,infinity,true,[],undefined,false}, > "http://www.goryachev.org/", > [], > none, > []}}}]}, > {[],[]}, > new, > [], > nolimit, > nolimit, > {options,{undefined,[]},0,2,2,disabled,enabled,false}, > {timers,[],undefined}} > ** Reason for termination == > ** session_remotly_closed > > > This behaviour could be worked around using timeout param (i.e. {timeout, 10000}). > > > From gunilla@REDACTED Tue Mar 6 11:28:17 2007 From: gunilla@REDACTED (Gunilla Arendt) Date: Tue, 06 Mar 2007 11:28:17 +0100 Subject: [erlang-bugs] http client bug while getting zero-length response In-Reply-To: <87vehnbr0n.fsf@yandex-team.ru> References: <87vehnbr0n.fsf@yandex-team.ru> Message-ID: <45ED4241.9010409@erix.ericsson.se> This bug has now been fixed in the coming version of Inets, 4.7.11. Regards, Gunilla, Erlang/OTP team Igor Goryachev wrote: > Hello everyone. > > I've just found a bug in inets http-client (or somewhere in chunk decode > routines). It is reproduced when a remote http-server sends zero-length > response: > > From goryachev@REDACTED Tue Mar 6 11:53:01 2007 From: goryachev@REDACTED (Igor Goryachev) Date: Tue, 06 Mar 2007 13:53:01 +0300 Subject: [erlang-bugs] http client bug while getting zero-length response In-Reply-To: <45ED4241.9010409@erix.ericsson.se> (Gunilla Arendt's message of "Tue\, 06 Mar 2007 11\:28\:17 +0100") References: <87vehnbr0n.fsf@yandex-team.ru> <45ED4241.9010409@erix.ericsson.se> Message-ID: <87wt1u1w4y.fsf@yandex-team.ru> Gunilla Arendt writes: > This bug has now been fixed in the coming version of Inets, 4.7.11. Thanks a lot. -- Igor Goryachev Yandex development team. From gunilla@REDACTED Mon Mar 19 14:03:14 2007 From: gunilla@REDACTED (Gunilla Arendt) Date: Mon, 19 Mar 2007 14:03:14 +0100 Subject: [erlang-bugs] efficiency guide In-Reply-To: References: Message-ID: <45FE8A12.6020001@erix.ericsson.se> Thanks, Ulf. I guess that dirty_write was the cheapest operation at the time when the Efficiency Guide was written. Unfortunately, we have a hard time keeping all of the system documentation up-to-date. I changed the text to "Even the Mnesia dirty_write_operations...". Regards, Gunilla, Erlang/OTP team Ulf Wiger wrote: > In the Efficiency Guide, > > http://www.erlang.org/doc/doc-5.5.3/doc/efficiency_guide/tablesDatabases.html#4.1.4 > > it says: > > "Even the cheapest Mnesia operations, dirty_write operations," > > Dirty_write operations are not the cheapest Mnesia operations. > > > For example, > > mnesia:activity(ets, fun() -> mnesia:write(Obj) end) > > is significantly cheaper than > > mnesia:dirty_write(Obj) > > (and also semantically different, of course...) > > > BR, > Ulf W From christopher.faulet@REDACTED Thu Mar 29 23:21:48 2007 From: christopher.faulet@REDACTED (Christopher Faulet) Date: Thu, 29 Mar 2007 23:21:48 +0200 Subject: [erlang-bugs] [erlang-questions] Residual indexes with mnesia In-Reply-To: <45F92488.1080907@meetic-corp.com> References: <45F92488.1080907@meetic-corp.com> Message-ID: <460C2DEC.1030902@capflam.org> Salazard R?my a ?crit : > I have a problem with a mnesia table of type 'bag' with indexed fields. > > When I'm using mnesia:dirty_delete_object/2, sometimes the indexes are > removed and sometimes not :( [...] > > Do I make a mistake or is it a bug? Hi, IMHO, this is a bug and a leak. Firstly, I will explain shortly the format of indexes tables. I hope there are no mistakes in my explanation. For mnesia table, built with the record #mytbl{one, two, three}, the element identified by 'one' is the implicit key. We can add extra indexes on this table (For example, we can add an index on the element identified by 'two'). When we do that, a table per index is created. It will contain fields with the following syntax: {index, key} We are going to use the following example to illustrate our purpose: We insert {mytbl, key_1, index_1, data1} (1) {mytbl, key_1, index_2, data2} (2) {mytbl, key_1, index_2, data3} (3) {mytbl, key_2, index_1, data4} (4) in the mnesia table named 'mytbl', defined from the record #mytbl{one, two, three} and with an index on second element. The associated indexes table will be: {index_1, key_1} -> associated with record (1) {index_2, key_1} -> associated with records (2) and (3) {index_1, key_2} -> associated with record (4) Now, when we remove a record, we must remove these associated indexes too. But, with a table of type 'bag', we can have multiple records with the same pair {index, key} (in our example, {index_2, key_1} is shared by records (2) and (3)). So, to remove an index, we must be sure that there is no other records that use the same pair {index, key}. In our example, if we remove the record (1) or (4), we also implicitly remove the associated index, i.e, respectively, {index_1, key_1} or {index_1, key_2}. But, if we remove the record (2), the record (3) still uses the pair {index_2, key_1}. So this index must not be removed immediately. It will be removed only with the record (3). From this point, we can try to explain the suspected bug. In the file mnesia_index.erl which deals with indexes, we can find the following code: [...] 1 |del_object_bag(Tab, Key, Obj, Pos, Ixt, undefined) -> 2 | Old = mnesia_lib:db_get(Tab, Key), 3 | del_object_bag(Tab, Key, Obj, Pos, Ixt, Old); 4 |%% If Tab type is bag we need remove index identifier if Tab 5 |%% contains less than 2 elements. 6 |del_object_bag(_Tab, Key, Obj, Pos, Ixt, Old) when length(Old) < 2 -> 7 | del_ixes(Ixt, [Obj], Pos, Key); 8 |del_object_bag(_Tab, _Key, _Obj, _Pos, _Ixt, _Old) -> ok. [...] Currently, to remove an index, a request is performed in the mnesia table with the record key (line 2). If there are more than one result (guard on line 6), we suppose that there is another record(s) that shares the same index and we do not remove it (line 8). Else, we try to remove it (line 7). Come back on our example to understand what it happens. If we remove the record (4), the associated index (identified by {index_1, key_2}) is removed, because there is no other records with the same key. all is ok. Nevertheless, if we remove the record (1), the associated index (identified by {index_1, key_1}) is not removed, because there is other records with the same key (records (2) and (3)). Once the record (1) removed, there is no more opportunity to remove the pair {index_1, key_1}. IMHO, there is a bug here. We must refine the selection. We must only keep records with the same key *AND* the same index. the line 2 returns all records with the key of the one we want to remove. But, it seems likely there are records with different indexes. To fix this bug, we can replace the line 2 by these two lines: IxKey = element(Pos, Obj), Old = [X || X <- mnesia_lib:db_get(Tab, Key), element(Pos, X) =:= IxKey], It slows down the deletion of indexes and, maybe, it exists faster solutions (perhaps with some mnesia internal facilities). But this hack works. I made a patch that seems to work with the releases from R10B9 to R11B4. Regards, -- Christopher Faulet http://www.capflam.org -------------- next part -------------- A non-text attachment was scrubbed... Name: mnesia_index.patch Type: text/x-patch Size: 582 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 252 bytes Desc: OpenPGP digital signature URL: From ayrnieu@REDACTED Fri Mar 30 02:22:19 2007 From: ayrnieu@REDACTED (Julian Fondren) Date: Fri, 30 Mar 2007 09:22:19 +0900 Subject: [erlang-bugs] R11B-4 'gmake install' fails under OpenBSD 4.0/Zaurus Message-ID: === Leaving application dialyzer gmake[1]: Leaving directory `/mnt/250/jul/erlang/otp_src_R11B-4/lib/dialyzer' cd /usr/local/lib/erlang && ./Install -minimal /usr/local/lib/erlang Formatting manual pages (this may take a while...) gmake: *** [install.Install] Error 127 This fails for two reasons: case $SYS:$REL in SunOS:5.*) TARGET=sunos5 ;; Linux:*) TARGET=linux ;; - OpenBSD:3.*) + OpenBSD:3.*|OpenBSD:4.*) TARGET=openbsd ;; *) TARGET="" ;; esac and: it seems that this machine doesn't have catman -- that may be a 4.0 issue, or possibly a OpenBSD-on-zaurus issue. Anyway, 'make -n install' tells me that only one step happens after this one, so I got R11B-4 installed anyway. Cheers, Julian