Opened 10 years ago

Closed 9 years ago

Last modified 9 years ago

#13687 closed defect (invalid)

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


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:

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 (4)

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

Download all attachments as: .zip

Change History (14)

comment:1 by aph123, 9 years ago


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 9 years ago by aph123 (previous) (diff)

comment:2 by Frank Mehnert, 9 years ago

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?

by aph123, 9 years ago

Attachment: VBox.log added

comment:3 by aph123, 9 years ago

3D disabled.

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

comment:4 by degoydegoy, 9 years ago

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 9 years ago by degoydegoy (previous) (diff)

in reply to:  3 comment:5 by Valery Ushakov, 9 years ago

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.

by aph123, 9 years ago

Attachment: infocmp.txt added

by aph123, 9 years ago

Attachment: typescript added

comment:6 by Valery Ushakov, 9 years ago

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.

by Valery Ushakov, 9 years ago

Attachment: bug13687-native.png added

Screenshot of the same problem reproduced without VirtualBox

comment:7 by Valery Ushakov, 9 years ago

Resolution: invalid
Status: newclosed

Not a VirtualBox bug. Closing as invalid.

comment:8 by aph123, 9 years ago

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

comment:9 by Valery Ushakov, 9 years ago

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 by aph123, 9 years ago

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;

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

© 2023 Oracle
ContactPrivacy policyTerms of Use