From heinz@REDACTED Mon Jul 2 00:19:23 2012 From: heinz@REDACTED (Heinz N. Gies) Date: Mon, 2 Jul 2012 00:19:23 +0200 Subject: [erlang-bugs] Sendfile in solaris Message-ID: <6567DD9D-2160-4322-82CF-47B90DC514D4@licenser.net> Hi everyone, I've recently encountered a big nuber of errors in sendfiel in solaris. (example https://www.refheap.com/paste/3406) I've dug through the web a bit and after eliminating error sources like non existing files, problems with cowboy etc I've found the following thread with python facing a similar problem: http://bugs.python.org/issue11323 And I kind of think we're facing the same issue. I've tried to look at the erlang sendfile source but I must admit after reading it I've still not the slightest clue if erlang catches this or not o.O. Regards, Heinz -- Heinz N. Gies heinz@REDACTED http://licenser.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From lukas@REDACTED Mon Jul 2 09:40:44 2012 From: lukas@REDACTED (Lukas Larsson) Date: Mon, 2 Jul 2012 09:40:44 +0200 Subject: [erlang-bugs] Sendfile in solaris In-Reply-To: <6567DD9D-2160-4322-82CF-47B90DC514D4@licenser.net> References: <6567DD9D-2160-4322-82CF-47B90DC514D4@licenser.net> Message-ID: <4FF1507C.4070101@erlang.org> Hello, Thanks for reporting this! Which version of Solaris are you running? Could you send me a minimal testcase for the failure? Lukas On 02/07/12 00:19, Heinz N. Gies wrote: > Hi everyone, > I've recently encountered a big nuber of errors in sendfiel in > solaris. (example https://www.refheap.com/paste/3406) > > I've dug through the web a bit and after eliminating error sources > like non existing files, problems with cowboy etc I've found the > following thread with python facing a similar problem: > http://bugs.python.org/issue11323 And I kind of think we're facing the > same issue. > > > I've tried to look at the erlang sendfile source but I must admit > after reading it I've still not the slightest clue if erlang catches > this or not o.O. > > Regards, > Heinz > -- > Heinz N. Gies > heinz@REDACTED > http://licenser.net > > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -------------- next part -------------- An HTML attachment was scrubbed... URL: From henrik@REDACTED Wed Jul 4 14:10:28 2012 From: henrik@REDACTED (Henrik Nord) Date: Wed, 4 Jul 2012 14:10:28 +0200 Subject: [erlang-bugs] www.erlang.org not responding In-Reply-To: <1CD1916B-14C7-403D-ABD4-EAAF11A04573@feuerlabs.com> References: <1CD1916B-14C7-403D-ABD4-EAAF11A04573@feuerlabs.com> Message-ID: <4FF432B4.3090807@erlang.org> Hello The site was down due to a backup-script that went in to a tailspin. The issue is now resolved and everything is back up! -- /Henrik Nord Erlang/OTP From henrik@REDACTED Fri Jul 6 15:17:23 2012 From: henrik@REDACTED (Henrik Nord) Date: Fri, 6 Jul 2012 15:17:23 +0200 Subject: [erlang-bugs] [erlang-patches] [PATCH] Zip archives disk numbering In-Reply-To: <028E625E-3B6E-4941-9764-40C94F69CA1A@kallisys.net> References: <028E625E-3B6E-4941-9764-40C94F69CA1A@kallisys.net> Message-ID: <4FF6E563.4040907@erlang.org> Thank you I grabbed git fetch git://github.com/pguyot/otp.git fix-zip-multidisk ;) On 06/18/2012 03:26 PM, Paul Guyot wrote: > Hello, > > There is a bug in zip.erl: archives are wrongly created with the central directory's disk_num_start set to 1. The specification is not extremely clear about the base number of this value, however zip.erl uses 0 everywhere else for the disk number. Besides, this bug causes some incompatibility with other software that insists in reading 0 as disk_num_start or otherwise consider that the archive is multidisk. This is the case with Microsoft Office applications. For example, the following code tests for 0: > http://code.google.com/p/xmind-merger/source/browse/OpenXmlManager/Internal/IO/Zip/ZipIOCentralDirectoryFileHeader.cs#204 > > You will find a patch against 'maint' here: > git fetch git://github.com/pguyot/otp.git fix-multidisk-zip > https://github.com/pguyot/otp/commit/da11eb78dac39940edf4dcfbb47b438493345598 > > This patch simply fixes the single buggy line. It does not include a test. Indeed, I am confused about the best way to test this fix. zip_SUITE tests in maint branch are mostly about extracting files from zip archives, and there is no comparison or binary matching of the output of zip:create/{2,3} function. If a test is required for inclusion, please let me know the best approach for designing such a test, and I will gladly provide an amended patch. > > Regards, > > Paul -- /Henrik Nord Erlang/OTP From mononcqc@REDACTED Wed Jul 18 14:58:53 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 18 Jul 2012 08:58:53 -0400 Subject: [erlang-bugs] Scheduler Wall Time Statistics live|dead locking a process. Message-ID: <5006B30D.4030409@ferd.ca> Hi there, If you go on erlang-questions, you'll find the following thread I started regarding one of my gen_servers locking up forever until I try to connect to the VM: http://erlang.org/pipermail/erlang-questions/2012-July/068097.html And the information following it in http://erlang.org/pipermail/erlang-questions/2012-July/068099.html The gist of it is that apparently, the gen_server gets stuck while calling erlang:statistics(scheduler_wall_time). A process info dump on it returns: [{registered_name,vmstats_server}, {current_function,{erlang,sched_wall_time,3}}, {initial_call,{proc_lib,init_p,5}}, {status,waiting}, {message_queue_len,2}, {messages,[{system,{<5998.7341.243>,#Ref<5998.0.3810.221818>},get_status}, {system,{<5998.28757.800>,#Ref<5998.0.3811.260443>},get_status}]}, {links,[<5998.918.0>]}, {dictionary,[{random_seed,{17770,13214,15044}}, {'$ancestors',[vmstats_sup,<5998.917.0>]}, {'$initial_call',{vmstats_server,init,1}}]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<5998.916.0>}, {total_heap_size,122003}, {heap_size,121393}, {stack_size,21}, {reductions,314325681}, {garbage_collection,[{min_bin_vheap_size,46368}, {min_heap_size,233}, {fullsweep_after,65535}, {minor_gcs,23774}]}, {suspending,[]}] ok with the interesting parts: {current_function,{erlang,sched_wall_time,3}}, {status,waiting}, I'm unsure what exactly causes the problem, and we're running the VM with default arguments when it comes to scheduling and layout. It happens even when the virtual machine is under relatively low load (scheduler active wall time is less than 5%, but more than 2% of the total wall time when averaging all cores) and can also happen under higher load. Only that process appears affected. From pan@REDACTED Wed Jul 18 15:44:13 2012 From: pan@REDACTED (pan@REDACTED) Date: Wed, 18 Jul 2012 15:44:13 +0200 Subject: [erlang-bugs] Scheduler Wall Time Statistics live|dead locking a process. In-Reply-To: <5006B30D.4030409@ferd.ca> References: <5006B30D.4030409@ferd.ca> Message-ID: Hi Fred! On Wed, 18 Jul 2012, Fred Hebert wrote: > Hi there, > > If you go on erlang-questions, you'll find the following thread I started > regarding one of my gen_servers locking up forever until I try to connect to > the VM: http://erlang.org/pipermail/erlang-questions/2012-July/068097.html > > And the information following it in > http://erlang.org/pipermail/erlang-questions/2012-July/068099.html > > The gist of it is that apparently, the gen_server gets stuck while calling > erlang:statistics(scheduler_wall_time). A process info dump on it returns: > > [{registered_name,vmstats_server}, > {current_function,{erlang,sched_wall_time,3}}, > {initial_call,{proc_lib,init_p,5}}, > {status,waiting}, > {message_queue_len,2}, > {messages,[{system,{<5998.7341.243>,#Ref<5998.0.3810.221818>},get_status}, > {system,{<5998.28757.800>,#Ref<5998.0.3811.260443>},get_status}]}, > {links,[<5998.918.0>]}, > {dictionary,[{random_seed,{17770,13214,15044}}, > {'$ancestors',[vmstats_sup,<5998.917.0>]}, > {'$initial_call',{vmstats_server,init,1}}]}, > {trap_exit,false}, > {error_handler,error_handler}, > {priority,normal}, > {group_leader,<5998.916.0>}, > {total_heap_size,122003}, > {heap_size,121393}, > {stack_size,21}, > {reductions,314325681}, > {garbage_collection,[{min_bin_vheap_size,46368}, > {min_heap_size,233}, > {fullsweep_after,65535}, > {minor_gcs,23774}]}, > {suspending,[]}] > ok > > with the interesting parts: > {current_function,{erlang,sched_wall_time,3}}, > {status,waiting}, > > I'm unsure what exactly causes the problem, and we're running the VM with > default arguments when it comes to scheduling and layout. It happens even > when the virtual machine is under relatively low load (scheduler active wall > time is less than 5%, but more than 2% of the total wall time when averaging > all cores) and can also happen under higher load. Ouch... Seems like one of the schedulers does not understand that it should report data back to the process. Is there any chance of dumping core of a machine where it hangs, or would that mean interruption of service? I *really* would like to know what the schedulers are doing when they should be reporting back... > > Only that process appears affected. Yes, it's just waiting for a message that does not arrive, one that should be sent from the VM when statistics for the scheduler is available... > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > Cheers, /Patrik From mononcqc@REDACTED Wed Jul 18 15:50:08 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 18 Jul 2012 09:50:08 -0400 Subject: [erlang-bugs] Scheduler Wall Time Statistics live|dead locking a process. In-Reply-To: References: <5006B30D.4030409@ferd.ca> Message-ID: <5006BF10.7060305@ferd.ca> Hi there Patrick! I can't exactly afford to dump core on one of the servers right now because yeah, it would interrupt the service. I could however set one VM up on the server that just sits and calls vmstats and does some busy test work, pushing it to a fake StatsD server to reproduce it; maybe it could work. I can get going setting stuff up; how should I dump the core for it to be useful for you? Regards, Fred. On 12-07-18 9:44 AM, pan@REDACTED wrote: > Hi Fred! > > On Wed, 18 Jul 2012, Fred Hebert wrote: > >> Hi there, >> >> If you go on erlang-questions, you'll find the following thread I >> started regarding one of my gen_servers locking up forever until I >> try to connect to the VM: >> http://erlang.org/pipermail/erlang-questions/2012-July/068097.html >> >> And the information following it in >> http://erlang.org/pipermail/erlang-questions/2012-July/068099.html >> >> The gist of it is that apparently, the gen_server gets stuck while >> calling erlang:statistics(scheduler_wall_time). A process info dump >> on it returns: >> >> [{registered_name,vmstats_server}, >> {current_function,{erlang,sched_wall_time,3}}, >> {initial_call,{proc_lib,init_p,5}}, >> {status,waiting}, >> {message_queue_len,2}, >> {messages,[{system,{<5998.7341.243>,#Ref<5998.0.3810.221818>},get_status}, >> >> {system,{<5998.28757.800>,#Ref<5998.0.3811.260443>},get_status}]}, >> {links,[<5998.918.0>]}, >> {dictionary,[{random_seed,{17770,13214,15044}}, >> {'$ancestors',[vmstats_sup,<5998.917.0>]}, >> {'$initial_call',{vmstats_server,init,1}}]}, >> {trap_exit,false}, >> {error_handler,error_handler}, >> {priority,normal}, >> {group_leader,<5998.916.0>}, >> {total_heap_size,122003}, >> {heap_size,121393}, >> {stack_size,21}, >> {reductions,314325681}, >> {garbage_collection,[{min_bin_vheap_size,46368}, >> {min_heap_size,233}, >> {fullsweep_after,65535}, >> {minor_gcs,23774}]}, >> {suspending,[]}] >> ok >> >> with the interesting parts: >> {current_function,{erlang,sched_wall_time,3}}, >> {status,waiting}, >> >> I'm unsure what exactly causes the problem, and we're running the VM >> with default arguments when it comes to scheduling and layout. It >> happens even when the virtual machine is under relatively low load >> (scheduler active wall time is less than 5%, but more than 2% of the >> total wall time when averaging all cores) and can also happen under >> higher load. > > Ouch... Seems like one of the schedulers does not understand that it > should report data back to the process. Is there any chance of dumping > core of a machine where it hangs, or would that mean interruption of > service? I *really* would like to know what the schedulers are doing > when they should be reporting back... > > >> >> Only that process appears affected. > > Yes, it's just waiting for a message that does not arrive, one that > should be sent from the VM when statistics for the scheduler is > available... > >> _______________________________________________ >> erlang-bugs mailing list >> erlang-bugs@REDACTED >> http://erlang.org/mailman/listinfo/erlang-bugs >> > Cheers, > /Patrik From pan@REDACTED Wed Jul 18 16:30:27 2012 From: pan@REDACTED (pan@REDACTED) Date: Wed, 18 Jul 2012 16:30:27 +0200 Subject: [erlang-bugs] Scheduler Wall Time Statistics live|dead locking a process. In-Reply-To: <5006BF10.7060305@ferd.ca> References: <5006B30D.4030409@ferd.ca> <5006BF10.7060305@ferd.ca> Message-ID: Hi! On Wed, 18 Jul 2012, Fred Hebert wrote: > Hi there Patrick! > > I can't exactly afford to dump core on one of the servers right now because > yeah, it would interrupt the service. I could however set one VM up on the > server that just sits and calls vmstats and does some busy test work, pushing > it to a fake StatsD server to reproduce it; maybe it could work. That would be great! > > I can get going setting stuff up; how should I dump the core for it to be > useful for you? Oh, just kill -ABRT on the beam pid when it hangs. Don't forget to 'ulimit -c unlimited' before starting erlang though, I tend to forget that all the time and get very sad when I've reproduced a problem after three days of trying and get no core whatsoever :) > > Regards, > Fred. Cheers, Patrik > > On 12-07-18 9:44 AM, pan@REDACTED wrote: >> Hi Fred! >> >> On Wed, 18 Jul 2012, Fred Hebert wrote: >> >>> Hi there, >>> >>> If you go on erlang-questions, you'll find the following thread I started >>> regarding one of my gen_servers locking up forever until I try to connect >>> to the VM: >>> http://erlang.org/pipermail/erlang-questions/2012-July/068097.html >>> >>> And the information following it in >>> http://erlang.org/pipermail/erlang-questions/2012-July/068099.html >>> >>> The gist of it is that apparently, the gen_server gets stuck while calling >>> erlang:statistics(scheduler_wall_time). A process info dump on it returns: >>> >>> [{registered_name,vmstats_server}, >>> {current_function,{erlang,sched_wall_time,3}}, >>> {initial_call,{proc_lib,init_p,5}}, >>> {status,waiting}, >>> {message_queue_len,2}, >>> {messages,[{system,{<5998.7341.243>,#Ref<5998.0.3810.221818>},get_status}, >>> {system,{<5998.28757.800>,#Ref<5998.0.3811.260443>},get_status}]}, >>> {links,[<5998.918.0>]}, >>> {dictionary,[{random_seed,{17770,13214,15044}}, >>> {'$ancestors',[vmstats_sup,<5998.917.0>]}, >>> {'$initial_call',{vmstats_server,init,1}}]}, >>> {trap_exit,false}, >>> {error_handler,error_handler}, >>> {priority,normal}, >>> {group_leader,<5998.916.0>}, >>> {total_heap_size,122003}, >>> {heap_size,121393}, >>> {stack_size,21}, >>> {reductions,314325681}, >>> {garbage_collection,[{min_bin_vheap_size,46368}, >>> {min_heap_size,233}, >>> {fullsweep_after,65535}, >>> {minor_gcs,23774}]}, >>> {suspending,[]}] >>> ok >>> >>> with the interesting parts: >>> {current_function,{erlang,sched_wall_time,3}}, >>> {status,waiting}, >>> >>> I'm unsure what exactly causes the problem, and we're running the VM with >>> default arguments when it comes to scheduling and layout. It happens even >>> when the virtual machine is under relatively low load (scheduler active >>> wall time is less than 5%, but more than 2% of the total wall time when >>> averaging all cores) and can also happen under higher load. >> >> Ouch... Seems like one of the schedulers does not understand that it should >> report data back to the process. Is there any chance of dumping core of a >> machine where it hangs, or would that mean interruption of service? I >> *really* would like to know what the schedulers are doing when they should >> be reporting back... >> >> >>> >>> Only that process appears affected. >> >> Yes, it's just waiting for a message that does not arrive, one that should >> be sent from the VM when statistics for the scheduler is available... >> >>> _______________________________________________ >>> erlang-bugs mailing list >>> erlang-bugs@REDACTED >>> http://erlang.org/mailman/listinfo/erlang-bugs >>> >> Cheers, >> /Patrik > From fritchie@REDACTED Wed Jul 18 19:09:00 2012 From: fritchie@REDACTED (Scott Lystig Fritchie) Date: Wed, 18 Jul 2012 12:09:00 -0500 Subject: [erlang-bugs] Scheduler Wall Time Statistics live|dead locking a process. In-Reply-To: Message of "Wed, 18 Jul 2012 09:50:08 EDT." <5006BF10.7060305@ferd.ca> Message-ID: <569.1342631340@snookles.snookles.com> fh> I can't exactly afford to dump core on one of the servers right now fh> because yeah, it would interrupt the service. Fred, does the time that "gcore" pause a process cause too long of an interruption? Gcore would allow a process to continue running after it's done. -Scott From mononcqc@REDACTED Wed Jul 18 19:22:41 2012 From: mononcqc@REDACTED (Fred Hebert) Date: Wed, 18 Jul 2012 13:22:41 -0400 Subject: [erlang-bugs] Scheduler Wall Time Statistics live|dead locking a process. In-Reply-To: <569.1342631340@snookles.snookles.com> References: <569.1342631340@snookles.snookles.com> Message-ID: <5006F0E1.4080609@ferd.ca> I actually managed to get a core dump from a fake VM. It's currently being compressed, as the original one stands at a whopping 7.3GB. The big problem is how long it takes to dump vs. the memory it requires. We were swapping for a few minutes while I was getting it ready. Patrik: Got a favorite way to receive huge files? -Fred. On 12-07-18 1:09 PM, Scott Lystig Fritchie wrote: > fh> I can't exactly afford to dump core on one of the servers right now > fh> because yeah, it would interrupt the service. > > Fred, does the time that "gcore" pause a process cause too long of an > interruption? Gcore would allow a process to continue running after > it's done. > > -Scott From emile@REDACTED Thu Jul 19 12:43:17 2012 From: emile@REDACTED (Emile Joubert) Date: Thu, 19 Jul 2012 11:43:17 +0100 Subject: [erlang-bugs] Non-ASCII $HOME crashed distributed Erlang on OS X Message-ID: <5007E4C5.7030303@rabbitmq.com> Hi, I'm unable to start a distributed Erlang node on OS X when the $HOME directory contains non-ASCII characters. Is there some aspect of my environment that I need to change or is this a bug in Erlang (I'm using R15B)? Here is a transcript that demonstrates: uname -v Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 locale LANG="en_GB.UTF-8" LC_COLLATE="en_GB.UTF-8" LC_CTYPE="en_GB.UTF-8" LC_MESSAGES="en_GB.UTF-8" LC_MONETARY="en_GB.UTF-8" LC_NUMERIC="en_GB.UTF-8" LC_TIME="en_GB.UTF-8" LC_ALL= echo $HOME /tmp/?A? erl -sname foo {error_logger,{{2012,7,19},{11,33,22}},"Failed to create cookie file",[]} {error_logger,{{2012,7,19},{11,33,22}},crash_report,[[{initial_call,{auth,init,['Argument__1']}},{pid,<0.18.0>},{registered_name,[]},{error_info,{exit,{"Failed to create cookie file",[{auth,init_cookie,0,[{file,"auth.erl"},{line,285}]},{auth,init,1,[{file,"auth.erl"},{line,139}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,297}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,321}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{ancestors,[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[<0.16.0>]},{dictionary,[]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,548}],[]]} {error_logger,{{2012,7,19},{11,33,22}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{"Failed to create cookie file",[{auth,init_cookie,0,[{file,"auth.erl"},{line,285}]},{auth,init,1,[{file,"auth.erl"},{line,139}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,297}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{offender,[{pid,undefined},{name,auth},{mfargs,{auth,start_link,[]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} {error_logger,{{2012,7,19},{11,33,22}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} {error_logger,{{2012,7,19},{11,33,22}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} {"Kernel pid terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} -Emile From emile@REDACTED Thu Jul 19 14:51:09 2012 From: emile@REDACTED (Emile Joubert) Date: Thu, 19 Jul 2012 13:51:09 +0100 Subject: [erlang-bugs] Non-ASCII $HOME crashed distributed Erlang on OS X In-Reply-To: <5007E4C5.7030303@rabbitmq.com> References: <5007E4C5.7030303@rabbitmq.com> Message-ID: <500802BD.4020907@rabbitmq.com> On 19/07/12 11:43, Emile Joubert wrote: > environment that I need to change or is this a bug in Erlang (I'm using > R15B)? Here is a transcript that demonstrates: I've tried with R15B01 as well and get the same error. From pan@REDACTED Thu Jul 19 15:56:50 2012 From: pan@REDACTED (pan@REDACTED) Date: Thu, 19 Jul 2012 15:56:50 +0200 Subject: [erlang-bugs] Non-ASCII $HOME crashed distributed Erlang on OS X In-Reply-To: <5007E4C5.7030303@rabbitmq.com> References: <5007E4C5.7030303@rabbitmq.com> Message-ID: Hi! On Thu, 19 Jul 2012, Emile Joubert wrote: > Hi, > > I'm unable to start a distributed Erlang node on OS X when the $HOME > directory contains non-ASCII characters. Is there some aspect of my > environment that I need to change or is this a bug in Erlang (I'm using > R15B)? Here is a transcript that demonstrates: > > uname -v > Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; > root:xnu-1504.7.4~1/RELEASE_I386 > > locale > LANG="en_GB.UTF-8" > LC_COLLATE="en_GB.UTF-8" > LC_CTYPE="en_GB.UTF-8" > LC_MESSAGES="en_GB.UTF-8" > LC_MONETARY="en_GB.UTF-8" > LC_NUMERIC="en_GB.UTF-8" > LC_TIME="en_GB.UTF-8" > LC_ALL= > > echo $HOME > /tmp/??A?? > > erl -sname foo > {error_logger,{{2012,7,19},{11,33,22}},"Failed to create cookie file",[]} > {error_logger,{{2012,7,19},{11,33,22}},crash_report,[[{initial_call,{auth,init,['Argument__1']}},{pid,<0.18.0>},{registered_name,[]},{error_info,{exit,{"Failed > to create cookie > file",[{auth,init_cookie,0,[{file,"auth.erl"},{line,285}]},{auth,init,1,[{file,"auth.erl"},{line,139}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,297}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]},[{gen_server,init_it,6,[{file,"gen_server.erl"},{line,321}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{ancestors,[net_sup,kernel_sup,<0.9.0>]},{messages,[]},{links,[<0.16.0>]},{dictionary,[]},{trap_exit,true},{status,running},{heap_size,610},{stack_size,24},{reductions,548}],[]]} > {error_logger,{{2012,7,19},{11,33,22}},supervisor_report,[{supervisor,{local,net_sup}},{errorContext,start_error},{reason,{"Failed > to create cookie > file",[{auth,init_cookie,0,[{file,"auth.erl"},{line,285}]},{auth,init,1,[{file,"auth.erl"},{line,139}]},{gen_server,init_it,6,[{file,"gen_server.erl"},{line,297}]},{proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,227}]}]}},{offender,[{pid,undefined},{name,auth},{mfargs,{auth,start_link,[]}},{restart_type,permanent},{shutdown,2000},{child_type,worker}]}]} > {error_logger,{{2012,7,19},{11,33,22}},supervisor_report,[{supervisor,{local,kernel_sup}},{errorContext,start_error},{reason,shutdown},{offender,[{pid,undefined},{name,net_sup},{mfargs,{erl_distribution,start_link,[]}},{restart_type,permanent},{shutdown,infinity},{child_type,supervisor}]}]} > {error_logger,{{2012,7,19},{11,33,22}},std_info,[{application,kernel},{exited,{shutdown,{kernel,start,[normal,[]]}}},{type,permanent}]} > {"Kernel pid > terminated",application_controller,"{application_start_failure,kernel,{shutdown,{kernel,start,[normal,[]]}}}"} Yes, that's a reproducable bug allright. The environment variable is in UTF8 and a *list* with UTF8 characters is passed to the file operation instead of a binary (or a list of unicode codepoints, which would also have worked) Could you try the following source patch on kernel/auth.erl: -----------------8><----------------------------- *** auth.erl.old 2012-07-18 20:11:07.000000000 +0200 --- auth.erl 2012-07-19 15:52:57.000000000 +0200 *************** *** 298,304 **** read_cookie() -> case init:get_argument(home) of {ok, [[Home]]} -> ! read_cookie(filename:join(Home, ".erlang.cookie")); _ -> {error, "No home for cookie file"} end. --- 298,304 ---- read_cookie() -> case init:get_argument(home) of {ok, [[Home]]} -> ! read_cookie(filename:join(list_to_binary(Home), ".erlang.cookie")); _ -> {error, "No home for cookie file"} end. -----------------8><----------------------------- - and report back if that fixes your problem? Cheers, /Patrik > > > -Emile > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs > From diego.llarrull@REDACTED Thu Jul 19 15:58:12 2012 From: diego.llarrull@REDACTED (Diego Llarrull) Date: Thu, 19 Jul 2012 10:58:12 -0300 Subject: [erlang-bugs] Cover compiling of .beam files inside .ez archives, is it possible? In-Reply-To: <500802BD.4020907@rabbitmq.com> References: <5007E4C5.7030303@rabbitmq.com> <500802BD.4020907@rabbitmq.com> Message-ID: <50081274.7000903@tecso.coop> Good day to everyone, I'm building a riak-core based application which relies con rebar + gnu make to generate deployment nodes (i.e: an embedded erts plus all source code and dependencies). Each app is stored in an .ez file inside the "lib" folder. No unzipping of the files in a special directory occurs in runtime because the code server is able to load .beam files from archives (tough experimentally, as stated in http://www.erlang.org/doc/man/code.html). The cover server, instead, can't access such files, which makes it impossible to perform cover analysis in runtime (something we require because the modules to analyse rely on servers which are spawned on demand). My question would be the following: 1) Is it possible to cover compile the binaries at compile-time (i.e., before generating the node releases) ? 2) Is there any way to access the .ez files without unzipping them, so as to pass a reference to that file to cover:compile_beam() ? (Note to rebar users: rebar eunit doesn't do the job for me, because it performs offline, static, coverage analysis). Any help would be greatly appreciated. Thanks in advance Diego Llarrull -- -------------- next part -------------- An HTML attachment was scrubbed... URL: From diego.llarrull@REDACTED Thu Jul 19 16:21:53 2012 From: diego.llarrull@REDACTED (Diego Llarrull) Date: Thu, 19 Jul 2012 11:21:53 -0300 Subject: [erlang-bugs] Cover compiling of .beam files inside .ez archives, is it possible? In-Reply-To: <50081274.7000903@tecso.coop> References: <5007E4C5.7030303@rabbitmq.com> <500802BD.4020907@rabbitmq.com> <50081274.7000903@tecso.coop> Message-ID: <50081801.1070602@tecso.coop> I'm very sorry, that mail was intended to erlang-questions, not erlang-bugs. My apologies El jue 19 jul 2012 10:58:12 ART, Diego Llarrull escribi?: > Good day to everyone, > > I'm building a riak-core based application which relies con rebar + > gnu make to generate deployment nodes (i.e: an embedded erts plus all > source code and dependencies). Each app is stored in an .ez file > inside the "lib" folder. No unzipping of the files in a special > directory occurs in runtime because the code server is able to load > .beam files from archives (tough experimentally, as stated in > http://www.erlang.org/doc/man/code.html). > > The cover server, instead, can't access such files, which makes it > impossible to perform cover analysis in runtime (something we require > because the modules to analyse rely on servers which are spawned on > demand). My question would be the following: > > 1) Is it possible to cover compile the binaries at compile-time (i.e., > before generating the node releases) ? > 2) Is there any way to access the .ez files without unzipping them, so > as to pass a reference to that file to cover:compile_beam() ? > > (Note to rebar users: rebar eunit doesn't do the job for me, because > it performs offline, static, coverage analysis). > > Any help would be greatly appreciated. > > Thanks in advance > > Diego Llarrull > -- > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs -- *Lic. Diego Miguel Llarrull*LinkedIn diego.llarrull@REDACTED Tel: +54 341 527 4470 / +54 341 528 0080 / 0020 Sarmiento 784 Piso 1 - (CP 2000) Rosario - Provincia de Santa Fe - Argentina From emile@REDACTED Thu Jul 19 17:35:10 2012 From: emile@REDACTED (Emile Joubert) Date: Thu, 19 Jul 2012 16:35:10 +0100 Subject: [erlang-bugs] Non-ASCII $HOME crashed distributed Erlang on OS X In-Reply-To: References: <5007E4C5.7030303@rabbitmq.com> Message-ID: <5008292E.2060108@rabbitmq.com> Hi, On 19/07/12 14:56, pan@REDACTED wrote: > Could you try the following source patch on kernel/auth.erl: > -----------------8><----------------------------- [...] > -----------------8><----------------------------- > - and report back if that fixes your problem? Yes that does work for me, thanks! The cookie file gets created in the folder containing non-ASCII characters and distributed Erlang starts up. -Emile From pan@REDACTED Fri Jul 20 11:31:49 2012 From: pan@REDACTED (pan@REDACTED) Date: Fri, 20 Jul 2012 11:31:49 +0200 Subject: [erlang-bugs] Non-ASCII $HOME crashed distributed Erlang on OS X In-Reply-To: <5008292E.2060108@rabbitmq.com> References: <5007E4C5.7030303@rabbitmq.com> <5008292E.2060108@rabbitmq.com> Message-ID: Hi! On Thu, 19 Jul 2012, Emile Joubert wrote: > Hi, > > On 19/07/12 14:56, pan@REDACTED wrote: >> Could you try the following source patch on kernel/auth.erl: >> -----------------8><----------------------------- > > [...] > >> -----------------8><----------------------------- >> - and report back if that fixes your problem? > > Yes that does work for me, thanks! The cookie file gets created in the > folder containing non-ASCII characters and distributed Erlang starts up. Great! I'll run it through the test suites then - if all goes well it will be included in the next service release. Thanks for the bug report and fast feedback! > > > -Emile > Cheers, /Patrik From erlang@REDACTED Wed Jul 25 09:36:02 2012 From: erlang@REDACTED (Joe Armstrong) Date: Wed, 25 Jul 2012 09:36:02 +0200 Subject: [erlang-bugs] [erlang-questions] Recursive Heap Allocation In-Reply-To: References: Message-ID: It's a bug in the smp handling of io:format. This program has similar behaviour -module(bug1). -compile(export_all). test(N) -> io:format("~p~n", [N]), test(N+1). I did this: 1 > spawn(fun() -> etop:start() end). 2> bug1:test(0). You can see that user_drv global process is accumulating messages faster than it can handle them. It's in usr_drv:io_request/3. As far as I'm aware io:format did have flow control so this shouldn't happen I then changed the program to the following: test(N) -> Len = process_info(whereis(user_drv),[message_queue_len]), io:format("~p ~p~n", [N, Len]), test(N+1). The printout from this is weird - the length stays at zero for long periods - then climbs linearly up to some number like 180 or 169 then instantaneously goes back to zero Now I ran with "erl -smp disable" The counter stays at zero forever. I think the I/O handling for smp erlang is buggy On Mon, Jul 23, 2012 at 9:50 PM, Greg Martin wrote: > I'm just learning erlang using Erlang R15B01 (erts-5.9.1) on Windows. I'm > wondering why ipv4_addrs:test(ipv4_addrs:first()) leads to the crash below > and how it can be called so that it doesn't. Thanks. > > {1,2,22,127} > {1,2,22,128} > {1,2,22,129} > {1,2,22,130} > {1,2,22,131} > {1,2,22,132} > {1,2,22,133} > {1,2,22,134} > > Crash dump was written to: erl_crash.dump > eheap_alloc: Cannot allocate 373662860 bytes of memory (of type "heap"). > > > Abnormal termination > > > -module(ipv4_addrs). > > -export([first/0, next/1, test/1]). > > first()-> > { 1,1,0,0 }. > > next( { 255, 255, 255, 255 } ) -> done; > next( { 9, 255, 255, 255 } ) -> { 11, 0, 0, 0 }; > next( { 172, 15, 255, 255 } ) -> { 172, 32, 0, 0 }; > next( { 192, 167, 255, 255 } ) -> { 192, 169, 0, 0 }; > next( { First, 255, 255, 255 } ) -> { First + 1, 0, 0, 0 }; > next( { First, Second, 255, 255 } ) -> { First, Second + 1, 0, 0 }; > next( { First, Second, Third, 255 } ) -> { First, Second, Third + 1, 0 }; > next( { First, Second, Third, Fourth } ) -> { First, Second, Third, Fourth + > 1 }. > > test(done) -> done; > test(Addr) -> > io:format("~p~n", [Addr]), > Next = next(Addr), > test(Next). > > _______________________________________________ > erlang-questions mailing list > erlang-questions@REDACTED > http://erlang.org/mailman/listinfo/erlang-questions From carlsson.richard@REDACTED Wed Jul 25 10:02:48 2012 From: carlsson.richard@REDACTED (Richard Carlsson) Date: Wed, 25 Jul 2012 10:02:48 +0200 Subject: [erlang-bugs] [erlang-questions] Recursive Heap Allocation In-Reply-To: References: Message-ID: <500FA828.3030104@gmail.com> On 07/25/2012 09:36 AM, Joe Armstrong wrote: > This program has similar behaviour > > -module(bug1). > -compile(export_all). > > test(N) -> > io:format("~p~n", [N]), > test(N+1). > > I did this: > > 1 > spawn(fun() -> etop:start() end). > 2> bug1:test(0). > > You can see that user_drv global process is accumulating messages > faster than it can handle them. > It's in usr_drv:io_request/3. > > As far as I'm aware io:format did have flow control so this shouldn't happen The I/O protocol has no built-in flow control. > Now I ran with "erl -smp disable" > > The counter stays at zero forever. With only a single scheduler, it will be alternating between running the producer process and the consumer processes, but they won't be running at the same time, so the consumer has a better chance of keeping up. The number of reductions used per message is the deciding factor, and if I recall correctly, there's a built-in penalty in reductions when you pass a message to a process that already has a long queue. With multiple schedulers, the producer and the consumer will run on separate schedulers, i.e., they run on separate OS threads and reduction count doesn't matter, only actual time per message. The only thing keeping them back a little is the synchronization needed for the mailbox. It's not so surprising that it's easier to overload the consumer in this case. (Also note that the I/O protocol causes the formatting to be done on the receiver side, so if you're printing complex terms, you're making the consumer do a lot more work per message than the producer.) /Richard From robert.virding@REDACTED Thu Jul 26 01:20:49 2012 From: robert.virding@REDACTED (Robert Virding) Date: Thu, 26 Jul 2012 00:20:49 +0100 (BST) Subject: [erlang-bugs] [erlang-questions] Recursive Heap Allocation In-Reply-To: <500FA828.3030104@gmail.com> Message-ID: There is limited flow-control. An io request is sent to an io-server, in this case the default io-server group.erl. The function called by the user waits for a reply from the io-server. The io-server processes the output call, in this case the formatted output, sends it to the port and then replies back to the calling function/process. It does not wait until the output has been sent all the way to user so it can definitely overload the io output. Robert ----- Original Message ----- > On 07/25/2012 09:36 AM, Joe Armstrong wrote: > > This program has similar behaviour > > > > -module(bug1). > > -compile(export_all). > > > > test(N) -> > > io:format("~p~n", [N]), > > test(N+1). > > > > I did this: > > > > 1 > spawn(fun() -> etop:start() end). > > 2> bug1:test(0). > > > > You can see that user_drv global process is accumulating messages > > faster than it can handle them. > > It's in usr_drv:io_request/3. > > > > As far as I'm aware io:format did have flow control so this > > shouldn't happen > > The I/O protocol has no built-in flow control. > > > Now I ran with "erl -smp disable" > > > > The counter stays at zero forever. > > With only a single scheduler, it will be alternating between running > the > producer process and the consumer processes, but they won't be > running > at the same time, so the consumer has a better chance of keeping up. > The > number of reductions used per message is the deciding factor, and if > I > recall correctly, there's a built-in penalty in reductions when you > pass > a message to a process that already has a long queue. > > With multiple schedulers, the producer and the consumer will run on > separate schedulers, i.e., they run on separate OS threads and > reduction > count doesn't matter, only actual time per message. The only thing > keeping them back a little is the synchronization needed for the > mailbox. It's not so surprising that it's easier to overload the > consumer in this case. (Also note that the I/O protocol causes the > formatting to be done on the receiver side, so if you're printing > complex terms, you're making the consumer do a lot more work per > message > than the producer.) > > /Richard > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://erlang.org/mailman/listinfo/erlang-bugs >