VirtualBox

Ticket #13687 (closed defect: invalid)

Opened 5 years ago

Last modified 4 years ago

Emacs redraw issues with >1 Virtualbox CPU

Reported by: i4nt Owned by:
Component: other Version: VirtualBox 4.3.20
Keywords: Cc:
Guest type: other Host type: Mac OS X

Description

It sounds totally crazy, but yeah, with one VB CPU, Emacs redraws fine. With 2+ CPUs it's really glitchy.

The easiest way to repro this is fire up emacs with a decently large file, and do an incremental search (by typing "Ctrl-s search-term")and wrap from bottom to top a couple of times.

This forum post describes the problem well:  http://askubuntu.com/questions/418546/emacs-screen-drawing-issues-over-ssh

I have reproduced this with Ubuntu 12.04 and 14.04, with bash and zsh, with properly configured UTF-8 locales, with TERM=xterm-256, and with customized and minimal .emacs.d and .bashrc configs.

Net effect is that I can either have a functional search in my editor, or I can run my tests in a reasonable amount of time.

Attachments

VBox.log Download (53.1 KB) - added by aph123 4 years ago.
infocmp.txt Download (3.3 KB) - added by aph123 4 years ago.
typescript Download (67.0 KB) - added by aph123 4 years ago.
bug13687-native.png Download (61.9 KB) - added by vushakov 4 years ago.
Screenshot of the same problem reproduced without VirtualBox

Change History

comment:1 Changed 4 years ago by aph123

+1

This has been driving me crazy for quite some time.

VirtualBox; 4.3.24

Host; OS X 10.10.2

Guest; Linux (Ubuntu 14.04 and more I've tested many distros)

Turning down the CPU count to one fixes the glitch but obviously not ideal.

Last edited 4 years ago by aph123 (previous) (diff)

comment:2 Changed 4 years ago by frank

I would like to see VBox.log files. Also, do you have 3D enabled in the VM settings and does it make any difference if you disable 3D?

Changed 4 years ago by aph123

comment:3 follow-up: ↓ 5 Changed 4 years ago by aph123

3D disabled.

In fact, I am running VirtualBox headless and SSH-ing into it.

comment:4 Changed 4 years ago by degoydegoy

I'm seeing this with only one cpu and 3d acceleration turned on, running x-windows emacs in seamless mode. I turned off 3d acceleration and have not seen the problem yet, but it's intermittent and may yet show up again without 3d. Version 4.3.24, centos 7 guest, windows 8.1 host.

Last edited 4 years ago by degoydegoy (previous) (diff)

comment:5 in reply to: ↑ 3 Changed 4 years ago by vushakov

Replying to aph123:

In fact, I am running VirtualBox headless and SSH-ing into it.

If you can reproduce it under screen(1), please, can you capture emacs output with screen's log command (C-a : to get to the screen's prompt, then log on or log off respectively). Please, turn it on before doing that problematic C-s search in emacs. Turn it off after the display is corrupted. You will get ~/screenlog.<N> file where N is the window number.

You might need to use TERM=screen-256color inside screen, if 256-color mode is required to trigger the bug.

Alternatively, you may use script(1).

Just in case, please, provide infocmp(1) output for your $TERM. You say you use TERM=xterm-256 but the terminal name is xterm-256color. If you really do use xterm-256, you must have a private definition somewhere.

Changed 4 years ago by aph123

Changed 4 years ago by aph123

comment:6 Changed 4 years ago by vushakov

I think this is an emacs bug.

I have managed to reproduce it natively on my real multicore Ubuntu 12.04 machine with emacs -nw ~/.bashrc and C-s HIST C-s (and hold), like in that askubuntu post linked above.

I haven't looked into emacs internals too closely, but I'd guess the problem is with redisplay preemption.

The typescript attached above demonstrates that problem. A cursor move command is lost and after that the display becomes garbled. That happens several times. The first one is analyzed below.

If I interpret the typescript correctly, the cursor is on the "r" in "format" on file line 54 when search is started. That emacs also has highlight-sexp turned on, it seems, so it has quite a bit of repainting to do during the search.

Search the typescript for 42;18H cursor move command that puts the cursor after Regexp I-search: .

Just before that it moved to 21;20H - the current position on "r" in "format". Then there's a command sequence that corresponds to tty_show_cursor(), which implied update end hook was called at that point.

The we move to 42,18 and emit "d", the first char searched for.

Then screen update seems to resume. You can see ^H^H^H to back up to the open paren of "(format ", and then "(format " is emitted in appropriate faces (hilight of the format sexp is turned off, I guess, since the point moves to "d" in "Loading"). The problem is that there's no move back to 21,20, the "r", where that whole sequence must be emitted to make sense.

Changed 4 years ago by vushakov

Screenshot of the same problem reproduced without VirtualBox

comment:7 Changed 4 years ago by vushakov

  • Status changed from new to closed
  • Resolution set to invalid

Not a VirtualBox bug. Closing as invalid.

comment:8 Changed 4 years ago by aph123

Interesting, I've never managed to reproduce this outside VirtualBox.

comment:9 Changed 4 years ago by vushakov

Yes, it's harder to reproduce natively, but I've just reproduced it a couple more times by holding C-s down for less than a minute, so it's not even that much harder.

Typescript analysis indicated algorithmic bug in emacs, so then it was just a question of patience :).

I guess under virtual box because of different timing/scheduling/??? the window of opportunity becomes wide enough for this bug to manifest more often.

comment:10 Changed 4 years ago by aph123

Makes sense, thanks a lot for your analysis.

If anybody finds this thead in the future, here is a (brute force) workaround;

Add the following to your init.el

(add-hook 'isearch-update-post-hook 'redraw-display)

Alternatively this patch to emacs seems to solve the problem;  https://github.com/martintrojer/emacs/commit/bdff1ff98d02f4307659c052d0b35a40a36f0706

Last edited 4 years ago by aph123 (previous) (diff)
Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use