Help with NIF upgrade implementation

Thu Sep 3 12:39:07 CEST 2020

Hi Robert,

Your NIF rtc_upgrade callback function is missing a call to 
enif_open_resource_type. You can basically do the same call as in rtc_load.

The upgrade callback is called when there already exists a loaded instance of 
the NIF module, which is the case in your second and third calls in the shell 
to c(rtc).

enif_open_resource_type has to be called (in load or upgrade) for each 
resource type that is going to be used by that logical NIF module instance. If 
not, the resource type will be deallocated when all resource objects are gone.

/Sverker, Erlang/OTP

From: erlang-questions <erlang-questions-bounces@REDACTED> On Behalf Of 
Harris, Robert
Sent: den 26 augusti 2020 21:16
To: erlang-questions@REDACTED Questions <erlang-questions@REDACTED>
Subject: Help with NIF upgrade implementation

I observe a reproducible SEGV of the 21.3.8.4 VM on macos Catalina when
repeatedly recompiling a module that has a skeletal NIF with an upgrade
callback. The skeleton is based on the examples in the documentation
but I am assuming that I have made an error somewhere. I would be
grateful for any pointers.

The very simple NIF library is attached, together with its makefile and
the Erlang module's source. Once built, the failure is seen very
quickly:

$ erl
Erlang/OTP 21 [erts-10.3.5.3] [source] [64-bit] [smp:12:12] [ds:12:12:10] 
[async-threads:1] [hipe]

Eshell V10.3.5.3 (abort with ^G)
1> c(rtc), rtc:foo(), rtc:bar().
ok
2> c(rtc), rtc:foo(), rtc:bar().
ok
3> c(rtc), rtc:foo(), rtc:bar().
Segmentation fault: 11
$

The stack is

* thread #10, name = '6_scheduler', stop reason = EXC_BAD_ACCESS (code=1, 
address=0x70)
frame #0: 0x000000001e41bc0e beam.smp`nif_resource_dtor at atomic.h:240
237 ETHR_AINT_T__ tmp;
238
239 tmp = incr;
-> 240 __asm__ __volatile__(
241 "lock; xadd" ETHR_AINT_SUFFIX__ " %0, %1" /* xadd didn't exist prior to 
the 486 */
242 : "=r"(tmp)
243 : "m"(var->counter), "0"(tmp)

* thread #10, name = '6_scheduler', stop reason = EXC_BAD_ACCESS (code=1, 
address=0x70)
* frame #0: 0x000000001e41bc0e beam.smp`nif_resource_dtor at atomic.h:240
frame #1: 0x000000001e41bc07 beam.smp`nif_resource_dtor
frame #2: 0x000000001e41bc07 beam.smp`nif_resource_dtor
frame #3: 0x000000001e41bc07 beam.smp`nif_resource_dtor
frame #4: 0x000000001e41bc07 beam.smp`nif_resource_dtor
frame #5: 0x000000001e41bbf0 
beam.smp`nif_resource_dtor(bin=0x000000001fc800f8)
frame #6: 0x000000001e3d390d beam.smp`sweep_off_heap(p=0x0000000020740778, 
fullsweep=<unavailable>) at erl_binary.h:453
frame #7: 0x000000001e3d73f7 beam.smp`do_minor(p=0x0000000020740778, 
live_hf_end=<unavailable>, mature=<unavailable>, mature_size=696, new_sz=376, 
objv=<unavailable>, nobj=3) at erl_gc.c:1674
frame #8: 0x000000001e3d9af4 beam.smp`garbage_collect(p=0x0000000020740778, 
live_hf_end=0xfffffffffffffff8, need=4, objv=0x000000001f7d4440, nobj=3, 
fcalls=3047, max_young_gen_usage=0) at erl_gc.c:1417
frame #9: 0x000000001e3dabb5 
beam.smp`erts_garbage_collect_nobump(p=0x0000000020740778, need=<unavailable>, 
objv=<unavailable>, nobj=<unavailable>, fcalls=3047) at erl_gc.c:878
frame #10: 0x000000001e4e8097 
beam.smp`process_main(x_reg_array=0x000000001f7d4440, 
f_reg_array=<unavailable>) at beam_hot.h:104
frame #11: 0x000000001e287916 
beam.smp`sched_thread_func(vesdp=0x0000000020bb3400) at erl_process.c:8469
frame #12: 0x000000001e4cbd52 beam.smp`thr_wrapper(vtwd=0x00007ffee197c140) at 
ethread.c:118
frame #13: 0x00007fff692aa109 libsystem_pthread.dylib`_pthread_start + 148
frame #14: 0x00007fff692a5b8b libsystem_pthread.dylib`thread_start + 15

Robert Harris

Confidentiality Notice | This email and any included attachments may be 
privileged, confidential and/or otherwise protected from disclosure. Access to 
this email by anyone other than the intended recipient is unauthorized. If you 
believe you have received this email in error, please contact the sender 
immediately and delete all copies. If you are not the intended recipient, you 
are notified that disclosing, copying, distributing or taking any action in 
reliance on the contents of this information is strictly prohibited.

Disclaimer

The information contained in this communication from the sender is 
confidential. It is intended solely for use by the recipient and others 
authorized to receive it. If you are not the recipient, you are hereby 
notified that any disclosure, copying, distribution or taking action in 
relation of the contents of this information is strictly prohibited and may be 
unlawful.

This email has been scanned for viruses and malware, and may have been 
automatically archived by Mimecast, a leader in email security and cyber 
resilience. Mimecast integrates email defenses with brand protection, security 
awareness training, web security, compliance and other essential capabilities. 
Mimecast helps protect large and small organizations from malicious activity, 
human error and technology failure; and to lead the movement toward building a 
more resilient world. To find out more, visit our website.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200903/2ca386f6/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5509 bytes
Desc: not available
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200903/2ca386f6/attachment.bin>