From matthias@REDACTED Sun Jul 1 00:41:35 2007 From: matthias@REDACTED (Matthias Lang) Date: Sun, 1 Jul 2007 00:41:35 +0200 Subject: [erlang-bugs] Documentation issues In-Reply-To: <337538cb0706300300k8daa0d3s72c646ac30af1ccf@mail.gmail.com> References: <337538cb0706180047g41f38025t61d3e7152f4da724@mail.gmail.com> <4684CF6B.5070509@erix.ericsson.se> <337538cb0706300300k8daa0d3s72c646ac30af1ccf@mail.gmail.com> Message-ID: <18054.56351.717175.365318@antilipe.corelatus.se> Kirill Zaborski writes: > And then I get to http://www.erlang.org//doc/index.html and not to > http://www.erlang.org/doc/index.html as expected Going to those two URLs gets me the same page. But I failed to find a clear statement in RFC3986 about whether those two URLs are actually equivalent or not, i.e. is a conforming application supposed to treat the two as identical? Section six reads almost as though someone's describing some hacks they implemented on Friday afternoon... Maybe someone more familiar with those RFCs can enlighten me. Matthias, just curious From qrilka@REDACTED Sun Jul 1 08:17:43 2007 From: qrilka@REDACTED (Kirill Zaborski) Date: Sun, 1 Jul 2007 10:17:43 +0400 Subject: [erlang-bugs] Documentation issues In-Reply-To: <18054.56351.717175.365318@antilipe.corelatus.se> References: <337538cb0706180047g41f38025t61d3e7152f4da724@mail.gmail.com> <4684CF6B.5070509@erix.ericsson.se> <337538cb0706300300k8daa0d3s72c646ac30af1ccf@mail.gmail.com> <18054.56351.717175.365318@antilipe.corelatus.se> Message-ID: <337538cb0706302317g5de664caqc6960dee04958b1@mail.gmail.com> I'm not sure about RFC but Firefox treats URL with extra slashes as different so visited links for http://www.erlang.org//doc/index.html will be different from visited links on http://www.erlang.org/doc/index.html. Not a big issue but nonetheless It seems strange to me that it is so difficult not to include that superfluous slash in "Top" links. Regards, Kirill. On 7/1/07, Matthias Lang wrote: > > Kirill Zaborski writes: > > > And then I get to http://www.erlang.org//doc/index.html and not to > > http://www.erlang.org/doc/index.html as expected > > Going to those two URLs gets me the same page. > > But I failed to find a clear statement in RFC3986 about whether those > two URLs are actually equivalent or not, i.e. is a conforming > application supposed to treat the two as identical? Section six reads > almost as though someone's describing some hacks they implemented on > Friday afternoon... > > Maybe someone more familiar with those RFCs can enlighten me. > > Matthias, just curious > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikpe@REDACTED Mon Jul 2 11:04:37 2007 From: mikpe@REDACTED (Mikael Pettersson) Date: Mon, 2 Jul 2007 11:04:37 +0200 (MEST) Subject: [erlang-bugs] [erlang-questions] Patches for HIPE on OS X (Leopard WWDC Beta) Message-ID: <200707020904.l6294b6J003608@harpo.it.uu.se> On Sun, 1 Jul 2007 11:41:09 -0700, Brent Fulgham wrote: > I ran into problems trying to build Erlang using the Leopard Beta from > WWDC. Attached are the patches I generated to get HIPE to compile > with the new OS changes. > > Most of these patches are simply adjusting the thread and float > primitives to the new structure (under Intel, 32-bit). Someone > knowledgeable about HIPE should check them to see if they seem > reasonable. It is very likely that they will break for PowerPC and 64- > bit Intel. > > If any of the HIPE guys would like me to try variations on these > patches, I'd be happy to look into it. > > At the very least, these changes let me run various shootout tests on > my MacBook Pro. These patches look quite reasonable. The only change I don't like is this one: > --- erts/configure.in.orig 2007-06-30 19:35:17.000000000 -0700 > +++ erts/configure.in 2007-06-30 19:39:13.000000000 -0700 > @@ -1697,6 +1697,13 @@ > __asm__ __volatile__("ldmxcsr %0" : : "m"(mxcsr)); > } > > +#if defined(__DARWIN__) > +#include > +#include > +#include > +#endif > + > + > #if defined(__x86_64__) || defined(__DARWIN__) > static inline int cpu_has_sse2(void) { return 1; } > #else /* !__x86_64__ */ It includes OS-specific stuff in an OS-agnostic part of the code. I'd much prefer if you could move that to the #ifdef/#include block just before fpe_sig_action(), and make it #ifdef __DARWIN_UNIX03 like your other changes. The HiPE group doesn't have OSX/x86 development machines, so OSX/x86 support relies on contributions like this one. Most of the changes in this patch set are about enabling floating-point exceptions. This will benefit BEAM as well. /Mikael From jddcef@REDACTED Tue Jul 3 11:38:37 2007 From: jddcef@REDACTED (David e Freitas) Date: Tue, 3 Jul 2007 09:38:37 +0000 Subject: [erlang-bugs] Documentation: additions to Index In-Reply-To: <4684D054.9050605@erix.ericsson.se> References: <20070618123303.AD0455A1F7@mail.erlangsystems.com> <4684D054.9050605@erix.ericsson.se> Message-ID: That's great thanks. I've been going through some of the docs and recording things that can be repaired or updated. I will send it through in the weeks to come. For now, more index additions: Add "SMP" to the index; There are probably more keywords missing from the "erl" module in the index. Documentation is very important for people picking up the language for the first time. Python's nice documentation is probably one of the reasons why the uptake has been so great. I agree that the Modules page also needs to have the "A B C... Z" anchors at the top. -David On 6/29/07, Gunilla Arendt wrote: > Hi, > > Yes, that would be nice. I've added this to the "to do"-list > for the documentation. > > Regards, > Gunilla, Erlang/OTP team > > def wrote: > > Greetings, > > > > In the big index: > > > > /doc/permuted_index > > > > I think there should be entries in the Index for -"import" and -"export" > and other built-in keywords. > > This makes it easier for someone to find information on what these words > do and their syntax. (/doc/reference_manual/modules.html) > > > > Sincerely, > > > > > > David Freitas > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From pwa@REDACTED Thu Jul 5 07:30:53 2007 From: pwa@REDACTED (Peter Wang) Date: Thu, 5 Jul 2007 15:30:53 +1000 Subject: [erlang-bugs] hipe compiler exception Message-ID: <20070705053052.GB32490@missioncriticalit.com> Hi, HiPE at o2 throws an exception on this piece of code. It works at o1. f(A) -> case A of 0 -> B = A div 8, foo end. I'm using R11R5 on Linux/x86-64. % erlc +native break.erl EXITED with reason {{badmatch,[]}, [{hipe_icode_type,call_dst,1},{hipe_icode_type,strength_reduce_div,3}, {hipe_icode_type,handle_call_and_enter,1}, {hipe_icode_type,'-make_transformations/1-lc$^0/1-0-',1}, {hipe_icode_type,transform_bbs,2}, {hipe_icode_type,common_rewrite,4}, {hipe_main,icode_ssa_type_info,3}, {hipe_main,icode_ssa_type,3}]} @hipe:869 =ERROR REPORT==== 5-Jul-2007::15:27:26 === Error: [hipe:868]: ERROR: {{badmatch,[]}, [{hipe_icode_type,call_dst,1}, {hipe_icode_type, strength_reduce_div, 3}, {hipe_icode_type, handle_call_and_enter, 1}, {hipe_icode_type, '-make_transformations/1-lc$^0/1-0-', 1}, {hipe_icode_type,transform_bbs,2}, {hipe_icode_type, common_rewrite, 4}, {hipe_main,icode_ssa_type_info,3}, {hipe_main,icode_ssa_type,3}]} ./break.erl:none: internal error in native_compile; crash reason: {{hipe, 869, {{badmatch,[]}, [{hipe_icode_type,call_dst,1}, {hipe_icode_type,strength_reduce_div,3}, {hipe_icode_type,handle_call_and_enter,1}, {hipe_icode_type,'-make_transformations/1-lc$^0/1-0-',1}, {hipe_icode_type,transform_bbs,2}, {hipe_icode_type,common_rewrite,4}, {hipe_main,icode_ssa_type_info,3}, {hipe_main,icode_ssa_type,3}]}}, [{hipe,finalize_fun_sequential,2}, {hipe,'-finalize_fun_concurrent/2-fun-3-',3}]} Thanks. Peter From sanjaya@REDACTED Thu Jul 12 07:38:54 2007 From: sanjaya@REDACTED (Sanjaya Vitharana) Date: Thu, 12 Jul 2007 11:08:54 +0530 Subject: [erlang-bugs] [erlang-questions] inets http --- httpc_handler, retry_pipline - Bug - Patch References: <017c01c7be06$898f7570$9a0810ac@wavenet.lk> Message-ID: <074501c7c446$ef839000$9a0810ac@wavenet.lk> Hi All, This seems a Bug in inets. Refer with httpc_handler:retry_pipline/3 and http_util:key1search/3. Find the attached log part with error details. Quick Patch: httpc_handler:retry_pipline/3 785c 787 < Timer = {_, TimerRef} = http_util:key1search(RequestTimers, Request#request.id, {undefined, undefined}), --- > case lists:keysearch(Request#request.id, 1, RequestTimers) of {value, Timer} -> {_, TimerRef} = Timer; _ -> Timer = {_, TimerRef} = {undefined, undefined} end, Test Details: 1> RequestTimers = [{make_ref(),make_ref()},{make_ref(),make_ref()}]. [{#Ref<0.0.0.31>,#Ref<0.0.0.32>},{#Ref<0.0.0.33>,#Ref<0.0.0.34>}] 2> [{_,_},{RequestID,_}] = RequestTimers. [{#Ref<0.0.0.31>,#Ref<0.0.0.32>},{#Ref<0.0.0.33>,#Ref<0.0.0.34>}] 3> RequestID. #Ref<0.0.0.33> 4> Timer = {_, TimerRef} =http_util:key1search(RequestTimers, RequestID,{undefined, undefined}). =ERROR REPORT==== 9-Jul-2007::21:56:09 === Error in process <0.29.0> with exit value: {{badmatch,#Ref<0.0.0.34>},[{erl_eval,expr,3}]} ** exited: {{badmatch,#Ref<0.0.0.34>},[{erl_eval,expr,3}]} ** 5> 5> http_util:key1search(RequestTimers, RequestID,{undefined, undefined}). #Ref<0.0.0.34> 6> Thanks, Sanjaya Vitharana. ----- Original Message ----- From: Sanjaya Vitharana To: erlang-questions@REDACTED Sent: Wednesday, 04 July 2007 12:12 pm Subject: [erlang-questions] inets http --- httpc_handler, retry_pipline Hi all, Anyone has a idea about below error & why it gets with http:request(get, {URL, []}, [{timeout, ?REQUEST_TIMEOUT},{autoredirect, true}], [{sync, false}]) ??? I have get it with R11B-4 (emulator version 5.5.4 - inets-4.7.11). Is this a bug in in inets ?? regards, Sanjaya Vitharana ** Reason for termination == ** {{badmatch,#Ref<0.0.43.103898>}, [{httpc_handler,retry_pipline,2}, {httpc_handler,terminate,2}, {gen_server,terminate,6}, {proc_lib,init_p,5}]} =CRASH REPORT==== 4-Jul-2007::10:16:10 === crasher: pid: <0.25066.9> registered_name: [] error_info: {{badmatch,#Ref<0.0.43.103898>}, [{httpc_handler,retry_pipline,2}, {httpc_handler,terminate,2}, {gen_server,terminate,6}, {proc_lib,init_p,5}]} initial_call: {gen, init_it, [gen_server, <0.54.0>, <0.54.0>, httpc_handler, [{request, #Ref<0.0.43.103750>, <0.63.0>, 0, http, {"scrb.int",80}, "/vmail/vmStart.php", "?key=c&session=a1183524542772308306&ch=56&serverid=3", get, {http_request_h, undefined, "keep-alive", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, "scrb.int", undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, undefined, [], undefined, undefined, undefined, undefined, "0", undefined, undefined, undefined, undefined, undefined, undefined, []}, {[],[]}, {http_options,18000,true,[],undefined,false}, "http://scrb.int/vmail/vmStart.php?key=c&session=a1183524542772308306&ch=56&serverid=3", [], none, []}, {options,{undefined,[]},0,2,2,disabled,enabled,false}], []]} ancestors: [httpc_manager,httpc_sup,inets_sup,<0.50.0>] messages: [] links: [<0.54.0>,#Port<0.390595>] dictionary: [] trap_exit: true status: running heap_size: 4181 stack_size: 21 reductions: 12757 neighbours: ------------------------------------------------------------------------------ _______________________________________________ erlang-questions mailing list erlang-questions@REDACTED http://www.erlang.org/mailman/listinfo/erlang-questions -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: error_details.txt URL: From Bruce@REDACTED Tue Jul 17 13:34:20 2007 From: Bruce@REDACTED (Bruce Fitzsimons) Date: Tue, 17 Jul 2007 23:34:20 +1200 Subject: [erlang-bugs] inet_ssl_dist bugs in R11B-5 Message-ID: <469CA93C.3080805@Fitzsimons.org> Right, I've found the right lists now. I don't know why the standard debugging flag (ERL_SSL_DEBUG) stops erts from starting up when in ssl_dist mode, but I worked around that. There was a variety of bugs caused by the reworking of ssl to break accept into two (transport_accept and ssl_accept). I've got it working now, but I am not convinced that it is a nice as it could be. 1. There was a fault where ssl_prim was passing an FD into a function that expected a socket, but the call was wrapped in a catch and a transform to a normal error. So the 'EXIT' was masked. I'd recommend against this approach having been forced to debug through it...at least let 'EXIT' fall through? 2. The state was being stomped on in ssl_prim - it was initialised in transport_accept, then the result was initialised again (effectively) in ssl_accept. 3. badarg caused by weird options being passed to connect_proxy. A common thread though ssl_* seems to be the carriage of state around that includes options for opening a socket which are frequently touched, so the original list is lost. ssl_broker also has a bunch of "transformation" functions to remove the not applicable ones, but it seems like an odd approach. I've tried to go back to the original (R11B-0) intent of passing the original ListenPort arguments in rather than the ones modified by transport_accept. I'm not sure that this was really required, however what was required was the change (back) of one of the connection options to exclude the ssl options. Including the ssl options was an odd change to make given the name of the function was "is_tcp_accept_opt" but there may have been a reason. 4. undefined was misspelt. I think that's about it. I will post the patch to the patches list presently. I would appreciate it if a unit test for inet_dist_ssl was added to avoid this kind of thing in the future; it was quite badly busted and this is good functionality. The changes I have made may have broken normal ssl operations, so a thorough review is in order. Regards, Bruce From ulf.wiger@REDACTED Wed Jul 25 15:04:13 2007 From: ulf.wiger@REDACTED (Ulf Wiger (TN/EAB)) Date: Wed, 25 Jul 2007 15:04:13 +0200 Subject: [erlang-bugs] erl_syntax constructors too forgiving Message-ID: <6616D98C65DD514BA2E1DDC5F9223155025464D9@esealmw115.eemea.ericsson.se> Lately, I've been running into crashes in syntax_tools, whenever I try to do something interesting. The crashes tend to occur in erl_syntax:revert/1, and often on constructs that have been built using the erl_syntax constructors. The latest example is given below. After some debugging, I've found the error. I had called erl_syntax:application(Operator, Args) with a non-list as Args. Since the constructor doesn't check whether Args is in fact a list, the crash occurs within a list comprehension clause in revert instead. Apparently, the constructors are forgiving, but revert/1 is not. A few is_list/1 guards in the right places would make life much easier. (: BR, Ulf W 84> A. {application,{atom,13,np}, {tree,list, {attr,0,[],none}, {list,[{integer,13,1}], {tree,list, {attr,0,[],none}, {list,[{var,0,'V73'}],none}}}}} 85> erl_syntax:revert(A). {application,{atom,13,np}, {tree,list, {attr,0,[],none}, {list,[{integer,13,1}], {tree,list, {attr,0,[],none}, {list,[{var,0,'V73'}],none}}}}} So far, so good, but when I put a standard erl_syntax tree node around it, it goes badly (note: in practice, it's erl_syntax that inserts the tree wrapper). 86> erl_syntax:revert({tree,application,{attr,0,none},A}). =ERROR REPORT==== 25-Jul-2007::14:47:03 === Error in process <0.316.0> with exit value: {function_clause,[{erl_syntax,'-revert/1-lc$^1/1-1-',[{tree,list,{attr,0 ,[],none},{list,[{integer,13,1}],{tree,list,{attr,0,[],none},{list,[{var ,0,'V73'}],none}}}}]},{erl_syntax,'-revert/1-lc$^0/1-0-',1},{erl_syntax, '-revert/1-lc$^0/1-0-'... ** exited: {function_clause, [{erl_syntax, '-revert/1-lc$^1/1-1-', [{tree, list, {attr,0,[],none}, {list, [{integer,13,1}], {tree, list, {attr,0,[],none}, {list,[{var,0,'V73'}],none}}}}]}, {erl_syntax,'-revert/1-lc$^0/1-0-',1}, {erl_syntax,'-revert/1-lc$^0/1-0-',1}, {erl_syntax,revert,1}, {erl_eval,do_apply,5}, {shell,exprs,6}, {shell,eval_loop,3}]} ** 87> rr(code:which(erl_syntax)). [application, arity_qualifier, attr, attribute, binary_field, case_expr, class_qualifier, clause, com, comment, function, generator, infix_expr, list, list_comp, macro, match_expr, module_qualifier, prefix_expr, receive_expr, record_access, record_expr, record_field, record_index_expr, rule, size_qualifier, tree, try_expr, wrapper] 88> {tree,application,{attr,0,none},A}. #tree{ type = application, attr = {attr,0,none}, data = #application{ operator = {atom,13,np}, arguments = #tree{ type = list, attr = #attr{pos = 0,ann = [],com = none}, data = #list{ prefix = [{integer,13,1}], suffix = #tree{ type = list, attr = #attr{pos = 0,ann = [],com = none}, data = #list{prefix = [{var,0,'V73'}],suffix = none}}}}}} From mickael.remond@REDACTED Thu Jul 26 12:06:16 2007 From: mickael.remond@REDACTED (=?UTF-8?Q?Micka=C3=ABl_R=C3=A9mond?=) Date: Thu, 26 Jul 2007 12:06:16 +0200 Subject: [erlang-bugs] Dialyzer and os:version Message-ID: <3664D330-4997-4B38-AEFA-42962F00B0D8@process-one.net> Hello, Dialyzer issues a warning when matching the result of os:version: OSVersion = case os:version() of {Major, Minor, Release} -> lists:flatten( io_lib:format("~w.~w.~w", [Major, Minor, Release])); VersionString -> VersionString end, Dialyzer says on this code: The variable VersionString can never match since previous clauses completely covered the type {non_neg_integer(),non_neg_integer (),non_neg_integer()} However, the documentation of os.erl says: version() -> {Major, Minor, Release} | VersionString Dialyzer or the documentation has it wrong. This is on Erlang R11B-5. -- Micka?l R?mond http://www.process-one.net/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.kelsall@REDACTED Thu Jul 26 18:04:59 2007 From: r.kelsall@REDACTED (Richard Kelsall) Date: Thu, 26 Jul 2007 17:04:59 +0100 Subject: [erlang-bugs] Mismatch of string module and manual. to_upper, to_lower. Message-ID: <46A8C62B.1000502@millstream.com> The manual page for the string module here http://www.erlang.org/doc/man/string.html talks about functions to_lower and to_upper, but they don't seem to work in my version of erl (v5.5). (Unless I prefix them with http_util: rather than string:) I guess they have been removed from the string module because they don't work for all unicode characters, but the manual has not yet been updated. A generic fix might be for somebody clever to write a program to compare the manual entries against the functions exported from the modules and highlight differences. Or tie them together somehow. Richard. (Apologies for this appearing twice on TrapExit. I've subscribed to the list now.) From rickard.s.green@REDACTED Thu Jul 26 20:13:00 2007 From: rickard.s.green@REDACTED (Rickard Green) Date: Thu, 26 Jul 2007 20:13:00 +0200 Subject: [erlang-bugs] Mismatch of string module and manual. to_upper, to_lower. In-Reply-To: <46A8C62B.1000502@millstream.com> References: <46A8C62B.1000502@millstream.com> Message-ID: <46A8E42C.1010706@ericsson.com> The documentation under http://www.erlang.org/doc is always the documentation of the latest open source release; currently R11B-5. You are using R11B-0 (I assume you mean erts version 5.5 by "erl (v5.5)"). The to_upper and to_lower functions in the string module were introduced in R11B-4. Cut from http://www.erlang.org/download/otp_src_R11B-4.readme : OTP-6472 Added the functions to_upper/1 and to_lower/1 to the string module. These provide case conversion for ISO/IEC 8859-1 characters (Latin1) and strings. BR, Rickard Green, Erlang/OTP, Ericsson AB. Richard Kelsall wrote: > The manual page for the string module here > > http://www.erlang.org/doc/man/string.html > > talks about functions to_lower and to_upper, but they don't seem to > work in my version of erl (v5.5). (Unless I prefix them with http_util: > rather than string:) I guess they have been removed from the string > module because they don't work for all unicode characters, but the > manual has not yet been updated. > > A generic fix might be for somebody clever to write a program to > compare the manual entries against the functions exported from the > modules and highlight differences. Or tie them together somehow. > > > Richard. > > (Apologies for this appearing twice on TrapExit. I've subscribed > to the list now.) > > > _______________________________________________ > erlang-bugs mailing list > erlang-bugs@REDACTED > http://www.erlang.org/mailman/listinfo/erlang-bugs > From hpjcon@REDACTED Thu Jul 26 22:31:20 2007 From: hpjcon@REDACTED (Jan Jacobs) Date: Thu, 26 Jul 2007 22:31:20 +0200 Subject: [erlang-bugs] Runtime memory leak on Windows 2003. (beam.dll) Message-ID: <002b01c7cfc3$f074fe80$c800a8c0@jan03> Hi, I have an application and traffic generator which work on Windows 200 and XP. When I do the same tests on Windows 2003 it stops working with out generating a erl_crash.dump. The only indication to the problem is from the windows event viewer which gives the following result: Windows Event viewer: Event Type: Information Event Source: Application Error Event Category: (100) Event ID: 1004 Date: 2007/07/23 Time: 08:09:10 PM User: N/A Computer: DFG-SRV Description: Reporting queued error: faulting application erl.exe, version 0.0.0.0, faulting module beam.dll, version 0.0.0.0, fault address 0x0003c4d5. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. Data: 0000: 41 70 70 6c 69 63 61 74 Applicat 0008: 69 6f 6e 20 46 61 69 6c ion Fail 0010: 75 72 65 20 20 65 72 6c ure erl 0018: 2e 65 78 65 20 30 2e 30 .exe 0.0 0020: 2e 30 2e 30 20 69 6e 20 .0.0 in 0028: 62 65 61 6d 2e 64 6c 6c beam.dll 0030: 20 30 2e 30 2e 30 2e 30 0.0.0.0 0038: 20 61 74 20 6f 66 66 73 at offs 0040: 65 74 20 30 30 30 33 63 et 0003c 0048: 34 64 35 4d5 I then downloaded the source ad recompiled for win32 with debugging as per directions in the Readme file. Copied new executables and dlls to The Windows 2003 server. And ran the test again, with the following result: Test 1: bin\erl.exe -sname maxman -setcookie maxman -config data/maxman.config +P 65536 -env ERL_MAX_PORTS 5000 -env ERL_MAX_ETS_TABLES 3000 -env ERL_FULLSWEEP_AFTER 0 -yaws embedded true -mnesia dir '"c:/Program Files/ecs/MaxMan/data"' Error 1: Type: Access violation File: external.c Fuction: dec_term Line 935: next = (Eterm *) (*objp); Test 2: bin\erl.exe -sname maxman -setcookie maxman -config data/maxman.config +P 65536 -env ERL_MAX_PORTS 5000 -env ERL_MAX_ETS_TABLES 3000 -yaws embedded true -mnesia dir '"c:/Program Files/ecs/MaxMan/data"' Error 2: Type: Access violation File: external.c Fuction: dec_term Line 935: next = (Eterm *) (*objp); Test Box Info: OS Name Microsoft(R) Windows(R) Server 2003, Enterprise Edition Version 5.2.3790 Build 3790 OS Manufacturer Microsoft Corporation System Name DFG-SRV System Model 662/1066T-M2 System Type X86-based PC Processor x86 Family 15 Model 6 Stepping 5 GenuineIntel ~2998 Mhz Processor x86 Family 15 Model 6 Stepping 5 GenuineIntel ~2999 Mhz Hardware Abstraction Layer Version = "5.2.3790.0 (srv03_rtm.030324-2048)" Erlang Runtime: "Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [type-assertions] [debug-compiled] [lock-checking]\n" Summary: - Test 1 runs longer before it gives the access violation. - This happens when I send continuous stream of data via the TCP/IP - If no data is send via TCP/IP the application runs with out any problems. - I have noticed the erl.exe process allocates memory but never release memory when viewing the process on the Task Manager. !! The same application and test cases works on My other XP test box with out any problems (24H continuous) !! I do not know the internals of the memory allocations in erlang. Can somebody explain it to me so that I can try and find what is causing it? Any suggestions? It looks like erlang is not 2003 friendly! Thanks Jan Jacobs -------------- next part -------------- An HTML attachment was scrubbed... URL: From r.kelsall@REDACTED Fri Jul 27 15:25:22 2007 From: r.kelsall@REDACTED (Richard Kelsall) Date: Fri, 27 Jul 2007 14:25:22 +0100 Subject: [erlang-bugs] Thank you. My mistake - wrong version. [Re: Re: Mismatch of string module and manual. to_upper, to_lower.] Message-ID: <46A9F242.7020900@millstream.com> Thank you. That's clarified my confusion. I'm just on an older version than that documentation. I can get this version number : erlang:system_info(version). "5.5" And although I seem to be on R11 something I have to admit I can't immediately see how to test whether it is R11B-0, but that sounds plausible. I remember some erlang-questions mailing list thing about this but can't find the thread. Ah, yes, from my notes about my install process I see it is R11B0. Thank you. Richard. Rickard Green wrote: > > The documentation under http://www.erlang.org/doc is always the > documentation of the latest open source release; currently R11B-5. You > are using R11B-0 (I assume you mean erts version 5.5 by "erl (v5.5)"). > The to_upper and to_lower functions in the string module were > introduced in R11B-4. Cut from > http://www.erlang.org/download/otp_src_R11B-4.readme : > > OTP-6472 Added the functions to_upper/1 and to_lower/1 to the string > module. These provide case conversion for ISO/IEC 8859-1 > characters (Latin1) and strings. > > BR, > Rickard Green, Erlang/OTP, Ericsson AB. > > Richard Kelsall wrote: > > The manual page for the string module here > > > > http://www.erlang.org/doc/man/string.html > > > > talks about functions to_lower and to_upper, but they don't seem to > > work in my version of erl (v5.5). (Unless I prefix them with http_util: > > rather than string:) I guess they have been removed from the string > > module because they don't work for all unicode characters, but the > > manual has not yet been updated. > > > > A generic fix might be for somebody clever to write a program to > > compare the manual entries against the functions exported from the > > modules and highlight differences. Or tie them together somehow. > > > > > > Richard. > > > > (Apologies for this appearing twice on TrapExit. I've subscribed > > to the list now.) > > > > > > _______________________________________________ > > erlang-bugs mailing list > > erlang-bugs@REDACTED > > http://www.erlang.org/mailman/listinfo/erlang-bugs > > From matthew@REDACTED Fri Jul 27 20:54:05 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Fri, 27 Jul 2007 11:54:05 -0700 Subject: [erlang-bugs] Twisty turny gen_server hang Message-ID: I have a module: -module(bloop). -compile(export_all). start_one() -> gen_server:start({local, one}, ?MODULE, one, []). start_link_two() -> gen_server:start_link({local, two}, ?MODULE, two, []). init(one) -> start_link_two(); init(two) -> throw(burlap). When I run ``bloop:start_one()'' from the command-line, it just hangs: $ erl Erlang (BEAM) emulator version 5.5.5 [source] [async-threads:0] [kernel-poll:false] Eshell V5.5.5 (abort with ^G) 1> bloop:start_one(). (^-- hanging) Instead I expect it to evaluate to ``{error,{bad_return_value,burlap}}''. My reasoning: ``bloop:start_link_two()'' causes the calling process to exit with ``{bad_return_value,burlap}'', and if I change ``init(one)'' to just ``exit({bad_return_value,burlap})'', that is the return value for ``bloop:start_one()''. From matthew@REDACTED Fri Jul 27 22:30:45 2007 From: matthew@REDACTED (Matthew Dempsky) Date: Fri, 27 Jul 2007 13:30:45 -0700 Subject: [erlang-bugs] Twisty turny gen_server hang In-Reply-To: References: Message-ID: Here's a simpler test case: -module(bloop2). -compile(export_all). start() -> gen_server:start(?MODULE, [], []). init([]) -> exit(self(), burlap). The cause seems to be that proc_lib:sync_wait/2 expects to receive an EXIT message if Pid exits, but proc_lib:start* is often called from contexts where the trap_exit flag is unset (e.g., gen_server). From elharaty@REDACTED Fri Jul 27 23:46:08 2007 From: elharaty@REDACTED (Emad El-Haraty) Date: Fri, 27 Jul 2007 14:46:08 -0700 Subject: [erlang-bugs] Twisty turny gen_server hang In-Reply-To: References: Message-ID: On 7/27/07, Matthew Dempsky wrote: > Here's a simpler test case: > > -module(bloop2). > -compile(export_all). > > start() -> > gen_server:start(?MODULE, [], []). > > init([]) -> > exit(self(), burlap). > The simplest reproduction of this hanging problem is: proc_lib:start(erlang, exit, [die]). proc_lib is expecting to receive either an ack or 'EXIT' but since the process is not linked to anything, it will never receive the 'EXIT'. Setting up proc_lib to use a monitor of some sort should allow proc_lib to catch DOWN which would then produce the appropriate behavior. From dmitry.kargapolov@REDACTED Tue Jul 31 23:10:07 2007 From: dmitry.kargapolov@REDACTED (Dmitriy Kargapolov) Date: Tue, 31 Jul 2007 17:10:07 -0400 Subject: [erlang-bugs] System messages documentation Message-ID: <46AFA52F.2070101@corp.idt.net> I'm not sure about whole chapter describing module sys, but at least format of get_modules message and its expected reply should be fixed. The document said: "This message is {get_modules, From}. The reply to this message is From ! {modules, Modules}, where Modules is a list of the currently active modules in the process." But actually message pattern is: {Label, {From, MRef}, get_modules}, and response should be in form {MRef, Modules}, where Label in current implementation seems to be equal to From, and MRef is reference (used internally, returned by erlang:monitor/2).