The graphical debug tool lets you scroll back, so obviously somewhere it’s storing info.
Is there a limit to this? We’re wondering if storing debug info is causing us to consume memory.
The graphical debug tool lets you scroll back, so obviously somewhere it’s storing info.
Is there a limit to this? We’re wondering if storing debug info is causing us to consume memory.
What do you mean by scroll back?
A while back I posted a downloadable PDF that shows using gtrace as a FSA. See: Gtrace - Example finite-state automaton
Scroll back doesn’t ring a bell.
If you open the intelligent logging tool you’ll see debug messages. On the right is a scroll bar. You can scroll back through the messages.
You two are talking about two things. @anniepoo is taking about the gui that captures debug/3 calls and @EricGT is talking about gtrace
. The graphical tracer uses some memory to cache source files and information about clauses. As the number of involved files and clauses is finite (only clauses that come from loading a file are considered), this doesn’t cause infinite memory leaks.
The window that captures debug messages adds them to what xpce calls a dict
. AFAIK, they are never thrown away. So yes, if you keep this open and do not clear it you will keep loosing memory. Unless you log a lot of debug messages I doubt this is a serious leak though.
Note the ongoing work on webstat, a web-based dashboard for SWI-Prolog. That already has provisional support for debug messages. Currently, that will blow up your browser instead of Prolog if the number of messages is not limited