[Bug gdb/28948] New: Enabling/disabling logging over an interpreter switch can crash gdb

[Bug gdb/28948] New: Enabling/disabling logging over an interpreter switch can crash gdb

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28948

            Bug ID: 28948
           Summary: Enabling/disabling logging over an interpreter switch
                    can crash gdb
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: gdb
          Assignee: unassigned at sourceware dot org
          Reporter: aburgess at redhat dot com
  Target Milestone: ---

Try this GDB session:

 (gdb) file /path/to/some/executable
 (gdb) set logging file /tmp/gdb.log
 (gdb) set logging debugredirect on 
 (gdb) set logging enabled on 
 Copying output to /tmp/gdb.log.
 Redirecting debug output to /tmp/gdb.log.
 (gdb) set debug infrun 1
 (gdb) start
 ... snip ...
 (gdb) tui enable

 # Then at the TUI prompt:

 (gdb) set logging debugredirect off
 (gdb) set logging enabled off
 (gdb) stepi
 (gdb) stepi
 (gdb) stepi

 # By this point GDB has usually crashed for me.

This is very similar to this bug:

  https://sourceware.org/bugzilla/show_bug.cgi?id=28620

It might almost be considered a duplicate of that bug, but I'm not 100% sure
the same fix for the previous will also fix this, though the underlying problem
is identical in nature.

What happens is that when we enable logging, GDB stashes the current output
file descriptors to one side, and replaces them with alternative file
descriptors.  Then, when we switch interpreter (tui enable) we replace the
current output streams with the streams for the new interpreter.

Then, when we disable logging, we replace the current streams (those for the
tui now) with the earlier backed up streams (those from before logging was
enabled), which happen to be the streams for the CLI.

At this point, weird stuff happens.  Usually the TUI will immediately disappear
from the screen, and usually GDB crashes pretty quickly.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28948] Enabling/disabling logging over an interpreter switch can crash gdb

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28948

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
I've been looking at logging oddities a bit today and I think
maybe this entire area could be simplified.

The basic idea is to separate gdb_stdout (and stderr and stdlog)
from the raw, underlying stdout/log.

Most code uses gdb_stdout, and this would still be managed
by the particular interpreter.  This way MI can wrap the
output in the syntax it uses.

However, the new idea is to have a global raw_stdout and raw_stdlib.
The interp-provided streams would be required to redirect to these
dynamically.

The "set logging" commands would affect just the raw_ globals.
This way, switching between interpreters would be completely fine.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28948] Enabling/disabling logging over an interpreter switch can crash gdb

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28948

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
I'm also wondering if logging out to be per-ui.
It seems to me that this would make the most sense,
because otherwise the log would include redundant info.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28948] Enabling/disabling logging over an interpreter switch can crash gdb

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28948

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
After deeper investigation I found some problems with my idea.
The basic issue is that there's no good spot to put the logging:

If the logging is early, then anything logged won't be wrapped
in MI output formatting.
However, if the logging is late, then it won't happen at all
for the TUI, since it normally doesn't really use the output
stream at all.

Maybe it can be salvaged somehow.


For the TUI, I tend to think we should merge the TUI and CLI interps.
That might eliminate some of the weirdness.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug gdb/28948] Enabling/disabling logging over an interpreter switch can crash gdb

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=28948

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I think we can salvage this idea by having the interp resume
methods install filtering streams that then forward to
the ui's own stream (that possibly does logging).

The TUI would then save and restore the final raw streams.

This way logging will work correctly in all cases and so
will the MI filtering.  Also this should fix bug #28620
and bug #17697.

-- 
You are receiving this mail because:
You are on the CC list for the bug.