Webpositive is going crazy (strange/ascii characters on web pages and app_server crash)

[Giova84]

Well, is not the first time that I see this trouble, although it happens randomly: today is happened again:

Firstly I opened my inbox on Gmail, and instead of the usual page I just seen a page full of strange/ascii characters (see the attached screenshot), then I opened GitHub and I went to the issue page to add a ticket using the form: once I clicked on "Submit new issue" button, a KDL was triggered: unfortunately this KDL didn't recognized the "es" and the "bt" command, has claimed "Unrecognized command": the only command to exit from this KDL was "quit"; however, once I exit from the KDL, Haiku has become totally unresponsive: I was forced to press the power button on my computer.

Please notice that most of the time, using WebPositive, this KDL occurs when I am on the GitHub page: the last time this KDL was triggered when I attempted to attach an image to a ticket on GitHub and I think, due the develop nature of Haiku (and so the need to go on the GitHub page) that this issue is a great limit.

hrev50421

[pulkomandy]

If it doesn't say "welcome to kernel debugging land!" it is not a KDL. Most likely what you saw is the CLI for Debugger, which is loaded when the app_server crashes. It is a regular application crash, but there is no way to show the usual crash dialog (that requires a working app_server), so that console is loaded instead.

From there, you can use Debugger commands which are not the same as KDL. An useful one is save-report, which will write a crash report file on the desktop. You can then reboot (a single press of the power button should still do a clean shutdown in that situation) and upload that file.

From your screenshot it look like a sprite sheet is being displayed over the whole page. This is not ASCII characters, but a png file loaded from the page you were browsing.

[Giova84]

Replying to pulkomandy:

From there, you can use Debugger commands which are not the same as KDL. An useful one is save-report, which will write a crash report file on the desktop.

Thank you, I didn't know: the next time I will run such command.

You can then reboot (a single press of the power button should still do a clean shutdown in that situation)

I can't do a clean shutdown because in this particular situation the shutdown process is blocked by WebPositive: an alert window told me that "Is blocked on a modal panel" or something similar, and I cannot also click with the mouse pointer nor by the tab key on the keyboard: the mouse and the keyboard become totally unresponsive.

[pulkomandy]

Mouse and keyboard are unresponsive because you used the "quit" command, which completely stops the app_server. If you don't do it, the mouse may still work (it depends which part of the app_server is crashed). The keyboard is redirected to the emergency console so you can't recover it, however.

[Giova84]

Well, is happened again and this time I was able to save the report as you suggested; however, also if this time I haven't choosed to exit from the debugger screen, I choosed the resume option (otherwise I don't see any way to exit from the debugger screen), but the mouse was still unresponsive, WebPositive was still blocked on a modal panel, and I had to force again the shutdown by long pressing the power button.

I attach the debug report.

[Giova84]

Well, however now I also have another debug report, this time specific from WebPositive itself instead of from the app_server: this crash simply occurs with the GUI version of the debugger, and is triggered, when on GitHub page, I click on the link "collaborators", placed inside the settings page.

I attach this report too.

[Giova84]

Just for the record: I noticed the exact same behaviour with Gobe Productive, but with this application the issue occurs very randomly and I'm not able to reproduce it every time.

When will occur again I will attach the debug report from the full-screen debugger.

[waddlesplash]

Seems this hasn't happened in 3 years then, so closing as not reproducible. Some of the backtraces in the attached report look like #6354, so they may be fixed for good.

[nielx]

Remove milestone for tickets with status = closed and resolution != fixed