I cannot get stack traces with VS. I can add a macro to every compilation unit that wraps "new" so that __FILE__ and __LINE__ are recorded. It's quite a bit of work to re-arrange your header files, though. Would that suffice? Alternatively, do you happen to have a 3rd party tracker like Bounds Checker?
Oleg. On 2009/5/15 15:58, Kenton Varda wrote: > Can you get stack traces for these? > > I ran the whole protobuf test suite with the google-perftools leak > checker and didn't detect any leaks. > > On Thu, May 14, 2009 at 4:05 PM, Oleg Smolsky <o...@smolsky.net > <mailto:o...@smolsky.net>> wrote: > > Hi Kenton, thank you for letting me know. I've just got and built > this version of protoc/libprotobuf and run my unit test - there > are still a few leaks according to VS2008. So, there is a > difference between v2.1.0 and the destructor-based patch that I > had cleaned up for v2.0.3. > > The output is below. Do you happen to recognize the 24 byte > structure that starts with a pointer and then contains 0xffffffff? :) > > Kind regards, > Oleg. > > Detected memory leaks! > Dumping objects -> > {1438} normal block at 0x00D72620, 24 bytes long. > Data: <h ( > 68 A6 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {1437} normal block at 0x00D725C8, 24 bytes long. > Data: <0 ( > 30 A6 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {946} normal block at 0x00246AB0, 24 bytes long. > Data: < ( > A0 A1 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {945} normal block at 0x00249CD0, 24 bytes long. > Data: <h ( > 68 A1 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {934} normal block at 0x00249840, 24 bytes long. > Data: <0 ( > 30 A1 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {812} normal block at 0x002469B0, 24 bytes long. > Data: <x ( > 78 9D 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {685} normal block at 0x00D71FB0, 24 bytes long. > Data: < ( > D0 9C 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {667} normal block at 0x00D71608, 24 bytes long. > Data: <` ( > 60 9C 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {666} normal block at 0x00D715B0, 24 bytes long. > Data: <( ( > 28 9C 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {663} normal block at 0x00D713D8, 24 bytes long. > Data: <Pu( > 50 75 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {148} normal block at 0x00245820, 24 bytes long. > Data: <pt( > 70 74 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {147} normal block at 0x002457C8, 24 bytes long. > Data: <8t( > 38 74 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {136} normal block at 0x00245290, 24 bytes long. > Data: < t( > 00 74 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > {135} normal block at 0x00245238, 24 bytes long. > Data: < s( > C8 73 28 00 FF FF FF FF 00 00 00 00 00 00 00 00 > Object dump complete. > > > On 2009/5/14 13:08, Kenton Varda wrote: >> FYI: This is fixed in the 2.1.0 release (you can call >> google::protobuf::ShutdownProtobufLibrary() to clean up all "leaks"). >> >> On Fri, Mar 27, 2009 at 7:07 PM, Kenton Varda <ken...@google.com >> <mailto:ken...@google.com>> wrote: >> >> On Fri, Mar 27, 2009 at 4:30 PM, Oleg Smolsky >> <o...@smolsky.net <mailto:o...@smolsky.net>> wrote: >> >> So, the next question is - would it ever make its way >> into your SVN? If so, do you see a need for a switch of >> some kind? >> >> >> Yeah, reviewing and committing this is on my todo list for >> the next release. >> >> > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to protobuf@googlegroups.com To unsubscribe from this group, send email to protobuf+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
