NVIDIA / NVIDIA/raft

[BUG] handle_t destructor throws exceptions

Open
#71 2 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

bug inactive-30d inactive-90d
Dominant language
Cuda
Stars
1k
Forks
251
Avg merge
1d 8h
Merged PRs (30d)
31

Description

Describe the bug

The raft::handle_t destructor calls destroy_resources(), which can throw a variety of exceptions. It's hard/impossible to catch those if stack unwinding is in progress. I see a TODO to use NO_THROW and enable logging, but personally I don't like to see log messages about failed dtors due to a previous error.

https://github.com/rapidsai/raft/blob/d1e04a85eb701265b1d757db00eb6de4c488438d/cpp/include/raft/handle.hpp#L222-L223

Is it necessary to check the destroy calls at all?

Example code that terminates
inline void transpose(raft::handle_t& handle, float* out, float* in, size_t n_rows, size_t n_cols) {
  const float alpha = 1.0f;
  const float beta = 0.0f;
  const int lda = n_rows;
  const int ldb = n_cols;
  const int ldc = lda;
  DeviceBuffer<float> garbage(1);
  auto tStatus = raft::linalg::cublasgeam(handle.get_cublas_handle(),
                              CUBLAS_OP_T,
                              CUBLAS_OP_N,
                              n_cols, n_rows,
                              &alpha, in, lda,
                              &beta, garbage.Data(), ldb,
                              out, ldc,
                              handle.get_stream());
  if (tStatus != CUBLAS_STATUS_SUCCESS)
    throw std::runtime_error(raft::linalg::detail::cublas_error_to_string(tStatus));
}

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start in cpp/include/raft/handle.hpp at the handle_t destructor and its destroy_resources() call, then reproduce the termination with the provided transpose example. Determine the intended destructor behavior when cleanup occurs during stack unwinding; done means the example no longer terminates because the destructor propagates a cleanup exception.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
backend
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.