Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

AROS crashes hard if you drag the Wanderer screen rapidly up and down while several Demos are running. #635

Open
harbin-ctrl opened this issue Feb 8, 2024 · 0 comments
Labels
bug Something isn't working

Comments

@harbin-ctrl
Copy link

harbin-ctrl commented Feb 8, 2024

AROS crashes hard if you drag the Wanderer screen rapidly up and down while several graphical Demos are running at the same time.

Mouse does not move, OS no longer responds in any way. Full reboot necessary.

Bug is present in AROS (latest version as of AROS-20240206-pc-i386-boot-iso, AROS-20240206-pc-x86_64-boot-iso, and all other versions I have tested. It is present when running under qemu (under macOS X on an M1), on native hardware (on a ASUS Verizon Mini PC), on VirtualBox, and in all other variations, emulations, and hardware I've run it on. It is present on V0, or V1. It is also present on Icaros and AROS One.

To Reproduce
Steps to reproduce the behavior:

  1. Install AROS (or Icaros, as you please), and the contrib packages, for Intel architecture, 386 or x64, your choice. Install the correct contrib package for the AROS you've installed.
  2. Boot up AROS. Which video driver does not seem to matter. Mostly I tested it under VESA, but it happens on Native too.
  3. Under Extras/Demos, click on "Start Some Demos" script file so that nine demos are running. Or you can run Start Some Demos2. Either way. Or both!
  4. Rapidly drag the Wanderer screen up and down many times. Maybe five or 10 times. Then let go. It will hard crash when you let go of the mouse button.

It might not always crash, but things I've noticed that make it more likely to crash:

  1. More demos running. Fewer demos makes it less likely to crash. At about 4 or so it's basically guaranteed.
  2. High resolution. This makes it crash faster or more easily.
  3. Higher color depth. Same as 2.
  4. More dragging of the screen. It won't crash until you let go of the mouse button.
  5. Faster dragging on the screen. Really flick that thing up and down!
  6. A slower computer. The faster the computer, the less likely it is to crash.

Things I feel like make it more likely to crash, but not entirely sure:

  1. VESA vs Native. Native seems just a little bit more robust (less likely to crash).
  2. Having Opaque Commodity running. Again, not sure here.

That being said, It's easily reproducible if you set up a worst-case-scenario. By "High resolution", in my case, I mean "1280x1024", at 32 bit color, VESA. Run both Startsomedemos and Startsomedemos2.

Expected behaviour
It should happily continue to run. You know, maybe a slowdown because of all that's going on, but a hard crash is never right.

@harbin-ctrl harbin-ctrl added the bug Something isn't working label Feb 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant