Hacktoberfest 2026：维护者为十月标记出来的 issue，仍然开放、适合新手。 浏览 Hacktoberfest issue

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

未关闭
  • 哪里不对？
#503 0 条评论 0 个 reaction 已指派 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 小时
30 天内合并 PR
19

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

NativeScript/ios 的其他 Issue

查看 NativeScript/ios 的全部 Issue

相似的 Issue

更多 JavaScript Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。