From matthew@REDACTED Sat Mar 1 23:21:40 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sat, 1 Mar 2008 14:21:40 -0800 Subject: [erlang-bugs] calling anonymous function via rpc:call In-Reply-To: <1204291953.13997.15.camel@localhost> References: <1204291953.13997.15.camel@localhost> Message-ID: This is by design. Invoking a fun depends on the module that defines it to be loaded into the runtime. If you load your rem_fun module on axd301@REDACTED, your rpc:call should work. When you write "fun() -> ok end" at the shell, the resulting fun is actually a bit of code from erl_eval that continues with the evaluation, and erl_eval is already available by default. From matthew@REDACTED Mon Mar 3 03:30:38 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Sun, 2 Mar 2008 18:30:38 -0800 Subject: [erlang-bugs] Unix spawn driver does not close all file descriptors in child process Message-ID: In erts/emulator/sys/unix/sys.c, spawn_start() only closes file descriptors up to max_files-1, but there may be file descriptors open greater than that. E.g., on OS X 10.5 (checkfds.c is listed below): 1> [file:open("/dev/null", [read]) || _ <- lists:seq(1, 1016)], ok. ok 2> Port = erlang:open_port({spawn, "./checkfds"}, [stream, in]). #Port<0.4184> 3> receive {Port, {data, Data}} -> Data after 100 -> timeout end. "0 1 2 1024 \n" Erlang caps max_files to 1024 on unix systems where poll is unavailable/broken (e.g., OS X) even when the file descriptor limit is higher. Also, in spawn_start, Erlang doesn't verify that pipe file descriptors that will be closed in the parent process (e.g., ifd[1] and ofd[0]) are less than max_files. As a consequence, when nearly all 1024 file descriptors are in use, some files might leak into the child process. I think instead spawn_start() should try closing all file descriptors up to sysconf(_SC_OPEN_MAX). checkfds.c: #include #include #include int main() { int i, max; max = sysconf(_SC_OPEN_MAX); if (max == -1) max = 8192; /* XXX */ for (i = 0; i < 8192; ++i) if (fcntl(i, F_GETFD) != -1) printf("%d ", i); printf("\n"); return 0; } From bengt.kleberg@REDACTED Mon Mar 3 08:44:07 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 03 Mar 2008 08:44:07 +0100 Subject: [erlang-bugs] Unix spawn driver does not close all file descriptors in child process In-Reply-To: References: Message-ID: <1204530247.24311.23.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, The problem with closing open file descriptors gets its own subchapter in "Advanced programming in the UNIX environment". Richard Steven notes that _SC_OPEN_MAX is allowed by POSIX to be indeterminate (no upper limit). He has an open_max() that tries its best to find the real limit (this includes checking _SC_OPEN_MAX). I like the inline comment about SVR4 and BSD4.3 both having functions that will return this limit, but these are not portable. Does Erlang run on a unix that is neither SVR4 nor BSD4.3 based? bengt On Sun, 2008-03-02 at 18:30 -0800, Matthew Dempsky wrote: > In erts/emulator/sys/unix/sys.c, spawn_start() only closes file > descriptors up to max_files-1, but there may be file descriptors open > greater than that. > > E.g., on OS X 10.5 (checkfds.c is listed below): > > 1> [file:open("/dev/null", [read]) || _ <- lists:seq(1, 1016)], ok. > ok > 2> Port = erlang:open_port({spawn, "./checkfds"}, [stream, in]). > #Port<0.4184> > 3> receive {Port, {data, Data}} -> Data after 100 -> timeout end. > "0 1 2 1024 \n" > > Erlang caps max_files to 1024 on unix systems where poll is > unavailable/broken (e.g., OS X) even when the file descriptor limit is > higher. Also, in spawn_start, Erlang doesn't verify that pipe file > descriptors that will be closed in the parent process (e.g., ifd[1] > and ofd[0]) are less than max_files. As a consequence, when nearly > all 1024 file descriptors are in use, some files might leak into the > child process. > > I think instead spawn_start() should try closing all file descriptors > up to sysconf(_SC_OPEN_MAX). > > > checkfds.c: > #include > #include > #include > > int main() > { > int i, max; > > max = sysconf(_SC_OPEN_MAX); > if (max == -1) max = 8192; /* XXX */ > > for (i = 0; i < 8192; ++i) > if (fcntl(i, F_GETFD) != -1) > printf("%d ", i); > printf("\n"); > > return 0; > } > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From john.hughes@REDACTED Tue Mar 4 15:10:52 2008 From: john.hughes@REDACTED (John Hughes) Date: Tue, 4 Mar 2008 15:10:52 +0100 Subject: [erlang-bugs] Bug in file I/O under Windows. Message-ID: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> This bug manifests as follows: Suppose FileName is the name of an existing file to which we have access. file:delete(FileName) returns ok file:write_file(FileName,Bin) returns {error,eacces} This ought not to happen, because we do have access to the file. The documentation says eacces means "Missing permission for writing the file or searching one of the parent directories", but neither of these is the case-and indeed, if we repeat the same test, then it will almost always succeed as it should. Unfortunately, this bug is rare and very hard to reproduce, so I can't include instructions for doing so. I found the problem by running random sequences of file:write_file and file:delete commands, operating on a small set of filenames. I tried to get repeatable tests by running each test in a newly created directory, on a newly spawned Erlang node, and after a timer:sleep-but even so, I found that a sequence which failed once could very well go on to succeed the next 100 times I tried it. However, I have been able to collect about 40 examples of the bug using QuickCheck. All of them take the form above; they range in length from 4 commands to over 2,000. There are sometimes operations on other files between the delete and the write_file that fails, but never further operations on FileName itself. I've observed this behaviour under R11B and R12B, under both Windows XP and Vista. It doesn't appear to happen at all under Linux. John Hughes -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.kargapolov@REDACTED Tue Mar 4 15:49:58 2008 From: dmitry.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Tue, 04 Mar 2008 09:49:58 -0500 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> Message-ID: <47CD6196.2090308@corp.idt.net> In your Windows environment do you have any antivirus online monitoring s/w? Thanks. John Hughes wrote: > This bug manifests as follows: > > > > Suppose FileName is the name of an existing file to which we have access. > > > > file:delete(FileName) > returns ok > > > file:write_file(FileName,Bin) returns > {error,eacces} > > > > This ought not to happen, because we do have access to the file. The > documentation says eacces means ?Missing permission for writing the file > or searching one of the parent directories?, but neither of these is the > case?and indeed, if we repeat the same test, then it will almost always > succeed as it should. > > > > Unfortunately, this bug is rare and very hard to reproduce, so I can?t > include instructions for doing so. I found the problem by running random > sequences of file:write_file and file:delete commands, operating on a > small set of filenames. I tried to get repeatable tests by running each > test in a newly created directory, on a newly spawned Erlang node, and > after a timer:sleep?but even so, I found that a sequence which failed > once could very well go on to succeed the next 100 times I tried it. > However, I have been able to collect about 40 examples of the bug using > QuickCheck. All of them take the form above; they range in length from 4 > commands to over 2,000. There are sometimes operations on other files > between the delete and the write_file that fails, but never further > operations on FileName itself. > > > > I?ve observed this behaviour under R11B and R12B, under both Windows XP > and Vista. It doesn?t appear to happen at all under Linux. > > > > John Hughes > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From john.hughes@REDACTED Tue Mar 4 16:22:06 2008 From: john.hughes@REDACTED (John Hughes) Date: Tue, 4 Mar 2008 16:22:06 +0100 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <47CD6196.2090308@corp.idt.net> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> <47CD6196.2090308@corp.idt.net> Message-ID: <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> Yes I do--Norton 360 under XP and McAfee under Vista. Could that be the culprit? John -----Ursprungligt meddelande----- Fr?n: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] Skickat: den 4 mars 2008 15:50 Till: John Hughes Kopia: erlang-bugs@REDACTED ?mne: Re: [erlang-bugs] Bug in file I/O under Windows. In your Windows environment do you have any antivirus online monitoring s/w? Thanks. John Hughes wrote: > This bug manifests as follows: > > > > Suppose FileName is the name of an existing file to which we have access. > > > > file:delete(FileName) > returns ok > > > file:write_file(FileName,Bin) returns > {error,eacces} > > > > This ought not to happen, because we do have access to the file. The > documentation says eacces means ?Missing permission for writing the file > or searching one of the parent directories?, but neither of these is the > case?and indeed, if we repeat the same test, then it will almost always > succeed as it should. > > > > Unfortunately, this bug is rare and very hard to reproduce, so I can?t > include instructions for doing so. I found the problem by running random > sequences of file:write_file and file:delete commands, operating on a > small set of filenames. I tried to get repeatable tests by running each > test in a newly created directory, on a newly spawned Erlang node, and > after a timer:sleep?but even so, I found that a sequence which failed > once could very well go on to succeed the next 100 times I tried it. > However, I have been able to collect about 40 examples of the bug using > QuickCheck. All of them take the form above; they range in length from 4 > commands to over 2,000. There are sometimes operations on other files > between the delete and the write_file that fails, but never further > operations on FileName itself. > > > > I?ve observed this behaviour under R11B and R12B, under both Windows XP > and Vista. It doesn?t appear to happen at all under Linux. > > > > John Hughes > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From dmitry.kargapolov@REDACTED Tue Mar 4 17:27:14 2008 From: dmitry.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Tue, 04 Mar 2008 11:27:14 -0500 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> <47CD6196.2090308@corp.idt.net> <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> Message-ID: <47CD7862.8090800@corp.idt.net> Not necessary, but at least McAfee (per my experience) makes original OS quite unstable and unpredictable, so I would recommend to make tests with no antivirus guards running just to exclude one possible reason... Since your result is not well repeatable, I guess some time-outs or race conditions could be there. No other guess at this time. Thanks. John Hughes wrote: > Yes I do--Norton 360 under XP and McAfee under Vista. Could that be the > culprit? > > John > > -----Ursprungligt meddelande----- > Fr?n: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] > Skickat: den 4 mars 2008 15:50 > Till: John Hughes > Kopia: erlang-bugs@REDACTED > ?mne: Re: [erlang-bugs] Bug in file I/O under Windows. > > In your Windows environment do you have any antivirus online monitoring s/w? > Thanks. > > John Hughes wrote: >> This bug manifests as follows: >> >> >> >> Suppose FileName is the name of an existing file to which we have access. >> >> >> >> file:delete(FileName) >> returns ok >> >> >> file:write_file(FileName,Bin) returns >> {error,eacces} >> >> >> >> This ought not to happen, because we do have access to the file. The >> documentation says eacces means ?Missing permission for writing the file >> or searching one of the parent directories?, but neither of these is the >> case?and indeed, if we repeat the same test, then it will almost always >> succeed as it should. >> >> >> >> Unfortunately, this bug is rare and very hard to reproduce, so I can?t >> include instructions for doing so. I found the problem by running random >> sequences of file:write_file and file:delete commands, operating on a >> small set of filenames. I tried to get repeatable tests by running each >> test in a newly created directory, on a newly spawned Erlang node, and >> after a timer:sleep?but even so, I found that a sequence which failed >> once could very well go on to succeed the next 100 times I tried it. >> However, I have been able to collect about 40 examples of the bug using >> QuickCheck. All of them take the form above; they range in length from 4 >> commands to over 2,000. There are sometimes operations on other files >> between the delete and the write_file that fails, but never further >> operations on FileName itself. >> >> >> >> I?ve observed this behaviour under R11B and R12B, under both Windows XP >> and Vista. It doesn?t appear to happen at all under Linux. >> >> >> >> John Hughes >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs > > > From vinod.p@REDACTED Wed Mar 5 07:42:26 2008 From: vinod.p@REDACTED (Vinod Panicker) Date: Wed, 5 Mar 2008 12:12:26 +0530 Subject: [erlang-bugs] Client port limitations on Linux Message-ID: Hi, We're using tsung (http://tsung.erlang-projects.org/) as a load generator to test our application server. During testing we found that tsung was not able to generate over 65k clients, even though it was configured to use multiple ip addresses available to the host machine. On debugging, we found that though tsung was binding to the different ip addresses, it was not reusing a port number across the ip addresses. eg. if it has established a connection to the server using ip address 192.168.66.74 and port 12000, it will not establish another connection using ip address 192.168.66.75 and port 12000. It considers port 12000 to be used. We concluded that the problem was actually in erlang - attaching a test program that uses 2 hard coded ip addresses to connect to a tcp server. They can be run to verify this issue. A simple tcp server will be required to accept the connections. The server and client machines were appropriately configured to handle a large number of connections and erlang processes. Regards, Vinod. -------------- next part -------------- A non-text attachment was scrubbed... Name: connect_socket.erl Type: application/octet-stream Size: 1032 bytes Desc: not available URL: From vladdu55@REDACTED Thu Mar 6 19:55:44 2008 From: vladdu55@REDACTED (Vlad Dumitrescu) Date: Thu, 6 Mar 2008 19:55:44 +0100 Subject: [erlang-bugs] Documentation of io:setopts Message-ID: <95be1d3b0803061055u6a8dba16u99fab1785eb6437f@mail.gmail.com> Hi, There is an error in the documentation for io:setopts/1,2 -- the expand_fun option is mentioned, but I suppose it would have to be {expand_fun, someFun}, not only the expand_fun atom. The function specification omits expand_fun altogether. best regards, Vlad -- Some people see things that are and ask, Why? Some people dream of things that never were and ask, Why not? Some people have to go to work and don't have time for all that. --- George Carlin From john.hughes@REDACTED Sun Mar 9 18:16:03 2008 From: john.hughes@REDACTED (John Hughes) Date: Sun, 9 Mar 2008 18:16:03 +0100 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <47CD7862.8090800@corp.idt.net> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> <47CD6196.2090308@corp.idt.net> <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> <47CD7862.8090800@corp.idt.net> Message-ID: <003501c88209$43240610$c96c1230$@hughes@quviq.com> Couldn't figure out how to turn McAfee off, but I ran the tests on my other machine with Norton 360 disabled--same results. I have found a work-around, however, which consists of simply retrying operations that return {error,eacces} until they succeed. The one exception is file:delete, which can return ok *even though it failed*. In this case the work-around is to keep calling file:delete until it returns {error,enoent}. With these workarounds, at least delete, read_file, write_file, make_dir and del_dir seem to work, even under Vista with McAfee running! I do think it's a bit rummy that file:delete returns ok when it has not actually deleted the file... Weird. John -----Ursprungligt meddelande----- Fr?n: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] Skickat: den 4 mars 2008 17:27 Till: John Hughes Kopia: erlang-bugs@REDACTED ?mne: Re: SV: [erlang-bugs] Bug in file I/O under Windows. Not necessary, but at least McAfee (per my experience) makes original OS quite unstable and unpredictable, so I would recommend to make tests with no antivirus guards running just to exclude one possible reason... Since your result is not well repeatable, I guess some time-outs or race conditions could be there. No other guess at this time. Thanks. John Hughes wrote: > Yes I do--Norton 360 under XP and McAfee under Vista. Could that be the > culprit? > > John > > -----Ursprungligt meddelande----- > Fr?n: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] > Skickat: den 4 mars 2008 15:50 > Till: John Hughes > Kopia: erlang-bugs@REDACTED > ?mne: Re: [erlang-bugs] Bug in file I/O under Windows. > > In your Windows environment do you have any antivirus online monitoring s/w? > Thanks. > > John Hughes wrote: >> This bug manifests as follows: >> >> >> >> Suppose FileName is the name of an existing file to which we have access. >> >> >> >> file:delete(FileName) >> returns ok >> >> >> file:write_file(FileName,Bin) returns >> {error,eacces} >> >> >> >> This ought not to happen, because we do have access to the file. The >> documentation says eacces means ?Missing permission for writing the file >> or searching one of the parent directories?, but neither of these is the >> case?and indeed, if we repeat the same test, then it will almost always >> succeed as it should. >> >> >> >> Unfortunately, this bug is rare and very hard to reproduce, so I can?t >> include instructions for doing so. I found the problem by running random >> sequences of file:write_file and file:delete commands, operating on a >> small set of filenames. I tried to get repeatable tests by running each >> test in a newly created directory, on a newly spawned Erlang node, and >> after a timer:sleep?but even so, I found that a sequence which failed >> once could very well go on to succeed the next 100 times I tried it. >> However, I have been able to collect about 40 examples of the bug using >> QuickCheck. All of them take the form above; they range in length from 4 >> commands to over 2,000. There are sometimes operations on other files >> between the delete and the write_file that fails, but never further >> operations on FileName itself. >> >> >> >> I?ve observed this behaviour under R11B and R12B, under both Windows XP >> and Vista. It doesn?t appear to happen at all under Linux. >> >> >> >> John Hughes >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs > > > From jkposti@REDACTED Mon Mar 10 11:39:53 2008 From: jkposti@REDACTED (Jay) Date: Mon, 10 Mar 2008 21:39:53 +1100 Subject: [erlang-bugs] Packaged modules and qlc has namespace issues Message-ID: Hi there, I have been doing some Erlang programming and everything has been fun so far. However, I have had this one issue for sometime now that is quite annoying. Below is an example code, which describes the problem. -module(some.db.package). get_something() -> F = fun() -> Q = .qlc:q([D || D <- .ets:table(table1), P <- .ets:table(table2), D#table1.id == P#table2.id, D#table2.fielda == 1]), .qlc:e(Q) end, .mnesia:transaction(F). Calling the above function results following error: {aborted, {undef, [{'some.db.lists',reverse, [[{table1,{1,1},"row1"}, {table1,{1,0},"row2"}]]}, {qlc,collect,1}, {qlc,eval,2}, {mnesia_tm,apply_fun,3}, {mnesia_tm,execute_transaction,5}, {'some.db.package',get_something,0}]}}}, ... This looks to me like a carefully placed dot in the qlc package might give the necessary help. Writing ".lists:reverse(A)" instead of "lists:reverse(A)". The workaround to this problem is to have this function in the top level module. Cheers From john.hughes@REDACTED Mon Mar 10 11:54:16 2008 From: john.hughes@REDACTED (John Hughes) Date: Mon, 10 Mar 2008 11:54:16 +0100 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <003701c88209$4353a190$c9fae4b0$@hughes@quviq.com> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> <47CD6196.2090308@corp.idt.net> <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> <47CD7862.8090800@corp.idt.net> <003701c88209$4353a190$c9fae4b0$@hughes@quviq.com> Message-ID: <000601c8829d$173cb530$45b61f90$@hughes@quviq.com> Here's some code to replicate the bug without QuickCheck: -module(bug). -compile(export_all). bug() -> bug(1). bug(N) -> if N rem 1000==0 -> io:format("~p,",[N]); true -> ok end, case catch test() of {'EXIT',Reason} -> io:format("After ~p tests: ~p~n",[N,Reason]); _ -> bug(N+1) end. test() -> ok = file:write_file(bug,<<>>), ok = file:delete(bug), {error,enoent} = file:delete(bug). On my Vista machine, it took about three quarters of a million iterations to provoke a test failure. John -----Ursprungligt meddelande----- Fr?n: John Hughes [mailto:john.hughes@REDACTED] Skickat: den 9 mars 2008 18:16 Till: 'Dmitriy Kargapolov' Kopia: erlang-bugs@REDACTED ?mne: SV: SV: [erlang-bugs] Bug in file I/O under Windows. Couldn't figure out how to turn McAfee off, but I ran the tests on my other machine with Norton 360 disabled--same results. I have found a work-around, however, which consists of simply retrying operations that return {error,eacces} until they succeed. The one exception is file:delete, which can return ok *even though it failed*. In this case the work-around is to keep calling file:delete until it returns {error,enoent}. With these workarounds, at least delete, read_file, write_file, make_dir and del_dir seem to work, even under Vista with McAfee running! I do think it's a bit rummy that file:delete returns ok when it has not actually deleted the file... Weird. John -----Ursprungligt meddelande----- Fr?n: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] Skickat: den 4 mars 2008 17:27 Till: John Hughes Kopia: erlang-bugs@REDACTED ?mne: Re: SV: [erlang-bugs] Bug in file I/O under Windows. Not necessary, but at least McAfee (per my experience) makes original OS quite unstable and unpredictable, so I would recommend to make tests with no antivirus guards running just to exclude one possible reason... Since your result is not well repeatable, I guess some time-outs or race conditions could be there. No other guess at this time. Thanks. John Hughes wrote: > Yes I do--Norton 360 under XP and McAfee under Vista. Could that be the > culprit? > > John > > -----Ursprungligt meddelande----- > Fr?n: Dmitriy Kargapolov [mailto:dmitry.kargapolov@REDACTED] > Skickat: den 4 mars 2008 15:50 > Till: John Hughes > Kopia: erlang-bugs@REDACTED > ?mne: Re: [erlang-bugs] Bug in file I/O under Windows. > > In your Windows environment do you have any antivirus online monitoring s/w? > Thanks. > > John Hughes wrote: >> This bug manifests as follows: >> >> >> >> Suppose FileName is the name of an existing file to which we have access. >> >> >> >> file:delete(FileName) >> returns ok >> >> >> file:write_file(FileName,Bin) returns >> {error,eacces} >> >> >> >> This ought not to happen, because we do have access to the file. The >> documentation says eacces means ?Missing permission for writing the file >> or searching one of the parent directories?, but neither of these is the >> case?and indeed, if we repeat the same test, then it will almost always >> succeed as it should. >> >> >> >> Unfortunately, this bug is rare and very hard to reproduce, so I can?t >> include instructions for doing so. I found the problem by running random >> sequences of file:write_file and file:delete commands, operating on a >> small set of filenames. I tried to get repeatable tests by running each >> test in a newly created directory, on a newly spawned Erlang node, and >> after a timer:sleep?but even so, I found that a sequence which failed >> once could very well go on to succeed the next 100 times I tried it. >> However, I have been able to collect about 40 examples of the bug using >> QuickCheck. All of them take the form above; they range in length from 4 >> commands to over 2,000. There are sometimes operations on other files >> between the delete and the write_file that fails, but never further >> operations on FileName itself. >> >> >> >> I?ve observed this behaviour under R11B and R12B, under both Windows XP >> and Vista. It doesn?t appear to happen at all under Linux. >> >> >> >> John Hughes >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://www.erlang.org/mailman/listinfo/erlang-bugs > > > From richardc@REDACTED Mon Mar 10 12:15:38 2008 From: richardc@REDACTED (Richard Carlsson) Date: Mon, 10 Mar 2008 12:15:38 +0100 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <000601c8829d$173cb530$45b61f90$@hughes@quviq.com> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> <47CD6196.2090308@corp.idt.net> <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> <47CD7862.8090800@corp.idt.net> <003701c88209$4353a190$c9fae4b0$@hughes@quviq.com> <000601c8829d$173cb530$45b61f90$@hughes@quviq.com> Message-ID: <47D5185A.803@it.uu.se> John Hughes wrote: > On my Vista machine, it took about three quarters of a million iterations to > provoke a test failure. The problem might be concurrent access by some other interfering program. I believe (someone correct me if I'm wrong) that under Windows, the default way of opening files for reading is exclusive (yes, even for read-only). This way, programs such as virus checkers and other things that traverse your file system for one reason or another (notably TortoiseSVN), can occasionally happen to prevent you from performing an operation even on a file that you just created and nobody is supposed to know about yet. I'm not 100% sure that this is really what is happening, but it's our best hypothesis so far. We often see spurious failures when unzipping archives with loads of files, or sometimes when checking out big source trees from the repository. Only in Windows(TM). Oh, joy! /Richard PS. What seems to be happening with unzip is this: unzip creates the file and populates it from the archive data, then closes it again. Then, as a separate operation it wants to set the timestamp to whatever it was in the archive. But, meanwhile, some greedy program is already checking out the new file, and we get error reports stating that the date could not be set. Gah! From r.kelsall@REDACTED Mon Mar 10 14:10:38 2008 From: r.kelsall@REDACTED (Richard Kelsall) Date: Mon, 10 Mar 2008 13:10:38 +0000 Subject: [erlang-bugs] Bug in file I/O under Windows. In-Reply-To: <47D5185A.803@it.uu.se> References: <024f01c87e01$8ea23000$abe69000$@hughes@quviq.com> <47CD6196.2090308@corp.idt.net> <03ab01c87e0b$827588e0$87609aa0$@hughes@quviq.com> <47CD7862.8090800@corp.idt.net> <003701c88209$4353a190$c9fae4b0$@hughes@quviq.com> <000601c8829d$173cb530$45b61f90$@hughes@quviq.com> <47D5185A.803@it.uu.se> Message-ID: <47D5334E.3060300@millstream.com> Richard Carlsson wrote: > John Hughes wrote: >> On my Vista machine, it took about three quarters of a million iterations to >> provoke a test failure. > > The problem might be concurrent access by some other interfering program. > I believe (someone correct me if I'm wrong) that under Windows, the default > way of opening files for reading is exclusive (yes, even for read-only). > This way, programs such as virus checkers and other things that traverse > your file system for one reason or another (notably TortoiseSVN), can > occasionally happen to prevent you from performing an operation even on > a file that you just created and nobody is supposed to know about yet. > > I'm not 100% sure that this is really what is happening, but it's our best > hypothesis so far. We often see spurious failures when unzipping archives > with loads of files, or sometimes when checking out big source trees from > the repository. Only in Windows(TM). Oh, joy! > > /Richard > > PS. What seems to be happening with unzip is this: unzip creates the file > and populates it from the archive data, then closes it again. Then, as a > separate operation it wants to set the timestamp to whatever it was in the > archive. But, meanwhile, some greedy program is already checking out the new > file, and we get error reports stating that the date could not be set. Gah! This may not be relevant, but I'll add a bit of information about a file problem I had under Windows in a Delphi program. My problem was a virus checker and I got the impression that John had ruled out virus checkers, but thinking about it, there might be some sort of indexing or backup software running that performs the same kind of file operations as a virus checker. I have roughly edited a couple of old emails about my problem and pasted them below, in case it helps. This was a Delphi program running on Windows. Richard. When the program is installed it does lots of writing to files. A virus checker may attempt to read these files immediately after they are changed to look for viruses. The program may try another write to the files while they are being read by the virus checker and fail with the 'file in use' problem. (We found it could be solved by switching off the virus checker. And it never occurred on my machine without a virus checker.) The relevant error messages were : "The process cannot access the file because it is being used by another process" "File could not be opened. File may be in use by another process" (I can't immediately tell you whether these are Delphi or Windows messages.) The cause of my 'File in use' problem is that a virus checker can attempt to access the database tables while the program is running. (It took an enormous effort to prove this.) The program requires exclusive access to these files and can crash with the 'File in use' problem if these files are accessed simultaneously by a virus checker or similar application. It should be possible to reconfigure the virus checker to ignore the files used by the program, or just run the virus checker periodically rather than continuously. This happens primarily when the program is installed because all the records are loaded into the database at this point. This means a huge number of database updates are performed in quick succession. Nobody has yet reported the problem at other times but I don't see why it shouldn't happen during normal use of the program. However, during normal use database updates are brief and infrequent so even if the problem occurs at the same rate per database update it will almost never happen. My technical guess at what is happening is that a file write operation - in this case a database table change - is triggering the virus checker to scan the newly updated file for viruses. During this scan the program attempts to perform another write and falls in a heap because the virus checker is using the file. It might be possible to modify my database code to 'try again later' if the file is in use. From martin.stein@REDACTED Tue Mar 11 15:27:39 2008 From: martin.stein@REDACTED (Stein, Martin) Date: Tue, 11 Mar 2008 07:27:39 -0700 Subject: [erlang-bugs] Concurrent file access on Windows In-Reply-To: References: Message-ID: There is a tool that shows each file access in Windows available from Sysinternals (File Monitor and Process Monitor). Each file operation is traced. This should show the concurrent accesses. http://technet.microsoft.com/en-us/sysinternals/bb896642.aspx http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx >>>>>>>>>>>> Quote: The problem might be concurrent access by some other interfering program. I believe (someone correct me if I'm wrong) that under Windows, the default way of opening files for reading is exclusive (yes, even for read-only). This way, programs such as virus checkers and other things that traverse your file system for one reason or another (notably TortoiseSVN), can occasionally happen to prevent you from performing an operation even on a file that you just created and nobody is supposed to know about yet. I'm not 100% sure that this is really what is happening, but it's our best hypothesis so far. We often see spurious failures when unzipping archives with loads of files, or sometimes when checking out big source trees from the repository. Only in Windows(TM). Oh, joy! /Richard PS. What seems to be happening with unzip is this: unzip creates the file and populates it from the archive data, then closes it again. Then, as a separate operation it wants to set the timestamp to whatever it was in the archive. But, meanwhile, some greedy program is already checking out the new file, and we get error reports stating that the date could not be set. Gah! From jean-marc.prud-homme@REDACTED Fri Mar 14 22:15:25 2008 From: jean-marc.prud-homme@REDACTED (Jean-Marc Prud Homme) Date: Fri, 14 Mar 2008 17:15:25 -0400 Subject: [erlang-bugs] possible bug with binary pattern matching Message-ID: <0DC69EC36AAA5E4B9727E2CA74037C7B089B6B57@UBIMAIL1.ubisoft.org> Hi, We are experiencing crashes in the VM that seems to be related with binary pattern matching. It was successfully reproduced on Windows XP and Linux Ubuntu 7.10 systems with R12B-0 and R12B-1. The code below was used to reproduce the crash. It needs to be executed several times to produce the crash. Regards, Jean-Marc - - - - - - - - - - - - - - - - %% Run the test 50 times binary_test:run(50). - - - - - - - - - - - - - - - - -module(binary_test). -compile(export_all). run(N) -> T = <<8,1,9,1,0,8,1,9,1,0,8,1,9,1,0>>, F = fun() -> f1(T, {[test]}) end, repeat(N, F), ok. repeat(0, _Fun) -> ok; repeat(N, Fun) -> Fun(), repeat(N-1, Fun). %% 1 f1(R, T) -> f2(R, [T]). %% 2 f2(<>, T) -> f3(R, {T}). %% Never called but helps reproducing the crash f3(<>, a) -> f4(T); f3(<>, b) -> f4(T); f3(<>, c) -> f4(0); %% 3 f3(<>, {T}) -> f3(R, T); %% 4 f3(<>, [_]) -> f4([]); %% Never called but helps reproducing the crash f3(<>, d) -> f4(T). %% 5 f4(T) -> f5({T}). %% 6 f5(T) -> {T}. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Mon Mar 17 09:37:49 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 17 Mar 2008 09:37:49 +0100 Subject: [erlang-bugs] possible bug with binary pattern matching In-Reply-To: <0DC69EC36AAA5E4B9727E2CA74037C7B089B6B57@UBIMAIL1.ubisoft.org> References: <0DC69EC36AAA5E4B9727E2CA74037C7B089B6B57@UBIMAIL1.ubisoft.org> Message-ID: "Jean-Marc Prud Homme" writes: > We are experiencing crashes in the VM that seems to be related with > binary pattern matching. It was successfully reproduced on Windows XP > and Linux Ubuntu 7.10 systems with R12B-0 and R12B-1. The code below > was used to reproduce the crash. It needs to be executed several times > to produce the crash. > The patch in the following mail should correct the bug: http://www.erlang.org/pipermail/erlang-questions/2008-March/033296.html /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From bengt.kleberg@REDACTED Mon Mar 17 09:49:39 2008 From: bengt.kleberg@REDACTED (Bengt Kleberg) Date: Mon, 17 Mar 2008 09:49:39 +0100 Subject: [erlang-bugs] possible bug with binary pattern matching In-Reply-To: <0DC69EC36AAA5E4B9727E2CA74037C7B089B6B57@UBIMAIL1.ubisoft.org> References: <0DC69EC36AAA5E4B9727E2CA74037C7B089B6B57@UBIMAIL1.ubisoft.org> Message-ID: <1205743779.5670.7.camel@seasc0625.dyn.rnd.as.sw.ericsson.se> Greetings, On my machine there crash did _not_ happen. Erlang (BEAM) emulator version 5.5.5.6 [async-threads:0] [kernel-poll:false] Linux seasc0625 2.6.16.53-0.16-bigsmp #1 SMP Tue Oct 2 16:57:49 UTC 2007 i686 athlon i386 GNU/Linux bengt On Fri, 2008-03-14 at 17:15 -0400, Jean-Marc Prud Homme wrote: > Hi, > > > > We are experiencing crashes in the VM that seems to be related with > binary pattern matching. It was successfully reproduced on Windows > XP and Linux Ubuntu 7.10 systems with R12B-0 and R12B-1. The code > below was used to reproduce the crash. It needs to be executed > several times to produce the crash. > > > > > > Regards, > > > > Jean-Marc > > > > > > - - - - - - - - - - - - - - - - > > > > %% Run the test 50 times > > binary_test:run(50). > > > > > > - - - - - - - - - - - - - - - - > > -module(binary_test). > > > > -compile(export_all). > > > > run(N) -> > > > > T = <<8,1,9,1,0,8,1,9,1,0,8,1,9,1,0>>, > > > > F = fun() -> f1(T, {[test]}) end, > > > > repeat(N, F), > > > > ok. > > > > repeat(0, _Fun) -> > > ok; > > > > repeat(N, Fun) -> > > Fun(), > > repeat(N-1, Fun). > > > > > > %% 1 > > f1(R, T) -> > > f2(R, [T]). > > > > %% 2 > > f2(<>, T) -> > > f3(R, {T}). > > > > %% Never called but helps reproducing the crash > > f3(<>, a) -> > > f4(T); > > f3(<>, b) -> > > f4(T); > > f3(<>, c) -> > > f4(0); > > > > %% 3 > > f3(<>, {T}) -> > > f3(R, T); > > > > %% 4 > > f3(<>, [_]) -> > > f4([]); > > > > %% Never called but helps reproducing the crash > > f3(<>, d) -> > > f4(T). > > > > %% 5 > > f4(T) -> > > f5({T}). > > > > %% 6 > > f5(T) -> > > {T}. > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From goryachev@REDACTED Wed Mar 19 14:25:35 2008 From: goryachev@REDACTED (Igor Goryachev) Date: Wed, 19 Mar 2008 16:25:35 +0300 Subject: [erlang-bugs] etop dies with unmatched case_clause error Message-ID: <877ifyu9ps.fsf@yandex-team.ru> Hello. etop sometimes dies with the following output: Output server crashed: {{case_clause,undefined}, [{observer_backend,pi,2}, {observer_backend,'-etop_collect/1-fun-0-',1}, {lists,flatmap,2}, {lists,flatmap,2}, {observer_backend,etop_collect,1}]} There seems to be a missed case clause in pi/2 of observer_backend while process_info can return more values than is handled, from manual page: ``process_info(Pid, Item) -> {Item, Info} | undefined | [])''. The tiny patch is included. -------------- next part -------------- A non-text attachment was scrubbed... Name: observer_backend_unmatched_case_clause_fix.diff Type: text/x-diff Size: 336 bytes Desc: not available URL: -------------- next part -------------- -- Igor Goryachev Yandex development team. From bjorn@REDACTED Wed Mar 19 15:28:41 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 19 Mar 2008 15:28:41 +0100 Subject: [erlang-bugs] etop dies with unmatched case_clause error In-Reply-To: <877ifyu9ps.fsf@yandex-team.ru> References: <877ifyu9ps.fsf@yandex-team.ru> Message-ID: Igor Goryachev writes: > There seems to be a missed case clause in pi/2 of observer_backend while > process_info can return more values than is handled, from manual page: > ``process_info(Pid, Item) -> {Item, Info} | undefined | [])''. The > tiny patch is included. Thanks for pointing this out. We will fix the problem in R12B-2. /Bjorn -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From dougedmunds@REDACTED Wed Mar 19 22:16:05 2008 From: dougedmunds@REDACTED (DougEdmunds) Date: Wed, 19 Mar 2008 14:16:05 -0700 Subject: [erlang-bugs] Documentation error R12B Message-ID: <47E18295.90005@gmail.com> Error in .../Doc/programming_examples/funs.html, section 2.5.5 (foldl) The order of the arguments is wrong. Section 2.5.5 currently says: foldl takes a function of two arguments, an accumulator and a list. The function is called with two arguments. The first argument is the successive elements in the list, the second argument is the accumulator. The function must return a new accumulator which is used the next time the function is called. This paragraph should read: foldl takes a function of two arguments. The function is called with two arguments. The first argument is the accumulator, the second argument is the successive elements in the list. The function must return a new accumulator which is used the next time the function is called. ref: lists:foldl(Fun, Acc0, List) -> Acc1 -dae From kenneth.lundin@REDACTED Thu Mar 20 08:24:05 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Thu, 20 Mar 2008 08:24:05 +0100 Subject: [erlang-bugs] Documentation error R12B In-Reply-To: <47E18295.90005@gmail.com> References: <47E18295.90005@gmail.com> Message-ID: Hi, Sorry but I can't find anything wrong with the doc here: The fun passed as the first argument to lists:foldl indeed takes 2 arguments where the first argument is the successive elements in the list and the second is the accumulator. /Kenneth Erlang/OTP team at Ericsson On 3/19/08, DougEdmunds wrote: > Error in > .../Doc/programming_examples/funs.html, section 2.5.5 (foldl) > > The order of the arguments is wrong. > > Section 2.5.5 currently says: > > > foldl takes a function of two arguments, an accumulator and a list. The > function is called with two arguments. The first argument is the > successive elements in the list, the second argument is the accumulator. > The function must return a new accumulator which is used the next time > the function is called. > > This paragraph should read: > > foldl takes a function of two arguments. The function is called with two > arguments. The first argument is the accumulator, the second argument is > the successive elements in the list. The function must return a new > accumulator which is used the next time the function is called. > > ref: > lists:foldl(Fun, Acc0, List) -> Acc1 > > -dae > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From tobbe@REDACTED Tue Mar 25 11:28:55 2008 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Tue, 25 Mar 2008 11:28:55 +0100 Subject: [erlang-bugs] Bug in QLC ? Message-ID: Hi, (Sorry if this bug-report is coming out twice, I tried to post it via trapexit.org yesterday but seem to have failed...) I've been playing around with my natural DSL engine which generates QLC questions like the one below: [{X1#invoice.invno,X2#person.fname,X2#person.lname} || X1 <- mnesia:table(invoice), X1#invoice.eid == 308, X2 <- mnesia:table(person), X1#invoice.pno == X2#person.pno] It causes qlc to crash: =ERROR REPORT==== 25-Mar-2008::11:19:03 === exit: {function_clause,[{file,check_args,[false]}, {file,open,2}, {qlc,'-sort_cursor_list_output/2-fun-0-',4}, {file_sorter,outfun,2}, {file_sorter,merge_files,5}, {file_sorter,last_merge,2}, {file_sorter,do_sort,5}, {qlc,do_sort,5}]} So perhaps my QLC-question is wrong, or it is a bug in qlc? Running R11B-2 on Linux. The QLC was being run in a dirty context. Cheers, Tobbe (Ps. The DSL query was: for every invoice and person record where eid == 308 and inv_pno == pno return invno, fname and lname as a table ) From klas.johansson@REDACTED Tue Mar 25 12:54:25 2008 From: klas.johansson@REDACTED (Klas Johansson) Date: Tue, 25 Mar 2008 12:54:25 +0100 Subject: [erlang-bugs] Bug in QLC ? In-Reply-To: References: Message-ID: On Tue, Mar 25, 2008 at 11:28 AM, Torbjorn Tornkvist wrote: > Hi, > > (Sorry if this bug-report is coming out twice, I tried to > post it via trapexit.org yesterday but seem to have failed...) > > I've been playing around with my natural DSL engine which generates > QLC questions like the one below: > > [{X1#invoice.invno,X2#person.fname,X2#person.lname} || > X1 <- mnesia:table(invoice), > X1#invoice.eid == 308, > X2 <- mnesia:table(person), > X1#invoice.pno == X2#person.pno] > > It causes qlc to crash: > > =ERROR REPORT==== 25-Mar-2008::11:19:03 === > exit: {function_clause,[{file,check_args,[false]}, > {file,open,2}, > {qlc,'-sort_cursor_list_output/2-fun-0-',4}, > {file_sorter,outfun,2}, > {file_sorter,merge_files,5}, > {file_sorter,last_merge,2}, > {file_sorter,do_sort,5}, > {qlc,do_sort,5}]} > > So perhaps my QLC-question is wrong, or it is a bug in qlc? > > Running R11B-2 on Linux. The QLC was being run in a dirty context. > > Cheers, Tobbe > (Ps. The DSL query was: for every invoice and person record where eid == > 308 and inv_pno == pno return invno, fname and lname as a table ) > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > Hi, I stumbled upon this bug a year ago. It was corrected in stdlib-1.14.4 (which seems to correspond to R11B-4): --- stdlib-1.14.4 ------------------------------------------------------------ [...] OTP-6562 When sorting the operands of a join operation, QLC called file:open/3 with bad arguments. This bug has been fixed. (from http://www.erlang.org/download/otp_src_R11B-4.readme) BR, Klas From hans.bolinder@REDACTED Tue Mar 25 13:17:34 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 25 Mar 2008 13:17:34 +0100 Subject: [erlang-bugs] Bug in QLC ? In-Reply-To: References: Message-ID: <18408.60766.227918.108105@gargle.gargle.HOWL> [Torbjorn Tornkvist:] > (Ps. The DSL query was: for every invoice and person record where eid == > 308 and inv_pno == pno return invno, fname and lname as a table ) Note that currently qlc will not try to look up the key unless you write "eid =:= 308". Similarly, qlc will always do a merge join when columns are compared; lookup join is only considered when columns are matched ("inv_pno =:= pno"). (I assume here that you don't mix integers and floating point numbers is such a way that ==/2 has to be used.). Use qlc:info() to see how qlc will evaluate a query. Best regards, Hans Bolinder, Erlang/OTP team From hans.bolinder@REDACTED Tue Mar 25 13:39:44 2008 From: hans.bolinder@REDACTED (Hans Bolinder) Date: Tue, 25 Mar 2008 13:39:44 +0100 Subject: [erlang-bugs] [Fwd: [erlang-questions] string:join([], Str) fails] In-Reply-To: <47B190AA.9010000@gmail.com> References: <47B190AA.9010000@gmail.com> Message-ID: <18408.62096.978252.550733@gargle.gargle.HOWL> [Serge Aleynikov:] > I noticed that strings:join([], Str) is not handled in the implementation: > > 1> string:join([], ","). > ** exception error: no function clause matching string:join([],",") > > This looks like an oversight, as it's not symmetric to string:tokens/2: > > 2> string:tokens([], ","). > [] Thanks. We will fix it in R12B-2. Best regards, Hans Bolinder, Erlang/OTP team From tobbe@REDACTED Tue Mar 25 13:59:11 2008 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Tue, 25 Mar 2008 13:59:11 +0100 Subject: [erlang-bugs] Bug in QLC ? In-Reply-To: <18408.60766.227918.108105@gargle.gargle.HOWL> References: <18408.60766.227918.108105@gargle.gargle.HOWL> Message-ID: Hans Bolinder wrote: > [Torbjorn Tornkvist:] >> (Ps. The DSL query was: for every invoice and person record where eid == >> 308 and inv_pno == pno return invno, fname and lname as a table ) > > Note that currently qlc will not try to look up the key unless you > write "eid =:= 308". Similarly, qlc will always do a merge join when Thanx a lot for that info! Cheers, Tobbe > columns are compared; lookup join is only considered when columns are > matched ("inv_pno =:= pno"). (I assume here that you don't mix > integers and floating point numbers is such a way that ==/2 has to be > used.). > > Use qlc:info() to see how qlc will evaluate a query. > > Best regards, > > Hans Bolinder, Erlang/OTP team > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From VKlebansky@REDACTED Tue Mar 25 18:36:36 2008 From: VKlebansky@REDACTED (Vladimir Klebansky) Date: Tue, 25 Mar 2008 13:36:36 -0400 Subject: [erlang-bugs] Compiler crash Message-ID: <840D0E3C6DE3904A862484082DC9DC3D02DEE605@SITE3MAIL03.jeeves.ask.info> Hi, Compiler crashes when compiling this small sample program (tst.erl): -module(tst). -compile(export_all). -record(rec, {key, val}). print_rec(Rec) -> <> = Rec#rec.key, case K of <<"XX">> -> Value = Rec#rec.val, case lists:keysearch("xxxxxxxx", 1, Value) of {value, T} -> io:format("{~p, [~p]}~n", [Rec#rec.key, T]); false -> ok end; _ -> ok end. The error message: tst: function print_rec/1+29: Internal consistency check failed - please report this bug. Instruction: {put_list,{y,0},{x,0},{x,1}} Error: {match_context,{y,0}}: Running R12B-1 on Linux and Windows. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fredrikelinder@REDACTED Wed Mar 26 20:30:05 2008 From: fredrikelinder@REDACTED (Fredrik Linder) Date: Wed, 26 Mar 2008 20:30:05 +0100 Subject: [erlang-bugs] lists:suffix/2 Message-ID: <3b513c8d0803261230y76898c33sd77bcf7a73f2977d@mail.gmail.com> * *(node@REDACTED)23> lists:suffix("a", "ala"). true (node@REDACTED)24> lists:suffix("al", "ala"). false (node@REDACTED)25> lists:suffix("ala", "ala"). true Erlang OTP R11B stdlib-1.14.5 -------------- next part -------------- An HTML attachment was scrubbed... URL: From anders.nygren@REDACTED Wed Mar 26 20:53:27 2008 From: anders.nygren@REDACTED (Anders Nygren) Date: Wed, 26 Mar 2008 13:53:27 -0600 Subject: [erlang-bugs] lists:suffix/2 In-Reply-To: <3b513c8d0803261230y76898c33sd77bcf7a73f2977d@mail.gmail.com> References: <3b513c8d0803261230y76898c33sd77bcf7a73f2977d@mail.gmail.com> Message-ID: 2008/3/26 Fredrik Linder : > > > > (node@REDACTED)23> lists:suffix("a", "ala"). > true > (node@REDACTED)24> lists:suffix("al", "ala"). > false > (node@REDACTED)25> lists:suffix("ala", "ala"). > true > > > Erlang OTP R11B > stdlib-1.14.5 > And what is the problem? "ala" does not end with "al" but it ends with "ala" Remember suffix is at the end, prefix is at the beginning. /Anders > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From fredrikelinder@REDACTED Wed Mar 26 20:59:49 2008 From: fredrikelinder@REDACTED (Fredrik Linder) Date: Wed, 26 Mar 2008 20:59:49 +0100 Subject: [erlang-bugs] lists:suffix/2 In-Reply-To: References: <3b513c8d0803261230y76898c33sd77bcf7a73f2977d@mail.gmail.com> Message-ID: <3b513c8d0803261259v65b9ec21w824471cbb26391b5@mail.gmail.com> Ooops. True, very true. It is I who can't read. /Fredrik On Wed, Mar 26, 2008 at 8:53 PM, Anders Nygren wrote: > 2008/3/26 Fredrik Linder : > > > > > > > > (node@REDACTED)23> lists:suffix("a", "ala"). > > true > > (node@REDACTED)24> lists:suffix("al", "ala"). > > false > > (node@REDACTED)25> lists:suffix("ala", "ala"). > > true > > > > > > Erlang OTP R11B > > stdlib-1.14.5 > > > > And what is the problem? "ala" does not end with "al" but it ends with > "ala" > Remember suffix is at the end, prefix is at the beginning. > /Anders > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bjorn@REDACTED Thu Mar 27 07:53:56 2008 From: bjorn@REDACTED (Bjorn Gustavsson) Date: 27 Mar 2008 07:53:56 +0100 Subject: [erlang-bugs] Compiler crash In-Reply-To: <840D0E3C6DE3904A862484082DC9DC3D02DEE605@SITE3MAIL03.jeeves.ask.info> References: <840D0E3C6DE3904A862484082DC9DC3D02DEE605@SITE3MAIL03.jeeves.ask.info> Message-ID: "Vladimir Klebansky" writes: > Compiler crashes when compiling this small sample program (tst.erl): [...] Thanks for the bug report. The following patch corrects the problem: *** lib/compiler/src/sys_core_fold.erl@@/OTP_R12B-1 Tue Feb 5 14:37:37 2008 --- lib/compiler/src/sys_core_fold.erl Wed Mar 26 11:25:54 2008 *************** *** 1995,2005 **** Tdb = update_types_1(Expr, Pat, Tdb0), Sub#sub{t=Tdb}. ! update_types_1(#c_var{name=V}, [#c_tuple{}=P], Types) -> ! orddict:store(V, P, Types); update_types_1(_, _, Types) -> Types. ! %% update_types(V, Tdb) -> Tdb' %% Kill any entries that references the variable, %% either in the key or in the value. kill_types(V, [{V,_}|Tdb]) -> --- 1995,2015 ---- Tdb = update_types_1(Expr, Pat, Tdb0), Sub#sub{t=Tdb}. ! update_types_1(#c_var{name=V,anno=Anno}, Pat, Types) -> ! case member(reuse_for_context, Anno) of ! true -> ! %% If a variable has been marked for reuse of binary context, ! %% optimizations based on type information are unsafe. ! kill_types(V, Types); ! false -> ! case Pat of ! [#c_tuple{}=P] -> orddict:store(V, P, Types); ! _ -> Types ! end ! end; update_types_1(_, _, Types) -> Types. ! %% kill_types(V, Tdb) -> Tdb' %% Kill any entries that references the variable, %% either in the key or in the value. kill_types(V, [{V,_}|Tdb]) -> -- Bj?rn Gustavsson, Erlang/OTP, Ericsson AB From paul-trapexit@REDACTED Thu Mar 27 17:31:50 2008 From: paul-trapexit@REDACTED (Paul Mineiro) Date: Thu, 27 Mar 2008 09:31:50 -0700 (PDT) Subject: [erlang-bugs] release handler dynamic modules registered names Message-ID: we ran into a problem in r11b-5 where the release_handler was using the supervisor's child id as a registered name for children whose module spec is 'dynamic'. attached is a patch which fixes the problem. -- p -------------- next part -------------- --- /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 15:41:07.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)]; From matthew@REDACTED Thu Mar 27 19:38:09 2008 From: matthew@REDACTED (Matthew Dempsky) Date: Thu, 27 Mar 2008 11:38:09 -0700 Subject: [erlang-bugs] Silly eshell history behavior Message-ID: Run erl, type "1.", hit enter, type "2.", hit enter, press up, press down, press up. I expect at the end of this sequence for the command edit buffer to contain "2.", not "1.". Below is a patch for this. Let me know if this breaks any intentional behavior and I will revise it as necessary. --- lib/kernel/src/group.erl 2008-03-27 11:34:12.000000000 -0700 +++ lib/kernel/src/group.erl.orig 2007-11-26 10:55:37.000000000 -0800 @@ -329,9 +329,9 @@ get_line1({undefined,{_A,Mode,Char},Cs,C or ((Mode =:= meta_left_sq_bracket) and (Char =:= $A)) -> send_drv_reqs(Drv, Rs), case up_stack(Ls0) of - {none,_Ls} -> + {none,Ls} -> send_drv(Drv, beep), - get_line1(edlin:edit_line(Cs, Cont), Drv, Ls0); + get_line1(edlin:edit_line(Cs, Cont), Drv, Ls); {Lcs,Ls} -> send_drv_reqs(Drv, edlin:erase_line(Cont)), {more_chars,Ncont,Nrs} = edlin:start(edlin:prompt(Cont)), @@ -346,9 +346,9 @@ get_line1({undefined,{_A,Mode,Char},_Cs, or ((Mode =:= meta_left_sq_bracket) and (Char =:= $B)) -> send_drv_reqs(Drv, Rs), case down_stack(Ls0) of - {none,Ls} -> + {none,_Ls} -> send_drv_reqs(Drv, edlin:erase_line(Cont)), - get_line1(edlin:start(edlin:prompt(Cont)), Drv, Ls); + get_line1(edlin:start(edlin:prompt(Cont)), Drv, Ls0); {Lcs,Ls} -> send_drv_reqs(Drv, edlin:erase_line(Cont)), {more_chars,Ncont,Nrs} = edlin:start(edlin:prompt(Cont)), @@ -407,17 +407,21 @@ new_stack(Ls) -> {stack,Ls,{},[]}. up_stack({stack,[L|U],{},D}) -> {L,{stack,U,L,D}}; +up_stack({stack,[L|U],C,D}) -> + {L,{stack,U,L,[C|D]}}; up_stack({stack,[],{},D}) -> {none,{stack,[],{},D}}; -up_stack({stack,U,C,D}) -> - up_stack({stack,U,{},[C|D]}). +up_stack({stack,[],C,D}) -> + {none,{stack,[C],{},D}}. down_stack({stack,U,{},[L|D]}) -> {L,{stack,U,L,D}}; +down_stack({stack,U,C,[L|D]}) -> + {L,{stack,[C|U],L,D}}; down_stack({stack,U,{},[]}) -> {none,{stack,U,{},[]}}; -down_stack({stack,U,C,D}) -> - down_stack({stack,[C|U],{},D}). +down_stack({stack,U,C,[]}) -> + {none,{stack,U,{},[C]}}. %% This is get_line without line editing (except for backspace) and %% without echo. From saleyn@REDACTED Fri Mar 28 00:18:33 2008 From: saleyn@REDACTED (Serge Aleynikov) Date: Thu, 27 Mar 2008 19:18:33 -0400 Subject: [erlang-bugs] release handler dynamic modules registered names In-Reply-To: References: Message-ID: <47EC2B49.50408@gmail.com> I also reported this issue a while back: http://www.erlang.org/pipermail/erlang-questions/2007-August/028545.html This is still not fixed in R12B-x. Serge Paul Mineiro wrote: > we ran into a problem in r11b-5 where the release_handler was using the > supervisor's child id as a registered name for children whose module spec > is 'dynamic'. > > attached is a patch which fixes the problem. > > -- p > > > ------------------------------------------------------------------------ > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs From tobbe@REDACTED Fri Mar 28 09:42:48 2008 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 28 Mar 2008 09:42:48 +0100 Subject: [erlang-bugs] Annoying catch in timer:tc/3 Message-ID: Why is it a catch hidden in timer:tc/3 ? tc(M, F, A) -> Before = erlang:now(), Val = (catch apply(M, F, A)), % <== ANNOYING CATCH HERE !! After = erlang:now(), {now_diff(After, Before), Val}. I suggest that it is removed. Cheers, Tobbe From ulf.wiger@REDACTED Fri Mar 28 09:59:25 2008 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Fri, 28 Mar 2008 09:59:25 +0100 Subject: [erlang-bugs] Annoying catch in timer:tc/3 In-Reply-To: References: Message-ID: <47ECB36D.9040600@ericsson.com> Torbjorn Tornkvist skrev: > Why is it a catch hidden in timer:tc/3 ? > > tc(M, F, A) -> > Before = erlang:now(), > Val = (catch apply(M, F, A)), % <== ANNOYING CATCH HERE !! > After = erlang:now(), > {now_diff(After, Before), Val}. > > I suggest that it is removed. > > Cheers, Tobbe Perhaps a new function then? timer:measure(M,F,A), which doesn't catch. BR, Ulf W From tobbe@REDACTED Fri Mar 28 10:39:11 2008 From: tobbe@REDACTED (Torbjorn Tornkvist) Date: Fri, 28 Mar 2008 10:39:11 +0100 Subject: [erlang-bugs] Annoying catch in timer:tc/3 In-Reply-To: <47ECB36D.9040600@ericsson.com> References: <47ECB36D.9040600@ericsson.com> Message-ID: Ulf Wiger (TN/EAB) wrote: > Torbjorn Tornkvist skrev: >> Why is it a catch hidden in timer:tc/3 ? >> >> tc(M, F, A) -> >> Before = erlang:now(), >> Val = (catch apply(M, F, A)), % <== ANNOYING CATCH HERE !! >> After = erlang:now(), >> {now_diff(After, Before), Val}. >> >> I suggest that it is removed. >> >> Cheers, Tobbe > > Perhaps a new function then? timer:measure(M,F,A), > which doesn't catch. Yes, probably the safest solution :-) --Tobbe > > BR, > Ulf W > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From matthias@REDACTED Mon Mar 31 10:46:30 2008 From: matthias@REDACTED (Matthias Lang) Date: Mon, 31 Mar 2008 10:46:30 +0200 Subject: [erlang-bugs] docbuilder doesn't like whitespace after CDATA section Message-ID: <18416.42214.427980.291676@antilipe.corelatus.se> Hi, I've attached a minimal file demonstrating the problem. Here's what R12B-1 says when I try to compile the document: 4> docb_transform:file("cdata_problem"). *** Error: Formatting trouble in code: {function_clause, [{docb_html,rule, [[code,section,chapter], {4, ["NONE"], [{pcdata,[],"\tThis does not\\n\t\n"}, {pcdata,[]," \n"}]}]}, {docb_main,handle_rule_call_result,8}, {docb_main,pp_list,5}, {docb_main,pp_list,5}, {docb_main,handle_rule_call_result,8}, {docb_main,pp_list,5}, {docb_main,pp_list,5}, {docb_main,handle_rule_call_result,8}]} *** Error: Failure in rule([code,section,chapter], {4, ["NONE"], [{pcdata,[],"\tThis does not\\n\t\n"}, {pcdata,[]," \n"}]}) ok Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: cdata_problem.xml Type: application/octet-stream Size: 394 bytes Desc: not available URL: From kenneth.lundin@REDACTED Mon Mar 31 11:54:53 2008 From: kenneth.lundin@REDACTED (Kenneth Lundin) Date: Mon, 31 Mar 2008 11:54:53 +0200 Subject: [erlang-bugs] docbuilder doesn't like whitespace after CDATA section In-Reply-To: <18416.42214.427980.291676@antilipe.corelatus.se> References: <18416.42214.427980.291676@antilipe.corelatus.se> Message-ID: Thanks for reporting this problem, Will be corrected in R12B-2. Assigned ticket OTP-7236 /Kenneth On 3/31/08, Matthias Lang wrote: > Hi, > > I've attached a minimal file demonstrating the problem. Here's what > R12B-1 says when I try to compile the document: > > 4> docb_transform:file("cdata_problem"). > *** Error: Formatting trouble in code: {function_clause, > [{docb_html,rule, > [[code,section,chapter], > {4, > ["NONE"], > [{pcdata,[],"\tThis does not\\n\t\n"}, > {pcdata,[]," \n"}]}]}, > {docb_main,handle_rule_call_result,8}, > {docb_main,pp_list,5}, > {docb_main,pp_list,5}, > {docb_main,handle_rule_call_result,8}, > {docb_main,pp_list,5}, > {docb_main,pp_list,5}, > {docb_main,handle_rule_call_result,8}]} > *** Error: Failure in rule([code,section,chapter], {4, > ["NONE"], > [{pcdata,[],"\tThis does not\\n\t\n"}, > {pcdata,[]," \n"}]}) > ok > > > Matthias > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From christopher.faulet@REDACTED Mon Mar 31 17:36:56 2008 From: christopher.faulet@REDACTED (christopher faulet) Date: Mon, 31 Mar 2008 17:36:56 +0200 Subject: [erlang-bugs] Bug in qlc when a cursor is created Message-ID: <47F10518.5070302@capflam.org> Hi, I think there is a bug in the qlc module. It seems that the creation of a cursor is a little bit greedy with messages in current process queue: 1> ets:new(qlc_test, [named_table, public]). qlc_test 2> self() ! some_msg. some_msg 3> erlang:process_info(self(), messages). {messages,[some_msg]} 4> erlang:process_info(self(), message_queue_len). {message_queue_len,1} 5> C=qlc:cursor(ets:table(qlc_test)). {qlc_cursor,{<0.38.0>,<0.32.0>}} 6> erlang:process_info(self(), messages). {messages,[]} 7> erlang:process_info(self(), message_queue_len). {message_queue_len,0} 8> qlc:delete_cursor(C). ok I made my tests on R12B-1 but it exists in previous versions. After some investigation in the qlc module, I found a "catch all" clause in the function parent_fun: parent_fun(Pid, Parent) -> receive %% ... snipped code ... _Ignored -> parent_fun(Pid, Parent) end. IMHO, this clause must be removed otherwise we cannot "safely" create a cursor. An other solution might be to spawn the creation and send back the result. But it seems tedious (and undocumented). Here is a patch for the release R12B-1. Regards, -- Christopher Faulet -------------- next part -------------- A non-text attachment was scrubbed... Name: qlc.patch Type: text/x-patch Size: 502 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: