From Erik.Reitsma@REDACTED Fri Jul 4 09:28:33 2003 From: Erik.Reitsma@REDACTED (Erik Reitsma (RY/ETM)) Date: Fri, 4 Jul 2003 09:28:33 +0200 Subject: ASN.1 problem with ObjectDescriptor Message-ID: <440A2703A54A8F4FB2AC2AE34F27129D215AC7@ESEALNT889.al.sw.ericsson.se> Hi, The BER compiler and runtime cannot deal with elements of type ObjectDescriptor because it is spelled 'OBJECT DESCRIPTOR' (instead of the correct 'ObjectDescriptor') in files asn1ct_gen_ber_v2.erl, asn1ct_gen_ber.erl and asn1rt_ber_bin.erl, once in each file. Replacing 'OBJECT DESCRIPTOR' with 'ObjectDescriptor' in these files solved the problem for me. Regards, *Erik. Erik Reitsma System Engineer, Technology Strategies Service Network and Applications Ericsson Telecommunicatie B.V. Research and Development Tel.: +31 161 242582 Fax: +31 161 242206 erik.reitsma@REDACTED http://www.ericsson.nl From lll@REDACTED Mon Jul 14 10:44:36 2003 From: lll@REDACTED (=?GB2312?B?yO28/srU08M=?=) Date: Mon, 14 Jul 2003 16:44:36 +0800 Subject: =?GB2312?B?sLLGvbzytaXP+srbudzA7cjtvP4zMDAuMDDUqg==?= Message-ID: <200307140844.h6E8iYq60019@hades.cslab.ericsson.net> An HTML attachment was scrubbed... URL: From Zoltan.Toth@REDACTED Wed Jul 16 13:52:02 2003 From: Zoltan.Toth@REDACTED (Zoltan Peter Toth) Date: Wed, 16 Jul 2003 13:52:02 +0200 Subject: module reload problem in erl Message-ID: <3F153C62.3000008@eth.ericsson.se> Hi, I've found a problem which happens on Solaris (e.g. version 5.2.3.1) and Linux (e.g. 5.2.3.3) similarly, described below. I attached my simple test program, which manages a sorted list. Do you think this is a bug in the Erlang virtual machine ? Thanks for any info, Zoltan --------------------------------------------------------------------- Problem: c:c(Module) for the 2nd time kills/loses the existing instance of the process in the erl shell. (The same problem exists if I recompile with erlc and load with l(Module).) Erlang (BEAM) emulator version 5.2.3.1 Compiled on Fri Feb 7 08:42:17 2003 1> sl:start(). true 2> process_info(whereis(listStore)). [{registered_name,listStore}, {current_function,{sl,listLoop,1}}, {initial_call,{sl,listLoop,1}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[]}, {dictionary,[]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.21.0>}, {heap_size,233}, {stack_size,4}, {reductions,1}, {garbage_collection,[{fullsweep_after,65535}]}] 4> sl:getList(). getList from <0.29.0> [] 5> sl:addElem({lali,1}). insert of lali, 1 {insert,{lali,1}} 6> sl:getList(). getList from <0.29.0> [{lali,1}] %% Recompile for the 1st time: 7> c:c(sl). {ok,sl} %% Now the process is still alive (and holds the data): 8> process_info(whereis(listStore)). [{registered_name,listStore}, {current_function,{sl,listLoop,1}}, {initial_call,{sl,listLoop,1}}, {status,waiting}, {message_queue_len,0}, {messages,[]}, {links,[]}, {dictionary,[]}, {trap_exit,false}, {error_handler,error_handler}, {priority,normal}, {group_leader,<0.21.0>}, {heap_size,233}, {stack_size,4}, {reductions,60}, {garbage_collection,[{fullsweep_after,65535}]}] %% Compile & load again: 9> c:c(sl). {ok,sl} %% But now the process has died: 10> process_info(whereis(listStore)). =ERROR REPORT==== 16-Jul-2003::11:39:06 === Error in process <0.29.0> with exit value: {badarg,[{erlang,process_info,[undefined]},{erl_eval,expr,3},{erl_eval,exprs,4},{shell,eval_loop,2}]} ** exited: {badarg,[{erlang,process_info,[undefined]}, {erl_eval,expr,3}, {erl_eval,exprs,4}, {shell,eval_loop,2}]} ** -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sl.erl URL: From Erik.Stenman@REDACTED Wed Jul 16 22:41:01 2003 From: Erik.Stenman@REDACTED (Erik Stenman) Date: Wed, 16 Jul 2003 22:41:01 +0200 Subject: module reload problem in erl In-Reply-To: <3F153C62.3000008@eth.ericsson.se> Message-ID: <003c01c34bda$91ba8660$2101a8c0@lamppc36> > Hi, > > I've found a problem which happens on Solaris (e.g. version > 5.2.3.1) and Linux (e.g. 5.2.3.3) similarly, described below. > I attached my simple test program, which manages a sorted list. > > Do you think this is a bug in the Erlang virtual machine ? No this is the intended behavior. When you compile the module in the shell a new version of the module is loaded. The previous version of the module which is used by the code in your server is marked as old. The second time you compile a third version of your module gets loaded, but the runtime system will not let you have more than two versions of a module loaded at a time. (This is to prevent you from running old code by mistake.) In order to enforce this all processes who have references to the old code will be killed. To keep your process alive you will need to force it to switch to new code (this is done by a fully qualified call). Example: ... listLoop(L) -> receive {insert, {Key,Value}} -> ... code_update -> ?MODULE:listLoop(L) end. update() -> listStore ! code_update, ok. ... Now you can migrate your server to new code by calling sl:update() after a recompile. A better practice for servers is to replace all recursive calls by fully qualified calls: listLoop(L) -> receive {insert, {Key,Value}} -> io:format("insert of ~w, ~w~n", [Key,Value]), ?MODULE:listLoop(insert({Key,Value}, L)); {P, getList} -> io:format("getList from ~w~n", [P]), P ! L, ?MODULE:listLoop(L); shutdown -> io:format("Castle of arrrrgggh...~n", []), unregister(listStore), exit(normal); code_update -> ?MODULE:listLoop(L) end. A problem with both these solutions is that you might need to update the data in the server when you have loaded new code. You could do this as: A better practice for servers is to replace all recursive calls by fully qualified calls: listLoop(L) -> receive {insert, {Key,Value}} -> io:format("insert of ~w, ~w~n", [Key,Value]), ?MODULE:listLoop(insert({Key,Value}, L)); {P, getList} -> io:format("getList from ~w~n", [P]), P ! L, ?MODULE:listLoop(L); shutdown -> io:format("Castle of arrrrgggh...~n", []), unregister(listStore), exit(normal); code_update -> %% Call this to prepare for an update. %% Wait for the new code to be loaded. receive update_done -> ?MODULE:listLoop(?MODULE:update_data(L)) end end. update_data(L) -> L. pre_update() -> listStore ! code_update, ok. after_update() -> listStore ! update_done, ok. ... Now you can safely do: > sl:pre_update(),c(sl),sl:after_update(). Or you can use OTPs more general behaviour for a server, but that is a lesson for some other time... /Erik -------------------------------------- Eric Conspiracy Secret Laboratories I'm Happi, you should be happy. Praeterea censeo "0xCA" scribere Erlang posse. From anders_nygren2002@REDACTED Thu Jul 24 03:03:05 2003 From: anders_nygren2002@REDACTED (=?iso-8859-1?q?Anders=20Nygren?=) Date: Thu, 24 Jul 2003 03:03:05 +0200 (CEST) Subject: compiler and debugger bugs, R9B-1, Windows XP Home Edition Message-ID: <20030724010305.34259.qmail@web14612.mail.yahoo.com> I have found two bugs in R9B-1 on Windows XP Home Edition. The first crashes the compiler. The following little program demonstrates it. --------------------------------------------------------------- -module(bug). -export([bug/0]). -record(rec,{f1}). test()-> #rec{f1=queue.new()}. --------------------------------------------------------------- 133> c(bug). ./bug.erl:none: internal error in beam_clean; crash reason: {{case_clause,{'EXIT',{function_clause, [{dict,fetch_val,[4,[]]}, {beam_clean,find_all_used,3}, {beam_clean,module,2}, {compile, '-select_passes/2-anonymous-2-', 2}, {compile, '-internal_comp/4-anonymous-1-', 2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]}}}, [{compile,'-select_passes/2-anonymous-2-',2}, {compile,'-internal_comp/4-anonymous-1-',2}, {compile,fold_comp,3}, {compile,internal_comp,4}, {compile,internal,3}]} error --------------------------------------------------------------- The second bug crashes the debugger. 1, start the debugger 2, move the monitor window so that a part of the Title bar of the window is outside the screen. 3, move the mouse pointer down into the monitor window again. 134> debugger:start(). {ok,<0.439.0>} 135> =ERROR REPORT==== 23-Jul-2003::19:33:33 === Error in process <0.439.0> with exit value: {badarith,[{dbg_ui_mon_win,handle_ev ent,2},{dbg_ui_mon,loop,1}]} _____________________________________________________ G? f?re i k?n och f? din sajt v?rderad p? nolltid med Yahoo! Express Se mer p?: http://se.docs.yahoo.com/info/express/help/index.html From richardc@REDACTED Thu Jul 24 13:39:44 2003 From: richardc@REDACTED (Richard Carlsson) Date: Thu, 24 Jul 2003 13:39:44 +0200 (MET DST) Subject: compiler and debugger bugs, R9B-1, Windows XP Home Edition In-Reply-To: <20030724010305.34259.qmail@web14612.mail.yahoo.com> References: <20030724010305.34259.qmail@web14612.mail.yahoo.com> Message-ID: You probably meant 'queue:new()', not 'queue.new()'. Anyway, this has been fixed in R9C, so the compiler does not crash. Instead you will see the warning "function 'queue.new'/0 undefined". /Richard On Thu, 24 Jul 2003, Anders Nygren wrote: > I have found two bugs in R9B-1 on Windows XP Home Edition. > > The first crashes the compiler. The following little program > demonstrates it. > > --------------------------------------------------------------- > > -module(bug). > -export([bug/0]). > -record(rec,{f1}). > > test()-> > #rec{f1=queue.new()}. > > --------------------------------------------------------------- > > 133> c(bug). > ./bug.erl:none: internal error in beam_clean; > crash reason: {{case_clause,{'EXIT',{function_clause, Richard Carlsson (richardc@REDACTED) (This space intentionally left blank.) E-mail: Richard.Carlsson@REDACTED WWW: http://user.it.uu.se/~richardc/ "Having users is like optimization: the wise course is to delay it." -- Paul Graham From anders_nygren2002@REDACTED Wed Jul 30 19:24:00 2003 From: anders_nygren2002@REDACTED (=?iso-8859-1?q?Anders=20Nygren?=) Date: Wed, 30 Jul 2003 19:24:00 +0200 (CEST) Subject: pman problems Message-ID: <20030730172400.86292.qmail@web14604.mail.yahoo.com> I am running R9B-1 on Windows XP Home Edition. I have found that the pman trace window can not be moved or resized. When I try to move it, it just jerks a little. Sometimes it actually moves a few cm and then jumps back to the original place. /Anders _____________________________________________________ G? f?re i k?n och f? din sajt v?rderad p? nolltid med Yahoo! Express Se mer p?: http://se.docs.yahoo.com/info/express/help/index.html