From alexey@REDACTED Sat Feb 5 15:49:29 2005 From: alexey@REDACTED (Alexey Shchepin) Date: Sat, 05 Feb 2005 16:49:29 +0200 Subject: statistics(wall_clock) Message-ID: <87acqjhxja.fsf@alex.sevcom.net> Hi! The BIF statistics(wall_clock) returns the following tuple: {Total_Wallclock_Time, Wallclock_Time_Since_Last_Call}. But after less than 50 days of uptime (exact value is 2^32/(1000*60*60*24)), Total_Wallclock_Time starts to count time from zero, which I believe is not very suitable for most of long-lived tasks. Erlang R10B, FreeBSD 5.2rc2, i386 architecture. From brian@REDACTED Wed Feb 9 22:16:45 2005 From: brian@REDACTED (Brian Buchanan) Date: Wed, 9 Feb 2005 13:16:45 -0800 (PST) Subject: HIPE bug in indirect function calls Message-ID: <20050209131135.K43618@mail.ncircle.com> HIPE doesn't seem to handle indirect function calls. The following works fine when compiled without +native, and fails when compiled with. It doesn't matter if the function being called is part of the same module or is in a different module. This bug was observed with R10B-2 on FreeBSD 5.3/i386. -module(native_test). -export([test/0, func/0]). test() -> F = {?MODULE, func}, (F)(). func() -> ok. Erlang (BEAM) emulator version 5.4.3 [source] [hipe] [threads:0] Eshell V5.4.3 (abort with ^G) 1> c(native_test). {ok,native_test} 2> native_test:test(). ok 3> c(native_test, native). {ok,native_test} 4> native_test:test(). =ERROR REPORT==== 9-Feb-2005::13:13:15 === Error in process <0.29.0> with exit value: {{badfun,{native_test,func}},[]} ** exited: {{badfun,{native_test,func}},[]} ** -- Brian Buchanan Principal Engineer nCircle Network Security http://www.ncircle.com/ From benno@REDACTED Thu Feb 10 01:59:37 2005 From: benno@REDACTED (Benno Rice) Date: Thu, 10 Feb 2005 11:59:37 +1100 Subject: Erlang on FreeBSD/amd64 Message-ID: <420AB1F9.3050203@jeamland.net> (Originally posted on erlang-questions, apologies to those who've seen it twice) Hi, I've recently been looking at using erlang for a project I'm working on but ran into a bit of a roadblock when I discovered that erlang hasn't been ported to FreeBSD/amd64 yet. I've tried building it and also generated some patches (attached) which should sort out some floating point exception issues (otherwise the build hangs in configure), but the build runs into some problems trying to compile erlang code with erlc. Errors I've seen are shown below along with some of the files they were seen in. I got the list by removing the named files from the build as I found them, so this may cause problems in and of itself and I wasn't able to proceed in the build eventually due to yeccparse being one of the affected files. As well as the three shown below, I've also seen erlc catch bus error signals. There appears to be some level of unrepeatability as can be seen by the fact that one of the files (cerl_to_icode.erl) saw two different types of error. Can anyone point me at a good place to start to track down and fix these problems? My main issue is one of not being at all familiar with the erlang/OTP codebase. I'm using the most recent FreeBSD port which includes a few other patches. These can be obtained from a FreeBSD installation or from: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/erlang/files/ I'm trying to build this on FreeBSD/amd64 6-CURRENT. Many thanks, Benno. Crash type 1 (most common): erlc -W +debug_info -I../include -o../ebin application_controller.erl =ERROR REPORT==== 4-Feb-2005::10:57:39 === Error in process <0.22.0> with exit value: {{badrecord,epp},[{epp,scan_toks,2}]} ./application_controller.erl:none: internal error in parse_module; crash reason: {{badrecord,epp},[{epp,scan_toks,2}]} Crash type 2 (unfortunately I accidentally deleted the dump): erlc -W +debug_info +nowarn_shadow_vars -o../ebin cerl_to_icode.erl Crash dump was written to: erl_crash.dump eheap_alloc: Cannot allocate 1880844493888946480 bytes of memory (of type "heap_frag"). Crash type 3: erlc -W +debug_info +nowarn_shadow_vars -o../ebin hipe_icode_pp.erl gmake[3]: *** [../ebin/hipe_icode_pp.beam] Segmentation fault (core dumped) The files that have seen crash type 1 are: lib/kernel/src/application_controller.erl lib/parsetools/src/yeccparser.erl lib/asn1/src/asn1ct_check.erl lib/asn1/src/asn1rt_per.erl lib/hipe/cerl/cerl_to_icode.erl lib/hipe/cerl/cerl_cconv.erl lib/hipe/cerl/cerl_messagean.erl lib/hipe/cerl/erl_bif_types.erl lib/hipe/cerl/cerl_closurean.erl lib/hipe/icode/hipe_beam_to_icode.erl lib/hipe/icode/hipe_icode_primops.erl lib/hipe/icode/hipe_icode_type.erl The files that have seen crash type 2 are: lib/hipe/cerl/cerl_to_icode.erl The files that have seen crash type 3 are: lib/hipe/icode/hipe_icode_pp.erl -- Benno Rice benno@REDACTED http://jeamland.net -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-erts_emulator_sys_unix_sys_float.c URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: patch-erts_configure.in URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 254 bytes Desc: OpenPGP digital signature URL: From brian@REDACTED Thu Feb 10 07:03:27 2005 From: brian@REDACTED (Brian Buchanan) Date: Wed, 9 Feb 2005 22:03:27 -0800 (PST) Subject: Erlang on FreeBSD/amd64 In-Reply-To: <420AB1F9.3050203@jeamland.net> References: <420AB1F9.3050203@jeamland.net> Message-ID: <20050209215242.N56787@mail.ncircle.com> Benno, I just did a little investigative work on this. Here's an error I get: =ERROR REPORT==== 9-Feb-2005::21:47:41 === Error in process <0.22.0> with exit value: {badarg,[{erlang,demonitor,[{}]},{io,wait_io_mon_reply,2},{epp,scan_toks,2}]} ./disk_log.erl:none: internal error in parse_module; crash reason: {badarg,[{erlang,demonitor,[{}]}, {io,wait_io_mon_reply,2}, {epp,scan_toks,2}]} I instrumented the bootstrap version of the io module and discovered what appears to be reference corruption in the interpreter after a process waits in "receive". My modified "io" prints out {monitor, MRef} after the call to erlang:monitor in io:receive, {wait_io_mon_reply,MRef} at the top of wait_io_mon_reply(), and {demonitor, MRef} right before the call to erlang:demonitor(). The output should look like a bunch of: {monitor,#Ref<0.0.0.122>} {wait_io_mon_reply,#Ref<0.0.0.122>} {demonitor,#Ref<0.0.0.122>} {monitor,#Ref<0.0.0.124>} {wait_io_mon_reply,#Ref<0.0.0.124>} {demonitor,#Ref<0.0.0.124>} etc. And that's what I get for the first many iterations. Then: {monitor,#Ref<0.0.0.178>} {wait_io_mon_reply,#Ref<0.0.0.178>} {demonitor,{}} (crash!) Here's the first fragment of io:wait_mon_reply/2 so you can see my modifications. wait_io_mon_reply(From, Mref) when is_reference(Mref) -> erlang:display({wait_io_mon_reply, Mref}), receive {io_reply,From,Reply} -> erlang:display({demonitor, Mref}), erlang:demonitor(Mref), receive {'DOWN', Mref, _, _, _} -> true after 0 -> true I made a few more tweaks after this to try to figure out if the interpreter stack was being clobbered, but determined that the "From" variable and any new variables I defined before the receive were not affected. I suspect something is broken in the implementation of references. Unfortunately, I have no real experience with the beam interpreter, and at this point am not even sure how to get it running in gdb, so I must appeal to someone more knowledgeable to provide some guidance here. - Brian -- Brian Buchanan Principal Engineer nCircle Network Security http://www.ncircle.com/ From benno@REDACTED Thu Feb 10 12:18:27 2005 From: benno@REDACTED (Benno Rice) Date: Thu, 10 Feb 2005 22:18:27 +1100 Subject: Erlang on FreeBSD/amd64 In-Reply-To: <20050209215242.N56787@mail.ncircle.com> References: <420AB1F9.3050203@jeamland.net> <20050209215242.N56787@mail.ncircle.com> Message-ID: <420B4303.7080808@jeamland.net> Brian Buchanan wrote: > Benno, > > I just did a little investigative work on this. Here's an error I get: > > =ERROR REPORT==== 9-Feb-2005::21:47:41 === > Error in process <0.22.0> with exit value: > {badarg,[{erlang,demonitor,[{}]},{io,wait_io_mon_reply,2},{epp,scan_toks,2}]} > > ./disk_log.erl:none: internal error in parse_module; > crash reason: {badarg,[{erlang,demonitor,[{}]}, > {io,wait_io_mon_reply,2}, > {epp,scan_toks,2}]} > > > I instrumented the bootstrap version of the io module and discovered what > appears to be reference corruption in the interpreter after a process > waits in "receive". [snip] I tried following your suggestions but I wasn't able to work out how to modify the bootstrap versions. I assume I'd need to recompile them somehow? Editing the .erl files containing scan_toks/2 doesn't appear to get me any extra debug output. -- Benno Rice benno@REDACTED http://jeamland.net/ From brian@REDACTED Thu Feb 10 17:38:57 2005 From: brian@REDACTED (Brian Buchanan) Date: Thu, 10 Feb 2005 08:38:57 -0800 (PST) Subject: HIPE bug in indirect function calls In-Reply-To: <20050210124120.BE256B91F2@gorgon.vtab.com> References: <20050210124120.BE256B91F2@gorgon.vtab.com> Message-ID: <20050210083451.A56787@mail.ncircle.com> On Thu, 10 Feb 2005, Erik Stenman wrote: > No, Hipe doesn't handle this type of call. > This is not a bug though, such calls will > be fobidden in Erlang as well at some time > in the future. [snip] > F = fun() -> ?MODULE:func() end, > (F)(). Thanks. I did this, and it works fine now. But I'll take the same hard line with you that my QA department would take with me and ask: if this isn't a bug, is there some documentation that defines everything that's different between Erlang and HiPE Erlang? ;-) - Brian From brian@REDACTED Fri Feb 11 00:43:24 2005 From: brian@REDACTED (Brian Buchanan) Date: Thu, 10 Feb 2005 15:43:24 -0800 (PST) Subject: Erlang on FreeBSD/amd64 In-Reply-To: <420B4303.7080808@jeamland.net> References: <420AB1F9.3050203@jeamland.net> <20050209215242.N56787@mail.ncircle.com> <420B4303.7080808@jeamland.net> Message-ID: <20050210154144.O69941@mail.ncircle.com> > I tried following your suggestions but I wasn't able to work out how to > modify the bootstrap versions. I assume I'd need to recompile them > somehow? Editing the .erl files containing scan_toks/2 doesn't appear > to get me any extra debug output. You have to recompile the .erl files using a working erlc (I used a FreeBSD/i386 machine and copied the .beam files over). Put the replacement beam files in boostrap/lib/stdlib/ebin/ or where appropriate. - Brian From erik.ej.reitsma@REDACTED Mon Feb 14 11:13:43 2005 From: erik.ej.reitsma@REDACTED (Erik Reitsma EJ (RY/ETM)) Date: Mon, 14 Feb 2005 11:13:43 +0100 Subject: xmerl and iso-8859-1 Message-ID: <110BA8ACEE682C479D0B008B6BE4AEB10C13EF@esealmw107.eemea.ericsson.se> Hi, The ucs module in the xmerl-1.0 app handles messages with iso_8859-1 as encoding, but not iso-8859-1 (with dash instead of underscore), although this is a valid alias. Ths fix is trivial on line 350 of ucs.erl Regards, *Erik. From klacke@REDACTED Tue Feb 15 14:36:36 2005 From: klacke@REDACTED (klacke@REDACTED) Date: Tue, 15 Feb 2005 14:36:36 +0100 Subject: inet driver bug Message-ID: <20050215133636.GA22730@hyber.org> Hi, Just had a debug session with Tobbe and Johan B. They've written some kind of javascript chat program for yaws. Anyway, it didn't work on vanilla R10_x and we were debugging the thing. It worked just fine on our local/cvs based erlangs ... all versions. It turned out to be a fix which I've sent to you before (years ago) which was still in our CVS but apparently not yet incorportaded. Sorry if patch is not dirctly applicable, but we have quite a lot of other stuff in the inet_driver which garbles the patch. inet_drv.c @@ -1980,7 +1979,7 @@ int c; /* start-line = Request-Line | Status-Line */ if (n == 0) - return 0; + return -1; h = 0; meth_ptr = ptr; Pretty serious. Cheers /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From klacke@REDACTED Wed Feb 16 14:20:04 2005 From: klacke@REDACTED (klacke@REDACTED) Date: Wed, 16 Feb 2005 14:20:04 +0100 Subject: inet driver bug In-Reply-To: <20050215133636.GA22730@hyber.org> References: <20050215133636.GA22730@hyber.org> Message-ID: <20050216132004.GA4366@hyber.org> On Tue, Feb 15, 2005 at 02:36:36PM +0100, klacke@REDACTED wrote: > > Hi, > > > Just had a debug session with Tobbe and Johan B. > They've written some kind of javascript chat program for yaws. > Anyway, it didn't work on vanilla R10_x and we were debugging > the thing. It worked just fine on our local/cvs based > erlangs ... all versions. > > It turned out to be a fix which I've sent to you before > (years ago) which was still in our CVS but apparently not > yet incorportaded. I dug up the old bugreports of mine, First one is: http://article.gmane.org/gmane.comp.lang.erlang.patches/2 and second one (the correct one) is: http://article.gmane.org/gmane.comp.lang.erlang.patches/3 Cheers (and let me know what you plan to do with this since HTTP servers/clients (especially yaws) behave bad without this bugfix) /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From klacke@REDACTED Wed Feb 16 14:32:46 2005 From: klacke@REDACTED (klacke@REDACTED) Date: Wed, 16 Feb 2005 14:32:46 +0100 Subject: inet driver bug In-Reply-To: <20050216132004.GA4366@hyber.org> References: <20050215133636.GA22730@hyber.org> <20050216132004.GA4366@hyber.org> Message-ID: <20050216133246.GA4435@hyber.org> On Wed, Feb 16, 2005 at 02:20:04PM +0100, klacke@REDACTED wrote: > On Tue, Feb 15, 2005 at 02:36:36PM +0100, klacke@REDACTED wrote: > > > > Hi, > > > > > > Just had a debug session with Tobbe and Johan B. > > They've written some kind of javascript chat program for yaws. > > Anyway, it didn't work on vanilla R10_x and we were debugging > > the thing. It worked just fine on our local/cvs based > > erlangs ... all versions. > > > > It turned out to be a fix which I've sent to you before > > (years ago) which was still in our CVS but apparently not > > yet incorportaded. > > > > I dug up the old bugreports of mine, > Talking to myself ... Dug further, and it turns out that inet_drv.c bug is actually triggered by a bug in firefox. It send's pipelined requests with an additional CRNL after the first request (which is a POST) This _exactly_ gets the inet driver into the bad state. Boring ... /klacke -- Claes Wikstrom -- Caps lock is nowhere and http://www.hyber.org -- everything is under control From benno@REDACTED Thu Feb 17 14:14:13 2005 From: benno@REDACTED (Benno Rice) Date: Fri, 18 Feb 2005 00:14:13 +1100 Subject: Erlang on FreeBSD/amd64 In-Reply-To: <20050210154144.O69941@mail.ncircle.com> References: <420AB1F9.3050203@jeamland.net> <20050209215242.N56787@mail.ncircle.com> <420B4303.7080808@jeamland.net> <20050210154144.O69941@mail.ncircle.com> Message-ID: <421498A5.6020002@jeamland.net> Brian Buchanan wrote: >>I tried following your suggestions but I wasn't able to work out how to >>modify the bootstrap versions. I assume I'd need to recompile them >>somehow? Editing the .erl files containing scan_toks/2 doesn't appear >>to get me any extra debug output. > > > You have to recompile the .erl files using a working erlc (I used a > FreeBSD/i386 machine and copied the .beam files over). Put the > replacement beam files in boostrap/lib/stdlib/ebin/ or where appropriate. Ok, latest stage is that I've gotten as far as instrumenting size_object in erts/emulator/beam/copy.c and discovered that at some point, when being called in the lead up to the following (caused by a segmentation fault): #0 0x0000000000446049 in copy_struct (obj=13805914, sz=67108887, hpp=0x7fffffffd4c8, off_heap=0x7e2378) at beam/copy.c:419 #1 0x000000000044f45d in queue_monitor_message (p=0x7e2178, ref=8327066, type=15627, item=355, reason=34373646266) at beam/bif.c:318 #2 0x000000000046506e in doit_exit_monitor (mon=0x7f0f68, vpcontext=0x7fffffffd880) at beam/erl_process.c:1304 #3 0x00000000004b15d8 in erts_sweep_monitors (root=0x0, doit=0x464e00 , context=0x7fffffffd880) at beam/erl_monitors.c:692 #4 0x000000000046571c in do_exit (p=0x7e23b8, reason=34373646266) at beam/erl_process.c:1459 #5 0x00000000004c5254 in terminate_proc (c_p=0x7e23b8, Value=34373646266) at beam/beam_emu.c:4203 #6 0x00000000004c5000 in handle_error (c_p=0x7e23b8, pc=0x90dc68, reg=0x663080, bf=0x44ef40) at beam/beam_emu.c:4143 #7 0x00000000004bac31 in process_main () at beam/beam_emu.c:1961 #8 0x000000000042f5c5 in erl_start (argc=30, argv=0x7fffffffe020) at beam/erl_init.c:855 #9 0x000000000041a3a9 in main (argc=13907898, argv=0x4000017) at sys/unix/erl_main.c:28 that in size_object, I'm ending up with an object whose primary_tag is TAG_PRIMARY_BOXED but whose header value ends up being 0xffffffff. Is this at all expected? It appears to cause thing_arityval to return a bogus value but I'm not sure. Am I on the right track here? Or is there somewhere else I should look? -- Benno Rice benno@REDACTED http://jeamland.net/ From bertil@REDACTED Fri Feb 18 09:42:08 2005 From: bertil@REDACTED (Bertil Karlsson) Date: Fri, 18 Feb 2005 09:42:08 +0100 Subject: xmerl and iso-8859-1 References: <110BA8ACEE682C479D0B008B6BE4AEB10C13EF@esealmw107.eemea.ericsson.se> Message-ID: <4215AA60.4010501@erix.ericsson.se> Thank you, it is corrected. /Bertil Erik Reitsma EJ RY/ETM wrote: > Hi, > > The ucs module in the xmerl-1.0 app handles messages with iso_8859-1 as encoding, but not iso-8859-1 (with dash instead of underscore), although this is a valid alias. Ths fix is trivial on line 350 of ucs.erl > > Regards, > *Erik. > From jahakala@REDACTED Fri Feb 18 12:57:04 2005 From: jahakala@REDACTED (Jani Hakala) Date: Fri, 18 Feb 2005 13:57:04 +0200 Subject: Bug in xmerl_scan or xmerl_eventp? Message-ID: <871xbershb.fsf@pingviini.kortex.jyu.fi> Hi, When I try to parse an xml-file using xmerl_eventp:file_sax I get an error about badarg in xmerl_scan:scan_prolog (around line 602) {Decl,T2, S2}=scan_xml_decl(T, S), Encoding=Decl#xmlDecl.encoding This happens only if there's at the beginning of my xml file. scan_xml_decl seems to call return_xml_decl after "?>". return_xml_decl calls hook_fun that calls xmerl:export_element, which returns CBstate in case of #xmlDecl. hook_fun returns {CBstate,xmerl_scan:user_state({CBs,CBstate},S)} so in return_xml_decl {Ret, S3} = Hook(Decl, S2), {Ret, T1, S3}. Ret is now something else than a #xmlDecl, so Decl#xmlDecl.encoding fails later in scan_prolog. I'm using debian packaged erlang 10.b.1a-2. ucs.erl:-vsn('0.3'). xmerl_eventp.erl:-vsn('0.19'). xmerl_scan.erl:-vsn('0.20'). xmerl_validate.erl:-vsn('0.1'). xmerl_xlate.erl:-vsn('0.6'). xmerl_xpath.erl:-vsn('0.13'). xmerl_xpath_pred.erl:-vsn('0.6'). xmerl_xpath_scan.erl:-vsn('0.6'). xmerl_xs.erl:-vsn('0.19'). xmerl_eventp.erl:-date('03-09-17'). xmerl_scan.erl:-date('03-09-16'). xmerl_validate.erl:-date('27-11-02'). xmerl_xlate.erl:-date('00-09-22'). xmerl_xpath.erl:-date('01-02-21'). xmerl_xpath_pred.erl:-date('00-09-22'). xmerl_xpath_scan.erl:-date('00-09-21'). xmerl_xs.erl:-date('03-02-03'). Jani Hakala From gosta.ask@REDACTED Wed Feb 23 15:22:16 2005 From: gosta.ask@REDACTED (=?ISO-8859-1?Q?=22G=F6sta_Ask_=28Mobile_Arts=29=22?=) Date: Wed, 23 Feb 2005 15:22:16 +0100 Subject: Setting/changing wildcards for ets in a nested record Message-ID: <421C9198.2050804@mobilearts.se> Hi, I found a problem when I wrote a routine to set all fields in a nested record to the special value '_'. Part of the demo code: P = #person{}, R = set_deep_underscore(P), {R, R#person{names = #name{last="Virding"}}}. which gives the following output: Erlang (BEAM) emulator version 5.3.6.2 [source] [hipe] Eshell V5.3.6.2 (abort with ^G) 196> person:demo(). {{person,{name,'_','_','_'},'_',{addr,'_','_',{town,'_','_'}},'_','_'}, {person,{name,undefined,undefined,"Virding"}, '_', {addr,'_','_',{town,'_','_'}}, '_', '_'}} 197> How come the first two fields in the #name record get set to 'undefined'? I had hoped that all fields that are not referred to would get copies of their old values when a new record is created. Instead fields that are not referred in the record where a change takes place (setting last = "Virding" in this example) get new values from the default setting. The default is 'undefined'. This was a bit confusing. Is the behavior intentional? Or unavoidable? I stumbled on this thing when I checked if I could use the cool shortcut P = #person{_ = '_'}, for testing purposes. Comparing an actual record output from a Test Object with an expected record prepared in advance, that is. For testing purposes it is nice to start with a record with wildcards. The record can be used as a pattern in ets:match_object/2 after the records output from the test object have been inserted into an ets table. To be flexible it must be possible to set each individual field in the test record to a specific value before the test is performed. With the present behavior I will have to resort to setting all fields explicitly = '_' in the record definition. This means a lot of extra keyboard work since this records are quite large. rgds, G?sta Ask (Mobile Arts) Here is the routine to traverse a record and set all fields = '_', assuming that the parameter Rec is a record represented as a tuple. ==================================================================== set_deep_underscore(Rec) -> [RecName|Fields] = tuple_to_list(Rec), traverse(Fields, [RecName]). traverse([], L) -> list_to_tuple(lists:reverse(L)); traverse([H|T], [LH|LT]) when is_tuple(H) -> traverse(T, [set_deep_underscore(H),LH|LT]); traverse([_|T], L) -> traverse(T, ['_'|L]). And here are the record definitions =================================== -module(person). -export([demo/0]). -record(name, {first,middle,last}). -record(addr, {nr,street,city}). -record(town, {code,size}). -record(person, {names = #name{}, phone, address = #addr{city = #town{}}, age, job}). From vlad_dumitrescu@REDACTED Wed Feb 23 16:16:37 2005 From: vlad_dumitrescu@REDACTED (Vlad Dumitrescu) Date: Wed, 23 Feb 2005 16:16:37 +0100 Subject: Setting/changing wildcards for ets in a nested record References: <421C9198.2050804@mobilearts.se> Message-ID: ----- Original Message ----- From: "G?sta Ask (Mobile Arts)" > P = #person{}, > R = set_deep_underscore(P), > {R, R#person{names = #name{last="Virding"}}}. Hi, You should use {R, R#person{names = (R#person.names)#name{last="Virding"}}}. Otherwise, a new #name record is created, where the unnamed fields have the value 'undefined'. best regards, Vlad