DeepToImage crash?

[Shawn Neely]

We've been testing 2.2.2-3 for a while now and are pretty happy so far.  One thing we've noted is that occasionally when working interactively and doing a lot of quick graph manipulations in Nuke we'll get a crash in the OpenDCX version of DeepToImage while constructing a ChannelSet.  The stack trace looks like this:

...
#4  <signal handler called>
#5  DD::Image::ChannelSet::ChannelSet(DD::Image::ChannelSet const&) () [0x7fabd6fe79a6] from Nuke10.0v6/libDDImage.so
#6  DD::Image::DeepOp::deepEngine(DD::Image::Box, DD::Image::ChannelSet const&, DD::Image::DeepPlane&) ()+0x103 from Nuke10.0v6/libDDImage.so
#7  DeepToImage::engine(int, int, int, DD::Image::ChannelSet const&, DD::Image::Row&) ()+0x13f from OpenDCX/DeepToImage.so
...

I'm wondering if this could be similar to the issue that was recently fixed for DeepSubpixelMask where an empty set of channels could crash deepEngine().  I don't know under what circumstances get_channels might be empty in DeepToImage, and I don't have a good repro case yet, but might it be safe practice to add an "if (!get_channels.empty())" check before calling deepEngine() in DeepToImage::engine() ?

cheers,
shawn.

[Jonathan Egstad]

Hm.

Could be that I'm not locking properly when I retrieve the channel index from the map as the map may get a channel inserted into it before the retrieved value is used. Thought locking on map insert would be enough but I guess not...

Try changing this method in DDImageAdapter.cpp, 158, it's likely more reliable:

Dcx::ChannelIdx

dcxChannel (DD::Image::Channel z)

{

    context_lock.lock();

    std::map<DD::Image::Channel, Dcx::ChannelIdx>::const_iterator it = dcx_channel_map.find(z);

    if (it != dcx_channel_map.end())

    {

        const Dcx::ChannelIdx dcx_chan = it->second;

        context_lock.unlock();

        return dcx_chan;

    }

    context_lock.unlock();

    return dcxAddChannel(z); // not found, add it now

[Shawn Neely]

Ok, we'll give that a try, thanks.

Haven't seen that crash for a while.  It seemed to be happening more when we were actively editing a large node graph.  Now that we've settled down to using something, it hasn't been problematic.

I never got a reliable repro case so I'm not exactly sure how to test, but if it got you thinking more about locking, then that's probably a good thing.  :)

thanks!