<div dir="ltr">Stavros, <br><br>you are right! Of course the change_code system message does not help. The only thing it does is to call system_code_change/4 in the new version of the module, but when it returns, the process keeps executing the old code.<br>
<br>Your suggested change, to make the system_continue call on line 184 qualified, will solve the problem. It will, however, also make (almost) any system message effectuate a code change (if new code_server code is loaded), e.g.<br>
<br>Erlang/OTP 18 [DEVELOPMENT] [erts-7.0] [source-a6de62b] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]<br><br>Eshell V7.0 (abort with ^G)<br>1> l(code_server).<br>{module,code_server}<br>2> sys:get_status(code_server).<br>
{status,<0.20.0>,<br> {module,code_server},<br> [[{any_native_code_loaded,false}],<br> running,<0.11.0>,[],<br> {state,<0.11.0>,"/ldisk/siri/git/otp",<br> [".","/ldisk/siri/git/otp/lib/kernel/ebin",<br>
"/ldisk/siri/git/otp/lib/stdlib/ebin",<br> [...]|...],<br> 13,4110,no_cache,interactive,[]}]}<br>3> erlang:check_process_code(whereis(code_server),code_server).<br>
false<br><br>I don't know if this is a good thing... On the other hand, that is the same as would happen for e.g. gen_server or any of the other gen* behaviour so maybe it is ok.<br><br>Another potential problem is that if you do the suspend - change_code - resume sequence, then system_code_change would be called in the new code, but then the old code would run again after its return and until the resume message was handled. Depending on which part of the code that was actually changed, this could be fatal. In the gen* behaviour case this is not a problem since the code running in between is in sys and not in gen*. A bit more code, and exporting the suspend_loop function, could of course solve this problem...<div>
<br></div><div>I think I need to discuss this a bit further with my team - if it is something we would want to do or not. Please let me know if such a change is at all desirable. Comments from others on the list are of course also welcome.</div>
<div><br></div><div>Regards</div><div>/siri<div><div><br><br>2014-06-27 14:11 GMT+02:00 Stavros Aronis <<a href="mailto:aronisstav@gmail.com">aronisstav@gmail.com</a>>:<br>><br>> Hi Siri!<br>><br>> You are right. I had a modification on the actual code_server.erl, which I hadn't removed when generating the previous report. With a clean R17 I cannot reproduce it so apologies for the false alarm.<br>
><br>> Back to the main topic, this sequence does not seem to work either, as the code_server is still stuck in old code:<br>><br>> ~$ diff ~/git/otp/lib/kernel/src/code_server.erl ~/code_server.erl <br>> 1263a1264<br>
> > erlang:display(foo),<br>> ~$ erlc code_server.erl<br>> ~$ erl -nostick<br>> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]<br>
><br>> Eshell V6.0 (abort with ^G)<br>> 1> l(code_server).<br>> {module,code_server}<br>> 2> code:which(code_server).<br>> "/home/stavros/code_server.beam"<br>> 3> erlang:check_old_code(code_server).<br>
> true<br>> 4> code:soft_purge(code_server).<br>> false<br>> 5> erlang:check_process_code(whereis(code_server),code_server).<br>> true<br>> 6> sys:suspend(code_server).<br>> ok<br>> 7> sys:change_code(code_server, code_server, ignored, ignored).<br>
> ok<br>> 8> sys:resume(code_server).<br>> ok<br>> 9> erlang:check_process_code(whereis(code_server),code_server).<br>> true<br>><br>> Regards,<br>><br>> Stavros<br>><br>><br>> On Fri, Jun 27, 2014 at 1:31 PM, Siri Hansen <<a href="mailto:erlangsiri@gmail.com">erlangsiri@gmail.com</a>> wrote:<br>
>><br>>> Hi Stavros!<br>>><br>>> 2014-06-23 11:48 GMT+02:00 Stavros Aronis <<a href="mailto:aronisstav@gmail.com">aronisstav@gmail.com</a>>:<br>>><br>>>> a lot of time has passed indeed, and I have put in place a different kind of instrumentation, which works for what I want to do. Unfortunately I currently don't have the time to test again, but I suspect that the issue remains, for the reasons I explained.<br>
>><br>>><br>>> Yes, I assume nothing has changed - my point was that when receiving a change_code system message, code_server does a qualified call to system_code_change. This is where the actual code change is expected to happen - not in the call to system_continue at line 184.<br>
>><br>>> I would think that the reason that sys uses a qualified call is that the module in question is not ?MODULE, but rather a callback.<br>>> <br>>>><br>>>><br>>>> Here is another bug, admittedly unrelated (since I am not trying to update the code of the code_server *process*):<br>
>>><br>>>> 1) Copied code_server.erl to my home directory and added an "erlang:display(foo)" call before the single erlang:load_module/1 call in the module.<br>>>> 2) Run the following:<br>
>>> $ erlc code_server.erl <br>>>> $ erl -nostick<br>>>> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8] [async-threads:10] [hipe] [kernel-poll:false]<br>>>><br>>>> Eshell V6.0 (abort with ^G)<br>
>>> 1> l(code_server).<br>>>> {module,code_server}<br>>>> 2> code:which(code_server).<br>>>> "/home/stavros/code_server.beam"<br>>>> 3> erlang:check_old_code(code_server).<br>
>>> true<br>>>> 4> code:soft_purge(code_server).<br>>>> true<br>>>> 5> l(te *TAB*<br>>>> Crash dump was written to: erl_crash.dump<br>>>> Internal error: Invalid reference count found on #Fun<code_server.0.416>: About to erase fun still referred by code.<br>
>>> Aborted<br>>>><br>>>> I would expect the soft_purge to fail and the system not to crash.<br>>><br>>><br>>> Yes, I would also expect that. And I can not reproduce the problem :(<br>
>><br>>> $ erlc code_server.erl <br>>> $ erl -nostick<br>>> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [smp:4:4] [async-threads:10] [hipe] [kernel-poll:false]<br>>><br>>> Eshell V6.0 (abort with ^G)<br>
>> 1> l(code_server).<br>>> {module,code_server}<br>>> 2> code:which(code_server).<br>>> "/home/siri/code_server.beam"<br>>> 3> erlang:check_old_code(code_server).<br>>> true<br>
>> 4> code:soft_purge(code_server).<br>>> false<br>>><br>>> I also have<br>>> 5> erlang:check_process_code(whereis(code_server),code_server).<br>>> true<br>>><br>>> Do you have any other patches, or is it a plain 17.0? (Sorry - I don't have any other ideas right now :( )<br>
>><br>>> /siri<br>>><br>>>><br>>>><br>>>> On Thu, Jun 19, 2014 at 11:26 AM, Siri Hansen <<a href="mailto:erlangsiri@gmail.com">erlangsiri@gmail.com</a>> wrote:<br>>>>><br>
>>>> Hi Stavros, I'm sorry for the very long delay! Are you still struggling with this problem or did you find a way around it? Would a code_change system message while the process is suspended possibly solve the problem?<br>
>>>> Regards<br>>>>> /siri<br>>>>><br>>>>><br>>>>> 2014-03-10 23:02 GMT+01:00 Stavros Aronis <<a href="mailto:aronisstav@gmail.com">aronisstav@gmail.com</a>>:<br>
>>>>><br>>>>>> Hello!<br>>>>>><br>>>>>> I am playing around with code instrumentation and trying to hack the code server so that it applies some transformation whenever it loads *any* module. The hack itself is relatively simple:<br>
>>>>><br>>>>>> 1) Instrument and reload any already loaded modules (come to think about it, during this process more modules may be loaded, but let's assume a fixpoint). This is to avoid the case where in order to load A, you have to instrument A, and the instrumenter itself needs a call to X, which is not yet loaded so you have to load X, so you have to instrument X, etc...<br>
>>>>> 2) Get the Core Erlang code of the codeserver and wrap the second argument of erlang:load_module (Line 1264) with a call to my instrumenter (which is a function from binary() -> binary())<br>>>>>> 3) Load the patched code_server code<br>
>>>>> 4) Move the code_server process from the old code to the new one.<br>>>>>><br>>>>>> I am having trouble with the last step. As far as I understand it, the reason is that the call to system_continue (Line 184) is not qualified, as is the similar call in sys.erl (Line 324).<br>
>>>>><br>>>>>> Is there a reason why this is so? Is there any possibility for this to be patched?<br>>>>>><br>>>>>> Cheers,<br>>>>>><br>>>>>> Stavros<br>
>>>>><br>>>>>><br>>>>>> _______________________________________________<br>>>>>> erlang-bugs mailing list<br>>>>>> <a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
>>>>> <a href="http://erlang.org/mailman/listinfo/erlang-bugs">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>>>>>><br>>>>><br>>>><br>>><br>><br></div></div>
</div></div>