In my spare time I have been working on a library to analyze debug information from a running program. It either already does, or I would like to have it before I'm done, support all of the following (I'm sure there are plenty of other neat additions that I haven't thought of): - Loading debug info either for the currently running executable or from an offline executable - Printing human readable stack traces from a running program - Dumping stack traces to a file in release mode. In this case it's usually just a dump of the entire stack in binary. - Matching dumped stacks from step 3 to debug information offline to get post-mortem information. - Assuming symbol information is loaded either for the running program or an offline program, format a block of memory in a human readable format to print the structure of the memory (for example, display member values of a class with field names, given a block of memory representing an instance of the class) - Iteration of loaded modules - Check whether debugger is attached - output stream that goes to the debugger console, and is not visible in the debugged process. I'm not sure about the feasibility under non-windows platforms (it's very easy in windows), but I would think that if it's possible to figure out the PID of the process debugging you, that it should be possible to send output to their stderr which should achieve the same effect. - launch process under a debugger and receive basic types of debugging notifications. There's some obvious portability concerns, and some of these things are (considerably) more difficult than others, so I can't say I'd be able to support everything. However I already have rudimentary support for about half the items on the list although it is definitely in its infancy since before now I had not considered extending this to any other platforms / architectures. Main problem is that I can't say that I know enough about OSes other than Windows, and architectures other than x86/x64 to know if it would be not worth the hassle to prepare something like this for introduction into boost. Also everything I've done so far is only on Windows, and I don't suppose I'd have the know-how to make it work on any other OS, so in that sense I'd need some assistance. That being said, is it worth it to tackle something like this or should I just not worry about the generality and keep working on it for personal use only?
2009/6/2 Zachary Turner <divisortheory@gmail.com>
In my spare time I have been working on a library to analyze debug information from a running program. It either already does, or I would like to have it before I'm done, support all of the following (I'm sure there are plenty of other neat additions that I haven't thought of):
This sounds extremely useful, we've developed quite a bit of in-house production code (unfortunately for Windows as well so can't help with portability) and it helps a great deal in large-scale software.
- Loading debug info either for the currently running executable or from an offline executable
Care to elaborate a bit, I don't follow exactly. How is this useful compared to attaching a debugger?
- Printing human readable stack traces from a running program
IMO getting a stack-trace really quick, and defer the print-out (using the dbghelp on windows for instance) until the user requests it would be more useful than printout only. Like: boost::debug::stack_trace foo() { return stack_trace(); ] boost::debug::stack_trace bar() { return foo(); }; main() { std::cout << bar(); } It could then also be bundled together with boost::exception without a huge performance impact at throw site, and without having the exception object grow unhealthy big.
- Dumping stack traces to a file in release mode. In this case it's usually just a dump of the entire stack in binary.
Where to dump the trace is better left to a logging library (there are two submissions to boost atm I think) or to the choice of user.
- Matching dumped stacks from step 3 to debug information offline to get post-mortem information.
Same as above.
- Assuming symbol information is loaded either for the running program or an offline program, format a block of memory in a human readable format to print the structure of the memory (for example, display member values of a class with field names, given a block of memory representing an instance of the class)
Care to provide an example here?
- launch process under a debugger and receive basic types of debugging notifications.
What kind of notifications are you referring to?
That being said, is it worth it to tackle something like this or should I just not worry about the generality and keep working on it for personal use only?
It's always worth worrying about =) I think the problem can be divided into: 1). Collect information (thread context, stack-frames, stack-size, memory load and other useful diagnostics). 2). Output information (using a symbol engine for stack-trace, such as dbghelp) 3). Support bundling with boost::exception, to allow for the useful feature of easily dumping where from an exception was originally thrown, if a stack trace was added to the exception by user. I do not think it should provide a logging facility, since that's quite a task by itself. Regards, Christian
On Tue, Jun 2, 2009 at 2:47 PM, Christian Holmquist <c.holmquist@gmail.com> wrote:
2009/6/2 Zachary Turner <divisortheory@gmail.com>
- Printing human readable stack traces from a running program
IMO getting a stack-trace really quick, and defer the print-out (using the dbghelp on windows for instance) until the user requests it would be more useful than printout only. Like:
boost::debug::stack_trace foo() { return stack_trace(); ]
boost::debug::stack_trace bar() { return foo(); };
main() { std::cout << bar(); }
It could then also be bundled together with boost::exception without a huge performance impact at throw site, and without having the exception object grow unhealthy big.
Adding stack trace support to Boost Exception was also discussed at BoostCon, it would definitely be a nice addition to the rest of the information recorded in Boost exceptions automatically by BOOST_THROW_EXCEPTION. I'm guessing that the stack trace information could be stored in boost::exception as a little more than just a list of pointers to functions, and converted to string at the catch site. Of course this support should be kept separate from Boost Exception, IMO a simple interface like this would be ideal: namespace boost { namespace debug { class stack_trace; shared_ptr<stack_trace> get_stack_trace(); std::string to_string( stack_trace const & ); } } Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Jun 2, 2009 at 5:08 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
Adding stack trace support to Boost Exception was also discussed at BoostCon, it would definitely be a nice addition to the rest of the information recorded in Boost exceptions automatically by BOOST_THROW_EXCEPTION.
I'm guessing that the stack trace information could be stored in boost::exception as a little more than just a list of pointers to functions, and converted to string at the catch site. Of course this support should be kept separate from Boost Exception, IMO a simple interface like this would be ideal:
namespace boost { namespace debug { class stack_trace; shared_ptr<stack_trace> get_stack_trace(); std::string to_string( stack_trace const & ); } }
I do agree that at a bare minimum it should provide a to_string() function, but actually so much more than this is possible. The rudimentary support for this that I've implemented so far already can determine how many parameters a function has, its return type, the names of the arguments, the types of the arguments, the values of each parameter. So it would definitely be nice to provide iterators for these types of things, and accessors / enumerations to determine what data type something is, names of symbols, etc. This way (among other things, such as the file / line number / overloaded new and delete issue I mentioned in the previous post) someone could provide a custom formatter for a stack trace if they didn't like the default.
On Tue, Jun 2, 2009 at 3:17 PM, Zachary Turner <divisortheory@gmail.com> wrote:
On Tue, Jun 2, 2009 at 5:08 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
Adding stack trace support to Boost Exception was also discussed at BoostCon, it would definitely be a nice addition to the rest of the information recorded in Boost exceptions automatically by BOOST_THROW_EXCEPTION.
I'm guessing that the stack trace information could be stored in boost::exception as a little more than just a list of pointers to functions, and converted to string at the catch site. Of course this support should be kept separate from Boost Exception, IMO a simple interface like this would be ideal:
namespace boost { namespace debug { class stack_trace; shared_ptr<stack_trace> get_stack_trace(); std::string to_string( stack_trace const & ); } }
I do agree that at a bare minimum it should provide a to_string() function, but actually so much more than this is possible. The rudimentary support for this that I've implemented so far already can determine how many parameters a function has, its return type, the names of the arguments, the types of the arguments, the values of each parameter. So it would definitely be nice to provide iterators for these types of things, and accessors / enumerations to determine what data type something is, names of symbols, etc. This way (among other things, such as the file / line number / overloaded new and delete issue I mentioned in the previous post) someone could provide a custom formatter for a stack trace if they didn't like the default.
I can't think of a use case for wanting anything but a string, to be dumped into a bug report of some sort. You might need more than that if you want this interface to be powerful enough to implement a full featured debugger or whatever, but that's a different problem domain altogether. So I'd keep the stack trace interface simple and to the point. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Jun 2, 2009 at 5:26 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Tue, Jun 2, 2009 at 5:08 PM, Emil Dotchevski < emildotchevski@gmail.com>wrote:
Adding stack trace support to Boost Exception was also discussed at BoostCon, it would definitely be a nice addition to the rest of the information recorded in Boost exceptions automatically by BOOST_THROW_EXCEPTION.
I'm guessing that the stack trace information could be stored in boost::exception as a little more than just a list of pointers to functions, and converted to string at the catch site. Of course this support should be kept separate from Boost Exception, IMO a simple interface like this would be ideal:
namespace boost { namespace debug { class stack_trace; shared_ptr<stack_trace> get_stack_trace(); std::string to_string( stack_trace const & ); } }
I do agree that at a bare minimum it should provide a to_string() function, but actually so much more than this is possible. The rudimentary support for this that I've implemented so far already can determine how many parameters a function has, its return type, the names of the arguments,
types of the arguments, the values of each parameter. So it would definitely be nice to provide iterators for these types of things, and accessors / enumerations to determine what data type something is, names of symbols, etc. This way (among other things, such as the file / line number / overloaded new and delete issue I mentioned in the previous post) someone could provide a custom formatter for a stack trace if they didn't like
On Tue, Jun 2, 2009 at 3:17 PM, Zachary Turner <divisortheory@gmail.com> wrote: the the
default.
I can't think of a use case for wanting anything but a string, to be dumped into a bug report of some sort. You might need more than that if you want this interface to be powerful enough to implement a full featured debugger or whatever, but that's a different problem domain altogether. So I'd keep the stack trace interface simple and to the point.
Well, ok for the stack trace interface itself I can agree with that. Most of the other functionality will end up getting implemented one way or another though, otherwise it wouldn't be possible to generate a stack trace in the first place. So would it be worthwhile to expose the other functionality, even if through some other interface than a stack trace? For example, the stack_trace class internally may need to create some objects of type symbol which contain references to the module_info the symbol is contained in, the name of the symbol, source/line number, virtual address, etc. This interface could be exposed as well, since it's going to have to probably be written anyway. Also, I think it's useful to at the very least be able to iterate the stack frames and find source/line number information for each call in stack.
On Tue, Jun 2, 2009 at 3:42 PM, Zachary Turner <divisortheory@gmail.com> wrote:
On Tue, Jun 2, 2009 at 5:26 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
On Tue, Jun 2, 2009 at 5:08 PM, Emil Dotchevski < emildotchevski@gmail.com>wrote:
Adding stack trace support to Boost Exception was also discussed at BoostCon, it would definitely be a nice addition to the rest of the information recorded in Boost exceptions automatically by BOOST_THROW_EXCEPTION.
I'm guessing that the stack trace information could be stored in boost::exception as a little more than just a list of pointers to functions, and converted to string at the catch site. Of course this support should be kept separate from Boost Exception, IMO a simple interface like this would be ideal:
namespace boost { namespace debug { class stack_trace; shared_ptr<stack_trace> get_stack_trace(); std::string to_string( stack_trace const & ); } }
I do agree that at a bare minimum it should provide a to_string() function, but actually so much more than this is possible. The rudimentary support for this that I've implemented so far already can determine how many parameters a function has, its return type, the names of the arguments,
types of the arguments, the values of each parameter. So it would definitely be nice to provide iterators for these types of things, and accessors / enumerations to determine what data type something is, names of symbols, etc. This way (among other things, such as the file / line number / overloaded new and delete issue I mentioned in the previous post) someone could provide a custom formatter for a stack trace if they didn't like
On Tue, Jun 2, 2009 at 3:17 PM, Zachary Turner <divisortheory@gmail.com> wrote: the the
default.
I can't think of a use case for wanting anything but a string, to be dumped into a bug report of some sort. You might need more than that if you want this interface to be powerful enough to implement a full featured debugger or whatever, but that's a different problem domain altogether. So I'd keep the stack trace interface simple and to the point.
Well, ok for the stack trace interface itself I can agree with that. Most of the other functionality will end up getting implemented one way or another though, otherwise it wouldn't be possible to generate a stack trace in the first place. So would it be worthwhile to expose the other functionality, even if through some other interface than a stack trace?
Yes, the functionality would have to be implemented anyway, and you're asking the right question: should this stuff be kept as undocumented (inaccessible?) implementation details? Keep in mind the implications of documenting it: support, documentation and maintenance become more complicated. For example, what if it turns out that the full interface can't be implemented on platform X? With the simple to_string interface that's no problem, since even return "stack trace unavailable" is a possible implementation. Also consider the other possibility: what if the platform X provides useful, platform-specific information that doesn't fit the portable interface? The string-based interface is so basic it that can easily accommodate anything (but I admit that it isn't as cool.)
Also, I think it's useful to at the very least be able to iterate the stack frames and find source/line number information for each call in stack.
Provided I have a function that gets me a string that contains that information, I personally don't have a use case for such iteration. I can't think of what else I'd want to do with this data other than dump it somewhere as text. Can you? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
Provided I have a function that gets me a string that contains that information, I personally don't have a use case for such iteration. I can't think of what else I'd want to do with this data other than dump it somewhere as text. Can you?
I've only ever dumped it somewhere. Still, I've used Python's traecback to get the last N (=2) stack frames as a way of making it less likely for context to be lost in noise. I also used print_tb (full traceback) as well. In general, I think it would be a good idea to follow Python's traceback facility if you were adding it to C++. Pre-emptive please don't make it header-only comment ;-) -- Sohail Somani http://uint32t.blogspot.com
On Tue, Jun 2, 2009 at 4:42 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Pre-emptive please don't make it header-only comment ;-)
I second this. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Jun 2, 2009 at 6:49 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Tue, Jun 2, 2009 at 4:42 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Pre-emptive please don't make it header-only comment ;-)
I second this.
Unless it actually makes sense for it to be header-only. E.g. It just happens to consist entirely of class/function templates. But yeah. ;-) Jon
Jonathan Franklin wrote:
On Tue, Jun 2, 2009 at 6:49 PM, Emil Dotchevski <emildotchevski@gmail.com> wrote:
On Tue, Jun 2, 2009 at 4:42 PM, Sohail Somani <sohail@taggedtype.net> wrote:
Pre-emptive please don't make it header-only comment ;-) I second this.
Unless it actually makes sense for it to be header-only. E.g. It just happens to consist entirely of class/function templates. But yeah. ;-)
Don't give them any ideas! -- Sohail Somani http://uint32t.blogspot.com
On Tue, Jun 2, 2009 at 6:28 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
Also, I think it's useful to at the very least be able to iterate the stack frames and find source/line number information for each call in stack.
Provided I have a function that gets me a string that contains that information, I personally don't have a use case for such iteration. I can't think of what else I'd want to do with this data other than dump it somewhere as text. Can you?
Well, if you're saying that iterating over the frames to get source/line information when the to_string() already contains formatted source/line information is unnecessary since one could implement a parser to extract it, then eh, I'm not sure. It would be undesirable to be tied to a specific output format for fear of breaking someone's code that uses a parser to parse the output. The iteration need not necessarily be provided by the same interface. I mean your stack trace interface could be: class stack_trace { public: stack_trace(); ~stack_trace(); std::string to_string(); }; and you could have another class defined: class stack_frame_iterator { public: stack_frame_iterator(const stack_trace& trace); //begin() stack_frame_iterator(); //end() }; which at least separates the two. The main use case I had for knowing source / line information I described in my second post in this thread. In short it allows a more powerful implementation of the __FILE__ and __LINE__ pre-defined compiler macros. If you wanted to provide an overloaded global new/delete to, for example, provide cross platform memory diagnostics then __FILE__ and __LINE__ are insufficient since they would point inside the implementation of the operator. With stack frame iteration your operator new / delete could simply create a stack trace, move backward 1 level, and what you end up with is the equivalent of a __FILE__ / __LINE__ for the previous function, which is the only thing that would be helpful in that case. It could always store the entire stack trace instead of just the file / line that allocated the memory but that might be wasteful from a memory / performance standpoint.
On Tue, Jun 2, 2009 at 4:42 PM, Zachary Turner <divisortheory@gmail.com> wrote:
On Tue, Jun 2, 2009 at 6:28 PM, Emil Dotchevski <emildotchevski@gmail.com>wrote:
Also, I think it's useful to at the very least be able to iterate the stack frames and find source/line number information for each call in stack.
Provided I have a function that gets me a string that contains that information, I personally don't have a use case for such iteration. I can't think of what else I'd want to do with this data other than dump it somewhere as text. Can you?
Well, if you're saying that iterating over the frames to get source/line information when the to_string() already contains formatted source/line information is unnecessary since one could implement a parser to extract it, then eh, I'm not sure.
No, I meant that I can't think of a use case for extracting any semantic data from a stack trace.
The main use case I had for knowing source / line information I described in my second post in this thread. In short it allows a more powerful implementation of the __FILE__ and __LINE__ pre-defined compiler macros. If you wanted to provide an overloaded global new/delete to, for example, provide cross platform memory diagnostics then __FILE__ and __LINE__ are insufficient since they would point inside the implementation of the operator. With stack frame iteration your operator new / delete could simply create a stack trace, move backward 1 level, and what you end up with is the equivalent of a __FILE__ / __LINE__ for the previous function, which is the only thing that would be helpful in that case.
Although in most cases knowing how I ended up calling the function is also useful information, I agree that needing to go (possibly constant number) K levels up is a valid use case. I'd still prefer a simpler interface: typedef <unspecified> stack_frame; std::string to_string( stack_frame const & ); class stack_trace { public: stack_trace(); bool empty() const; stack_frame top() const; void pop(); }; std::string to_string( stack_trace const & ); Simple use: std::string s=to_string(boost::stack_trace()); Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
On Tue, Jun 2, 2009 at 4:47 PM, Christian Holmquist <c.holmquist@gmail.com>wrote:
- Loading debug info either for the currently running executable or from
an
offline executable
Care to elaborate a bit, I don't follow exactly. How is this useful compared to attaching a debugger?
It's not that uncommon that one would be running a debug build of something in an environment that doesn't have a debugger. Or perhaps a customer is using a release build and you don't want to give them private symbols, but you don't mind giving them public symbols. They can generate a useful stack trace this way for you. (How to output this without integrating logging facilities is, as you mention, something that would need to be worked out). The reason that I originally thought of this entire debugging library is actually because I thought it would be useful to add my own memory leak detection facilities a program I was writing, because I was tracing a difficult memory leak. (oh yea, might as well add memory corruption / leak detection to the list of cool things that would be possible with a library such as this). In Windows they have some CRT debugging functions that enable this sort of thing inside the CRT, but they do this by #define'ing new and delete to functions such as debug_new and debug_delete, this way with #defines they can use __FILE__, __LINE__, etc to track the location of allocations. It's preferable to overload operator new and delete instead, this way you solve a lot of problems with order of #includes, but if you overload operator new and delete you can't use the __FILE__ and __LINE__ macros or they will just refer to the source file / line number of the implementation of the overloaded operators. With a structured stack trace representation, you could simply move up 1 frame and get source / line information from inside the operators, ultimately allowing advanced memory leak / integrity checking via overloaded operators while still maintaining accurate source / line information. When the process exits, you could dump all detected memory leaks along with their entire stack traces, or if a double delete was detected you could dump an entire stack trace for where it was allocated. This was the original use case I had in mind, I thought of the first case (with private / public symbols) later. It also might be useful in a Q/A environment where if they detect a program crash they can give you a stack traec (although if the library is able to generate stack traces, even if only through the unhandled_exception handler, in release mode that might be sufficient to cover some of these other cases).
- Printing human readable stack traces from a running program
IMO getting a stack-trace really quick, and defer the print-out (using the dbghelp on windows for instance) until the user requests it would be more useful than printout only. Like:
FWIW DbgHelp library turned out to be grossly insufficient for what I needed, so my library is now using the DIA SDK. Which unfortunately relies on COM, but I don't think that should be too much of a problem.
- Assuming symbol information is loaded either for the running program or an offline program, format a block of memory in a human readable format to print the structure of the memory (for example, display member values of a class with field names, given a block of memory representing an instance of the class)
Care to provide an example here?
The easiest example to understand here is that you're actually using this library to _implement_ your own debugger. You have debug information for the debugee because it was generated by your compiler, your process is the debugger, you want to display the value of a symbol in the watch window. You know that the virtual address of the symbol is 0x12345678. You look it up in the symbol table and find that that the symbol at this location is of type: class foo { int a; double d; }; clearly sizeof(foo) == 12, so the above would be able to take the address 0x12345678, interpret the first 4 bytes as a signed integer, the last 8 bytes as a double precision floating point, and return those values to the caller to display in a watch window. The best way to get this information back to the caller is open for discussion. I was thinking it would just be a simple string pre-formatted according to some rules of the library, but it's not hard to imagine other possibilities. For example, a "symbol_field_iterator" that returned objects which you could call to_string() on, or value_as<T> so you could get the actual data in the correct type.
- launch process under a debugger and receive basic types of debugging notifications.
What kind of notifications are you referring to?
The types needed in order to implement a debugger. module was loaded into the process, thread was just created, exception just occurred, etc. I've no idea how debuggers are implemented under Linux, but in windows there's a debug api that provides these events very easily. I'm sure there's something similar under Linux, even if it's difficult, because GDB does some fairly advanced things.
Zachary Turner wrote:
In my spare time I have been working on a library to analyze debug information from a running program. It either already does, or I would like to have it before I'm done, support all of the following (I'm sure there are plenty of other neat additions that I haven't thought of):
I've started this work as part of Boost.Test functionality. I'll be happy to offload this to you, but please make sure I can reuse it from inside Boost.Test. Most important consideration should be portability. Please see boost/test/debug.hpp for details.
- Loading debug info either for the currently running executable or from an offline executable - Printing human readable stack traces from a running program
Yes. I never got to finish it. We've got at least 3 different underlying runtimes to support.
- Dumping stack traces to a file in release mode. In this case it's usually just a dump of the entire stack in binary. - Matching dumped stacks from step 3 to debug information offline to get post-mortem information. - Assuming symbol information is loaded either for the running program or an offline program, format a block of memory in a human readable format to print the structure of the memory (for example, display member values of a class with field names, given a block of memory representing an instance of the class) - Iteration of loaded modules - Check whether debugger is attached
I named this function boost::debug::under_debugger. It works in number scenarios, though *nix implementation is rather 'hacky'.
- output stream that goes to the debugger console, and is not visible in the debugged process. I'm not sure about the feasibility under non-windows platforms (it's very easy in windows), but I would think that if it's possible to figure out the PID of the process debugging you, that it should be possible to send output to their stderr which should achieve the same effect. - launch process under a debugger and receive basic types of debugging notifications.
I opted for interface which allows developer to tell that the debugger has to be attached here. I named this function boost::debug::attach_debugger I also have following functions in this module: debugger_break - cause program to break execution in debugger at call point detect_memory_leaks - switch on/off detect memory leaks feature break_memory_alloc - cause program to break execution in debugger at specific allocation point set_debugger - debugger setup If you serious about finishing this work you can count on my help both with transition on my code and review process in Boost. Regards, Gennadiy
Gennadiy Rozental wrote On Saturday, June 06, 2009 3:15 AM
I also have following functions in this module:
debugger_break - cause program to break execution in debugger at call point
[snip]
break_memory_alloc - cause program to break execution in debugger at specific allocation point
The function name connotes causing the following memory allocation(s) to fail, which is useful in its own right for testing error handling. How is break_memory_alloc() different from debugger_break() in practical terms? IOW, if break_memory_alloc() causes a break at the next allocation, it doesn't seem any different than preceding the allocation call with debugger_break(). _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
On Sat, Jun 6, 2009 at 6:53 AM, Stewart, Robert <Robert.Stewart@sig.com>wrote:
Gennadiy Rozental wrote On Saturday, June 06, 2009 3:15 AM
I also have following functions in this module:
debugger_break - cause program to break execution in debugger at call point
[snip]
break_memory_alloc - cause program to break execution in debugger at specific allocation point
The function name connotes causing the following memory allocation(s) to fail, which is useful in its own right for testing error handling.
How is break_memory_alloc() different from debugger_break() in practical terms? IOW, if break_memory_alloc() causes a break at the next allocation, it doesn't seem any different than preceding the allocation call with debugger_break().
The user can't control when the next allocation will happen though. He may be in a multi-threaded environment and the next allocation might happen from another thread. It might even happen because you corrupt some memory which accidentally invokes malloc or new via a bogus function pointer which just happens to point there (unlikely, though). So it definitely provides functionality to the user not possible without a separate function for it.
Stewart, Robert <Robert.Stewart <at> sig.com> writes:
Gennadiy Rozental wrote On Saturday, June 06, 2009 3:15 AM
I also have following functions in this module:
debugger_break - cause program to break execution in debugger at call point
[snip]
break_memory_alloc - cause program to break execution in debugger at specific allocation point
The function name connotes causing the following memory allocation(s) to fail,
which is useful in its own
right for testing error handling.
How is break_memory_alloc() different from debugger_break() in practical terms? IOW, if break_memory_alloc() causes a break at the next allocation, it doesn't seem any different than preceding the allocation call with debugger_break().
break_memory_alloc take as an argument concrete allocation index and it should break at this particular allocation. We may consider designing interface which will support breaking *next* allocation, but it's not there yet. Note that in both cases you actually do not know where the allocation occurs. The primary usage of this functionality is to help with memory leaks detection. Gennadiy
participants (7)
-
Christian Holmquist -
Emil Dotchevski -
Gennadiy Rozental -
Jonathan Franklin -
Sohail Somani -
Stewart, Robert -
Zachary Turner