Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

interop.FunctionReference function passed as a block, then as a function pointer, asserts

オープン
  • 何か問題がありますか？
#503 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

@edusperoni がすでに取り組んでいます。

2026年10月9日 から。

  • #504 @edusperoni による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
22/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
ios, javascript, objective-c

調査の方向性

Start in NativeScript/runtime/Interop.mm, in the block branch and the function-pointer branch of Interop::SetFFIParams, and in FunctionReference.cpp, where the constructor stores a FunctionReferenceWrapper on the function. Reproduce with the block-then-pointer order and confirm the tns::Assert(false) fires. Done means both wrappers can coexist on one function, or the pointer path throws a JS error instead of asserting, with the worker test from #500 still passing.

索引モデルが issue の本文から書いたものです。

説明

Summary

A function wrapped with interop.FunctionReference and then passed to a native API as a block loses its FunctionReference identity. A later attempt to pass it as a function pointer then hits tns::Assert(false) in Interop::SetFFIParams, which crashes the app.

Repro

const fn = function () {};
const ref = new interop.FunctionReference(fn); // returns fn itself

// Any API taking a block, e.g.:
NSOperationQueue.mainQueue.addOperationWithBlock(ref);

// Any API taking a C function pointer, e.g. a struct field or a C function parameter
// typed as a function pointer:
someFunctionTakingAFunctionPointer(ref); // -> tns::Assert(false)

Cause

Both wrapper kinds live in the same per-object slot (tns::SetValue / tns::GetValue):

  • FunctionReference's constructor stores a FunctionReferenceWrapper on fn and registers fn with ObjectManager (FunctionReference.cpp).
  • The block branch of Interop::SetFFIParams doesn't recognise a FunctionReferenceWrapper as a cached block. It builds a JSBlock and overwrites the slot with its BlockWrapper. tns::SetValue doesn't free the previous wrapper, so the FunctionReferenceWrapper leaks, along with the trampoline it may have cached.
  • The function-pointer branch accepts only Pointer, AnonymousFunction and FunctionReference wrappers. With a BlockWrapper in the slot it falls through to tns::Assert(false, isolate) (NativeScript/runtime/Interop.mm, function-pointer branch of SetFFIParams).

In the opposite order (block first, then new interop.FunctionReference(fn)), the constructor overwrites the block's wrapper. Every later block marshal of fn then builds a new block instead of reusing the cached one, and the next one overwrites the FunctionReferenceWrapper again.

Expected

One function can be used both as a block and as a function pointer. Possible directions:

  • keep the block cache and the FunctionReference state in separate slots;
  • let the block path recognise a FunctionReferenceWrapper and keep the block alongside it.

Either way, neither marshal should evict the other's wrapper, and the function-pointer path should never assert on a wrapper type it can explain to the user. At minimum it should throw a JS error instead.

Context

Found while reviewing #500, which makes JS block wrappers owned by their JSBlock. The worker test added there (blockFunctionReferenceWorker.js) relies on the current overwrite behaviour to reach the teardown path.

主要言語
JavaScript
スター
150
フォーク
44
平均マージ
3日 23時間
マージ済み PR（30日）
19

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

NativeScript/ios のほかの issue

NativeScript/ios の issue をすべて見る

似ている issue

JavaScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。