Hi guysI'm debugging some code that throws an access violation error that occurs at the end of the application when the call stack is unwound.Its a long code base so its difficult to explain the control flow here. I saw something odd in the assembly code. In the attached code I cant understand why the compiler is emitting this code to delete the shared ptr "std::tr1::shared_ptr<SynthForward>::~shared_ptr<SynthForward>" at various points at the end of these brackets. The synthetic forward shared ptrs are created a few function calls inside the call stack of this function so it shouldn't be deleted at this point. All optimisations have been turned off.There are other products being priced in this code along with synthetic forwards using the same architecture and they do not cause a problem. Cant figure out what is different about this particular class.Any ideas?Thanks

It seems that the assembler code in visual studio shows the wrong ownership type for shared_ptr i.e. the actual pointer being deleted is not QDSynthForward. I'll post back with more details if I find something interesting. Thx for the suggestion outrun.

Hm, wondering, perhaps you can try comparing to another compiler on an otherwise unmodified platform -- is it reproducible?

I'm using VS2010, no threads. Debugging with tr1 shared_ptr is very misleading in VS. I had to dump out the assembler code to file which has the correct sharedptr types and then try best to match the buggy call stack in the debugger against the file output. I haven't been able to find the issue yet, its hidden somewhere deep in the code. Changing compiler is not an option but using boost shared_ptr shouldnt't be too much work. I'll try that when I get some time.

AFAIR tr1 (BTW kind of long in the tooth by now) and boost shared have the same interfaces. So, changing the namespace tr1 to boost is worth it although the issue may not disappear. Last time I used VS2010 (while ago) it supported C++11 smart pointers, but has less functionality than boost Thread. Are you only using tr1:shared_ptr? A random google gave this...It would seem that tr1 is a copy of boost in this context http://www.codesynthesis.com/~boris/blo ... r1-cxx-x0/ QuoteThere are other products being priced in this code along with synthetic forwards using the same architecture and they do not cause a problem.In that case, are there differences in how the two codes are written up? Can you modify the anomolous code to look like the correct code? Just an idea. Maybe a source code inspection will throw up something (no pun intended).

QuoteOriginally posted by: outrunSounds like a horrible waste of time, difficult to fix because things are cryptic.Well, we just don't know if it is or not. OP has said nothing about this. It is called software maintenance and takes up a big chunk of software budgets.Maybe it's a show stopper.Wait on what OP has to say.

Quoteabout the threads: ..so as a bonus for getting boost (I not sure if VS has native threads?) VS supports C++ Concurrency, so why would you want to know about Win32/MFC threads?

QuoteOriginally posted by: outrunWhen the debugger UI gives wrong information and you have to dump assembler to a file,... that's cryptic stuff and a waste of time.Ah, I see. Thanks.

Finally hunted it down, some of the trade types were being cached by the framework thus returning same pointers. It wouldn't have been this difficult to track down if the debugger was more helpful. I'll try replacing with boost sharedptr and see if the debugger is any better. As Cuch says, since the interface is the same I might get away with find and replace. Although a painful experience, I feel bullet proof now !!!

Plan B if boost does not solve it then std::shared_ptr<> works in VS2010.

Do you really need shared_ptr? I've rarely seen a case where it's justifiably used. Usually it's down to the programmer seeing it as a silver bullet and being unable to understand the lifetimes of objects is his own software.