apache / apache/pulsar-client-node

When seek timesout, node's vm crash with EXC_BAD_ACCESS

Open
#427 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
164
Forks
98
PR merge metrics
No merged PRs in 30d

Description

The following code will make it crash if it times out to seek to something in the past

```typescript
const consumeSince = new Date(new Date() - 7 * 24 * 24 * 60 * 1000);

const consumer = await client.subscribe({
topic: fullTopicName,
subscription,
subscriptionType: 'Exclusive' as SubscriptionType,
subscriptionInitialPosition: 'Latest' as InitialPosition,
consumerName,
listener: async (message: Message, listenerConsumer: Consumer) => {}
});

await consumer.seekTimestamp(consumeSince.valueOf());
```

Will crash with the following:
```
Process 32926 stopped
* thread #24, stop reason = EXC_BAD_ACCESS (code=1, address=0x276)
frame #0: 0x000000011e096b04 pulsar.node`Consumer::SeekTimestamp(Napi::CallbackInfo const&)::$_10::__invoke(pulsar_result, void*) + 64
pulsar.node`Consumer::SeekTimestamp(Napi::CallbackInfo const&)::$_10::__invoke(pulsar_result, void*):
-> 0x11e096b04 <+64>: ldadd x9, x8, [x8]
0x11e096b08 <+68>: ldr x23, [x22, #0x8]
0x11e096b0c <+72>: cbz x23, 0x11e096b20 ; <+92>
0x11e096b10 <+76>: add x8, x23, #0x8
Target 0: (node) stopped.
(lldb) bt
* thread #24, stop reason = EXC_BAD_ACCESS (code=1, address=0x276)
* frame #0: 0x000000011e096b04 pulsar.node`Consumer::SeekTimestamp(Napi::CallbackInfo const&)::$_10::__invoke(pulsar_result, void*) + 64
frame #1: 0x000000011e20d6f8 pulsar.node`void pulsar::MultiTopicsConsumerImpl::seekAllAsync(unsigned long long const&, std::__1::function)::'lambda'(std::__1::shared_ptr const&, pulsar::SharedFuture)::operator()(std::__1::shared_ptr const&, pulsar::SharedFuture) const::'lambda'(pulsar::Result)::operator()(pulsar::Result) const + 164
frame #2: 0x000000011e1c3390 pulsar.node`std::__1::__function::__func const&, std::__1::function)::$_18, std::__1::allocator const&, std::__1::function)::$_18>, void (pulsar::Result, pulsar::ResponseData const&)>::operator()(pulsar::Result&&, pulsar::ResponseData const&) + 508
frame #3: 0x000000011e148fa4 pulsar.node`pulsar::InternalState::complete(pulsar::Result, pulsar::ResponseData const&) + 192
frame #4: 0x000000011e1050bc pulsar.node`pulsar::ClientConnection::handleRequestTimeout(std::__1::error_code const&, pulsar::ClientConnection::PendingRequestData) + 84
frame #5: 0x000000011e149718 pulsar.node`asio::detail::binder1::operator()() + 144
frame #6: 0x000000011e149164 pulsar.node`asio::detail::wait_handler::do_complete(void*, asio::detail::scheduler_operation*, std::__1::error_code const&, unsigned long) + 280
frame #7: 0x000000011e122ebc pulsar.node`asio::detail::scheduler::do_run_one(asio::detail::conditionally_enabled_mutex::scoped_lock&, asio::detail::scheduler_thread_info&, std::__1::error_code const&) + 668
frame #8: 0x000000011e122ad0 pulsar.node`asio::detail::scheduler::run(std::__1::error_code&) + 268
frame #9: 0x000000011e1d124c pulsar.node`void* std::__1::__thread_proxy[abi:ue170006]>, pulsar::ExecutorService::start()::$_0>>(void*) + 176
frame #10: 0x000000018f162c0c libsystem_pthread.dylib`_pthread_start + 136
```

Contributor guide

No contributing guide indexed for this repository

Research direction

Reproduce the timeout using Consumer::SeekTimestamp and then trace the callback through seekAllAsync, seekAsyncInternal, and ClientConnection::handleRequestTimeout in the stack. Determine where the timeout result reaches the native callback and verify that the same scenario completes without an EXC_BAD_ACCESS crash.

Written by the indexing model from the issue text.

Assessment

Tech stack
nodejs, typescript
Domain
distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.