I looked at current definition of shared_ptr in msvc 2022. It doesn't have a custom deleter, at all. However it does not call delete either, and somehow I was not able to dig down to actual delete through all the virtuals - my obj browser failed. I suspect it might put the address of the delete function in the ptr during construction and call it later instead of delete.
But my assertion shows still wrong deleter used somehow. I am actually trying to switch to arrow_static.lib. From: dev@arrow.apache.org At: 05/12/23 13:49:22 UTC-4:00To: dev@arrow.apache.org Subject: Re: Freeing memory when working with static crt in windows. You're right that the default is delete/free. However, the important bit is that it needs to be the correct delete/free. The error you described originates from the fact that the final application has two copies of the CRT and thus two copies of delete/free. Since shared_ptr/unique_ptr picks the call to delete/free at compile time this means that it should be picking the correct delete/free. On Fri, May 12, 2023 at 9:27 AM Arkadiy Vertleyb (BLOOMBERG/ 120 PARK) < avertl...@bloomberg.net> wrote: > Maybe I am wrong about shared_ptr though. Yes, according to Scott Meyers > it is safe, at least in tr1. Have to see what is there now... > > From: dev@arrow.apache.org At: 05/12/23 12:23:48 UTC-4:00To: > dev@arrow.apache.org > Subject: Re: Freeing memory when working with static crt in windows. > > Unless you provide custom deleter, which I don't believe arrow does, it is > just > default delete()->free(), which exactly matches to the problem I am > having. It > would have to be a shared_ptr with additional template parameter. > > So no, unless special care was taken by arrow developers, shared_ptr would > not > solve the issue :-( > > Also I think potentially something like returning std::vector by value > would > cause the same issue. > > > From: dev@arrow.apache.org At: 05/12/23 11:53:34 UTC-4:00To: > dev@arrow.apache.org > Subject: Re: Freeing memory when working with static crt in windows. > > I'm not very familiar with Windows. However, I read through [1] and that > matches your description. > > I suppose I thought that a shared_ptr / unique_ptr would not have this > problem. I believe these smart pointers store / template a deleter as part > of their implementation. This seems to be reinforced by [2]. > > [1] > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing > -crt-objects-across-dll-boundaries?view=msvc-170 > <https://learn.microsoft.com/en-us/cpp/c-runtime-library/potential-errors-passing-crt-objects-across-dll-boundaries?view=msvc-170> > [2] > > https://stackoverflow.com/questions/1958643/is-it-ok-to-use-boostshared-ptr-in-d > ll-interface > <https://stackoverflow.com/questions/1958643/is-it-ok-to-use-boostshared-ptr-in-dll-interface> > > On Fri, May 12, 2023 at 8:21 AM Arkadiy Vertleyb (BLOOMBERG/ 120 PARK) < > avertl...@bloomberg.net> wrote: > > > Hi all. > > > > In some cases arrow API allocates an object and returns a shared pointer > > to it. Which means the object will be deallocated on the client side. > > > > This represents a problem when working with a static CRT in windows > (which > > I am experiencing right now). > > > > IIUC, the way to deal with this would be to export a "free" wrapper from > > arrow DLL and use custom deleter on the shared pointer to call this > > wrapper, so that both allocation and deallocation happens inside the > arrow > > DLL itself. > > > > Does arrow provide this kind of facility? > > > > Thanks, > > Arkadiy > > > > > > >
