> I am actually trying to switch to arrow_static.lib. Perhaps the issue is arrow_static.lib being linked with a static crt that's not the one you are using in your project?
On Fri, May 12, 2023 at 3:13 PM Arkadiy Vertleyb (BLOOMBERG/ 120 PARK) < avertl...@bloomberg.net> wrote: > This is not only about shared_ptr though. I think returning strings, > vectors, etc., would have a similar issue due to return value > optimization. Same with std::move. > > From: dev@arrow.apache.org At: 05/12/23 14:08:42 UTC-4:00To: > dev@arrow.apache.org > Subject: Re: Freeing memory when working with static crt in windows. > > 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-passin > g-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 > <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 > > > > > > > > > > > > > > >
