[erlang-bugs] Allow code upgrade for the code_server itself

[Stavros Aronis]

Hi Siri!

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.

Back to the main topic, this sequence does not seem to work either, as the
code_server is still stuck in old code:

~$ diff ~/git/otp/lib/kernel/src/code_server.erl ~/code_server.erl
1263a1264
>                     erlang:display(foo),
~$ erlc code_server.erl
~$ erl -nostick
Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8]
[async-threads:10] [hipe] [kernel-poll:false]

Eshell V6.0  (abort with ^G)
1> l(code_server).
{module,code_server}
2> code:which(code_server).
"/home/stavros/code_server.beam"
3> erlang:check_old_code(code_server).
true
4> code:soft_purge(code_server).
false
5> erlang:check_process_code(whereis(code_server),code_server).
true
6> sys:suspend(code_server).
ok
7> sys:change_code(code_server, code_server, ignored, ignored).
ok
8> sys:resume(code_server).
ok
9> erlang:check_process_code(whereis(code_server),code_server).
true

Regards,

Stavros


On Fri, Jun 27, 2014 at 1:31 PM, Siri Hansen <erlangsiri@REDACTED> wrote:

> Hi Stavros!
>
> 2014-06-23 11:48 GMT+02:00 Stavros Aronis <aronisstav@REDACTED>:
>
> 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.
>>
>
> 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.
>
> 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.
>
>
>>
>> Here is another bug, admittedly unrelated (since I am not trying to
>> update the code of the code_server *process*):
>>
>> 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.
>> 2) Run the following:
>> $ erlc code_server.erl
>> $ erl -nostick
>> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [64-bit] [smp:8:8]
>> [async-threads:10] [hipe] [kernel-poll:false]
>>
>> Eshell V6.0  (abort with ^G)
>> 1> l(code_server).
>> {module,code_server}
>> 2> code:which(code_server).
>> "/home/stavros/code_server.beam"
>> 3> erlang:check_old_code(code_server).
>> true
>> 4> code:soft_purge(code_server).
>> true
>> 5> l(te *TAB*
>> Crash dump was written to: erl_crash.dump
>> Internal error: Invalid reference count found on #Fun<code_server.0.416>:
>>  About to erase fun still referred by code.
>> Aborted
>>
>> I would expect the soft_purge to fail and the system not to crash.
>>
>
> Yes, I would also expect that. And I can not reproduce the problem :(
>
> $ erlc code_server.erl
> $ erl -nostick
> Erlang/OTP 17 [erts-6.0] [source-07b8f44] [smp:4:4] [async-threads:10]
> [hipe] [kernel-poll:false]
>
> Eshell V6.0  (abort with ^G)
> 1> l(code_server).
> {module,code_server}
> 2> code:which(code_server).
> "/home/siri/code_server.beam"
> 3> erlang:check_old_code(code_server).
> true
> 4> code:soft_purge(code_server).
> false
>
> I also have
> 5> erlang:check_process_code(whereis(code_server),code_server).
> true
>
> Do you have any other patches, or is it a plain 17.0? (Sorry - I don't
> have any other ideas right now :( )
>
> /siri
>
>
>>
>> On Thu, Jun 19, 2014 at 11:26 AM, Siri Hansen <erlangsiri@REDACTED>
>> wrote:
>>
>>> 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?
>>> Regards
>>> /siri
>>>
>>>
>>> 2014-03-10 23:02 GMT+01:00 Stavros Aronis <aronisstav@REDACTED>:
>>>
>>>> Hello!
>>>>
>>>> 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:
>>>>
>>>> 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...
>>>> 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())
>>>> 3) Load the patched code_server code
>>>> 4) Move the code_server process from the old code to the new one.
>>>>
>>>> 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).
>>>>
>>>> Is there a reason why this is so? Is there any possibility for this to
>>>> be patched?
>>>>
>>>> Cheers,
>>>>
>>>> Stavros
>>>>
>>>>
>>>> _______________________________________________
>>>> erlang-bugs mailing list
>>>> erlang-bugs@REDACTED
>>>> http://erlang.org/mailman/listinfo/erlang-bugs
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140627/9863eb63/attachment.htm>