View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000569 | LDMud 3.3 | Efuns | public | 2008-09-10 08:49 | 2008-12-29 17:17 |
| Reporter | warp | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.3.717 | ||||
| Summary | 0000569: Extend caller_stack() to optionally include filename, function name and line number information | ||||
| Description | caller_stack( int arg) could be extended so arg is a bit-field with status flags, to allow better debugging tools in the mudlib. Bit 0: include interactive (as it's now) Bit 1: include full stack If Bit 1 is set, caller_stack() could return an array of arrays, not only with the previous objects, but with full code locations (object, function-name, filename, linenumber). Also, it would be important that this also works properly in the various error-handling-functions of the master object (runtime_error and heart_beat_error) to allow a custom, full stack trace for the error. A nicety would be, if it would also work for compilation errors in log_error (in which case it would show the trace up to the point where to compilation of buggy object was triggered). I don't know, whether the driver has easy access to that information, but especially cool would be, if another bit could extend the full stack with information about all the arguments which have been passed to the functions in the stack, so that error logging tools/debugging tools could dump them, but this change would already be very helpful without the arguments, too. | ||||
| Tags | No tags attached. | ||||
| related to | 0000586 | new | LDMud | Allow querying single stack frames using debug_info(DINFO_TRACE) |
|
|
Concerning your wish to have stack traces during the error-handler in the master: isn't that what debug_info(DINFO_TRACE,...) is just doing? |
|
|
Oh, indeed. I completely missed that this feature was added in 3.2.9. I guess this issue can be closed, then. |
|
|
The other part of the request... Mhmm, caller_stack() with that information would still be a quite bad stacktrace, because it only contains inter-object calls and you would miss a lot of the real stack. If a efun for getting a complete stacktrace is needed, it would probably be a new one or debug_info(). Collecting the stack is quite expensive though - ok for error handling, but I am not sure if one should do this routinely. BTW: If you need a stack trace for some odd reason without aborting the execution, you could perform some catch(raise_error("Dummy error\n");nolog); mixed stacktrace=debug_info(DINFO_TRACE,DIT_ERROR); and evaluate the stacktrace afterwards. |
|
|
debug_info(DINFO_TRACE, DIT_CURRENT) should work without the need for a raise_error. But with the returned information you can't distinguish between call_others and normal lfun calls, maybe we should add some flag to indicate this. |
|
|
Seems to me I should also read the fine documentation. ;-) Maybe a nice idea to add this, yes. I don't have a real application for this right now, but it would give the possibility to reconstruct the caller_stack from the complete trace... (Should we keep this feature here or in a separate bug filed for debug_info()?) |
|
|
Since most of this feature wish is already existing and the missing flag in the stack traces of debug_info() can be dealt with in 0000586 I close this one. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2008-09-10 08:49 | warp | New Issue | |
| 2008-09-10 09:12 | zesstra | Note Added: 0000770 | |
| 2008-09-10 10:47 | warp | Note Added: 0000772 | |
| 2008-09-10 12:52 | zesstra | Note Added: 0000778 | |
| 2008-09-11 00:31 | Gnomi | Note Added: 0000781 | |
| 2008-09-11 02:09 | zesstra | Note Added: 0000782 | |
| 2008-12-29 17:12 | zesstra | Relationship added | related to 0000586 |
| 2008-12-29 17:17 | zesstra | Status | new => closed |
| 2008-12-29 17:17 | zesstra | Note Added: 0000843 | |
| 2008-12-29 17:17 | zesstra | Resolution | open => no change required |
