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

[Mac] Wesnoth freezing (GNA #18144) #1260

Closed
wesnoth-bugs opened this issue May 8, 2017 · 15 comments
Closed

[Mac] Wesnoth freezing (GNA #18144) #1260

wesnoth-bugs opened this issue May 8, 2017 · 15 comments
Assignees
Labels
Bug Issues involving unexpected behavior. macOS OS-specific issues that apply to Apple macOS. Postponed Issues which cannot be worked on at this time.

Comments

@wesnoth-bugs
Copy link

Original submission by velensk on 2011-05-15

On occasion, Wesnoth will freeze and can only be exited via the force quit command.

This bug did not occur on 1.9.5

I have not done a lot of other testing however it will occur on a semi-frequent basis during multiplayer where the game shows me as disconnecting.

(Reproduced on OSX 10.5.8)
Release: 1.9.6
Priority: 5 - Normal
Severity: 4 - Important

@wesnoth-bugs wesnoth-bugs added Bug Issues involving unexpected behavior. macOS OS-specific issues that apply to Apple macOS. Postponed Issues which cannot be worked on at this time. labels May 8, 2017
@wesnoth-bugs
Copy link
Author

Modified on 2011-05-21

theron wrote:

This kind of freeze does happen in SP too.

In my experience this happens at least every other scenario, but never during the same action.

Wesnoth's music is still playing, but a force quit is needed.

Wesnoth 1.9.6 / Mac OS X 10.6.7 / MacBook Air (1. gen)

@wesnoth-bugs
Copy link
Author

Modified on 2011-06-21

velensk wrote:

The problem persists in 1.9.7

@wesnoth-bugs
Copy link
Author

Modified on 2011-06-23

theron wrote:

I wonder if its somehow hardware/driver related:

While I'm getting this freeze on my MacBook Air (in 1.9.7 too)

I can't remember having experienced this on my Mac mini server.

(But I'm playing more often on my MacBook Air.)

MacBook Air (1. gen)

1x Core2Duo @ 1.8 GHz

64 GB SSD

2 GB RAM

Intel GMA X3100 / 144 MB VRAM

OS X 10.6.7

(Sophos Anti-Virus for Mac Home Edition)

Mac mini server (2010)

1x Core2Duo @2.66 GHz

2x 500 GB HD (configured as RAID 1)

4 GB RAM

NVIDIA GeForce 320M / 256 MB VRAM

OS X Server 10.6.7

@wesnoth-bugs
Copy link
Author

Modified on 2011-06-23

velensk wrote:

Incase it makes any difference, mine is

Model Name/Identifier: iMac8,1

Intel Core 2 Duo 2.4 GHz

3 GB RAM

System 10.5.8

@wesnoth-bugs
Copy link
Author

Modified on 2011-06-29

theron wrote:

For me it makes a huge difference if I set "preferences:advanced:animate map" to off.

I've chosen HttT-1(hard) as a test scenario and played lots of games.

With map animations I'm getting a freeze in up to 2/3 of the games.

Without map animations I had only 2 freezes (one in HttT-1 and one in HttT-2).

If this works for you too, having a look at the changes between 1.9.5 and 1.9.6+ regarding (map) animations might be a good idea.

I appreciate any advice how to investigate this issue further.

@wesnoth-bugs
Copy link
Author

Modified on 2011-07-01

theron wrote:

"bug #18126 Wesnoth freezes after attack click" looks like the same isssue.

But for me it's not related to some specific action.

It can happen while only watching the AI's turn.

@wesnoth-bugs
Copy link
Author

Modified on 2011-07-08

theron wrote:

Wow!

I just had a freeze while in the addon-manager (installing your new campaign btw).

Now I have a new suspect:

In 1.9.6 experimental support for OpenMP was added (listed under important changes and new features):

OpenMP has been tested under Linux and Windows but needs some testing under Mac OS X, which is why it is currently optional. In particular we are interested in abnormal CPU usage when OpenMP is enabled. Please report to Boucman for debug instructions

<<

If the animation engine makes use of OpenMP there would be a relation.

Also only Mac users seem to be affected.

(I see no abnormal CPU usage.)

@wesnoth-bugs
Copy link
Author

Modified on 2011-08-04

velensk wrote:

As a note: This problem persists in 1.9.8

@wesnoth-bugs
Copy link
Author

Modified on 2011-08-11

crab changed title: Wesnoth freezing -> [Mac] Wesnoth freezing

@wesnoth-bugs
Copy link
Author

wesnoth-bugs commented May 8, 2017

Modified on 2011-10-05

alarantalara wrote:

Profile for 1.9.9 while in lock.

(file #14210)

alarantalara added attachment: deadlock

@wesnoth-bugs
Copy link
Author

Modified on 2011-10-05

alarantalara wrote:

Since I've only experienced the error in that one function, I may try disabling OpenMP on the Mac OS for just that function as a workaround.

Thoughts?

@wesnoth-bugs
Copy link
Author

Modified on 2011-11-22

alarantalara changed status: None -> Postponed

alarantalara wrote:

This post suggests that turning off OpenMP does indeed resolve the problem. http://forums.wesnoth.org/viewtopic.php?f#6&t35426

Marking as postponed rather than fixed since turning OpenMP off does not resolve whatever bug is associated with it.

@wesnoth-bugs
Copy link
Author

Modified on 2012-01-29

shadowmaster changed status: Postponed -> None

@wesnoth-bugs
Copy link
Author

Modified on 2012-01-31

alarantalara changed status: None -> Postponed

@hrubymar10
Copy link
Member

I am testing OpenMP with current 1.14 branch right now. I'll let you know if it is still freezing.

jostephd pushed a commit to jostephd/wesnoth that referenced this issue Oct 6, 2018
After some discussion, we concluded that this code was unmaintained, not even used in
some places (display.cpp, units/frame.cpp), leaving the only area that really used it
at all the image surface cache. Considering there was never really a conclusive benchmark
of its benefits and because said surface cache will be used a lot less going forward,
we're just removing it and simplifying everything for everyone.

Closes wesnoth#1260 since it's now irrelevant.
jostephd pushed a commit to jostephd/wesnoth that referenced this issue Oct 7, 2018
After some discussion, we concluded that this code was unmaintained, not even used in
some places (display.cpp, units/frame.cpp), leaving the only area that really used it
at all the image surface cache. Considering there was never really a conclusive benchmark
of its benefits and because said surface cache will be used a lot less going forward,
we're just removing it and simplifying everything for everyone.

Closes wesnoth#1260 since it's now irrelevant.

(cherry-picked from commit 3792612)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Issues involving unexpected behavior. macOS OS-specific issues that apply to Apple macOS. Postponed Issues which cannot be worked on at this time.
Projects
None yet
Development

No branches or pull requests

3 participants