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

[Stavros Aronis]

Hi Siri,

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.

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.

Regards,

Stavros


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/20140623/65f3a92e/attachment.htm>