Kernel debugger does not redraw screen on exit

[andreasf]

When entering the kernel debugger via F12, typing e.g. threads (so that the screen gets completely white), a subsequent exit does not invalidate and redraw the screen. Only e.g. the blinking cursor of the terminal is visible. Finding the Terminal window and maximizing it and moving it around removes these artifacts.

Experienced in r23891.

[axeld]

Duplicate of #1421.

[andreasf]

Hm, bug #1421 is marked invalid with the argument that no end user is expected to encounter this situation ... yet on Haiku's frontpage Ingo invites users to actually use the kernel debugger!

[axeld]

Hehe :-) Our target audience in the long run won't need the kernel debugger anymore - for now it helps a lot, of course. I wouldn't mind if someone would provide a (clean) patch for the problem, but as I said in #1421, I don't think it's worth to spend much time on it.

The kernel debugger shouldn't be seen as part of the usual interface :-)

[andreasf]

Well, a clean fix could be to extend the kernel debugger through a client-side tool that silently executes kernel debugger commands without the screen going white and afterwards printing their results to the tool's stdout, thinking of DTrace there.

[axeld]

All KDL commands rely on the fact that you have complete ownership of the system (ie. interrupts are turned off, other CPUs are halted), so that's not the way to go.

Most stuff you can retrieve using KDL can also be retrieved in userland, though, and there are many tools available for this (GDB, list{area|image|port|sem|...}, ...), too.

But sometimes userland just isn't working right, so that's only a part time option. For that one could also do a tool that's able to have access to the "traced" buffer, though.

[euan]

perhaps a temporary hotkey could be added eg, alt+12 that app_server could use to force a redraw? It happened today when I was wondering what terminal was up to when I typed lsdev then tab and it hanged.

[mmlr]

Anyway, it's implemented in r24025.