Re: [libgpiod] Segmentation faults with

[Bartosz Golaszewski <brgl@xxxxxxxx>]

śr., 28 lis 2018 o 01:32 Michael Beach <michaelb@xxxxxxxx> napisał(a):
>
> Hi all, when I tried running gpiodetectcxx (one of the example
> programs for the C++ bindings) I was getting a segmentation fault on a
> system with no GPIO devices. The problem seemed to occur in a call to
> gpiod_chip_close() with a null pointer argument, which is made from
> ~chip_iter().
>
> The reason for this seems to be that if we called
> gpiod::make_chip_iter() when there were no GPIO devices in the system,
> the _m_current field of chip_iter gets constructed as a
> std::shared_ptr with a null pointer value, and so on destruction
> chip_deleter() ends up calling gpiod_chip_close() with a null pointer
> argument.
>
> The solution seems to be greater care in how we initialise
> chip_iter::_m_current, so that we never construct a std::share_ptr
> that points to null. Please see the patch below...
>
> diff --git a/bindings/cxx/iter.cpp b/bindings/cxx/iter.cpp
> index 0f11057..3598dbc 100644
> --- a/bindings/cxx/iter.cpp
> +++ b/bindings/cxx/iter.cpp
> @@ -58,10 +58,11 @@ bool chip_iter::operator!=(const chip_iter& rhs)
> const noexcept
>  }
>
>  chip_iter::chip_iter(::gpiod_chip_iter *iter)
> -       : _m_iter(iter, chip_iter_deleter),
> -         _m_current(chip(::gpiod_chip_iter_next_noclose(this->_m_iter.get())))
> +       : _m_iter(iter, chip_iter_deleter)
>  {
> +       ::gpiod_chip* current =
> ::gpiod_chip_iter_next_noclose(this->_m_iter.get());
>
> +       this->_m_current = current ? chip(current) : chip();
>  }
>
>  chip_iter& chip_iter::operator++(void)

Hi Michael,

Sorry for the late response - I'm only now seeing that many libgpiod
patches sent to this list went into my spam box. Not sure why.

Another user reported the same issue - I'm taking care of that now. I
wasn't aware that a shared_ptr initialized with a nullptr will call
the deleter anyway.

Bart