-
Jon Olav Hauglid authored
This crash occured if the same debug trace file was closed twice, leading to the same memory being free'd twice. This could occur if the "debug" server system variable refered to the same trace file in both global and session scope. Example of an order of events that would lead to a crash: 1) Enable debug tracing to a trace file (global scope) 2) Enable debug tracing to the same trace file (session scope) 3) Reset debug settings (global scope) 4) Reset debug settings (session scope) This caused a crash because the trace file was, by mistake, closed in 3), leading to the same memory being free'd twice when the file was closed again in 4). Internally, the debug settings are stored in a stack, with session settings (if any) on top and the global settings below. Each connection has its own stack. When a set of settings is changed, it must be determined if its debug trace file is to be closed. Before, this was done by only checking below on the settings stack. So if the global settings were changed, an existing debug trace file reference in session settings would be missed. This caused the file to be closed even if it was in use, leading to a crash later when it was closed again. This patch fixes the problem by preventing the trace file from being shared between global and session settings. If session debug settings are set without specifying a new trace file, stderr is used for output. This is a change in behaviour and should be reflected in the documentation. Test case added to variables.test.
7f80cffa