[FIXED] Game New Error!

[gameboy]

Assertion failed: "status == DISP_CHANGE_SUCCESSFUL"

Location: wsdl.cpp:438 (SDL_SetVideoMode)

Call stack:

OnActivate (wsdl.cpp:836)

hWnd = 0x002FD0A0 (..)

state = 2425728 (0x00250380)

__formal = 0x00250380 (..)

fMinimized = (unavailable)

OnMessage (wsdl.cpp:1288)

hWnd = 0x76ACFD72 (..)

uMsg = 2425728 (0x00250380)

wParam = 6 (0x00000006)

lParam = 0 (0x00000000)

GetWindowLongW (:0)

GetWindowLongW (:0)

CallWindowProcW (:0)

CallWindowProcW (:0)

wglSwapBuffers (:0)

GetWindowLongW (:0)

GetWindowLongW (:0)

ReleaseDC (:0)

WCSToMBEx (:0)

KiUserCallbackDispatcher (:0)

PeekMessageW (:0)

SDL_PumpEvents (wsdl.cpp:1339)

msg =

hwnd = 0x01E47C74 (..)

message = 2425728 (0x00250380)

wParam = 257 (0x00000101)

lParam = 17 (0x00000011)

time = 3223126017 (0xC01D0001)

pt = { x = 9163529 (0x008BD309), y = 1457 (0x000005B1) }

SDL_PollEvent (wsdl.cpp:1349)

ev = 0x00141D8A ->

type = [8] { 131 (0x83), 196 (0xC4), 4 (0x04), 133 (0x85), 192 (0xC0), 15 (0x0F), 132 (0x84), 154 (0x9A) }

active = { type = 131 (0x83), gain = 196 (0xC4), state = 4 (0x04) }

key =

type = 131 (0x83)

keysym = { sym = -1702621248, unicode = 1 (0x0001) }

motion = { type = 131 (0x83), x = 34052 (0x8504), y = 4032 (0x0FC0) }

button =

type = 131 (0x83)

button = 196 (0xC4)

state = 4 (0x04)

x = 4032 (0x0FC0)

y = 39556 (0x9A84)

resize = { type = 131 (0x83), w = 2592346048 (0x9A840FC0), h = 3204448257 (0xBF000001) }

expose = { type = 131 (0x83) }

quit = { type = 131 (0x83) }

user = { type = 131 (0x83), code = 2592346048 (0x9A840FC0), data1 = 0xBF000001 }

PumpEvents (main.cpp:183)

profile2__ =

m_Name = 0x511CA52F -> (unavailable - internal error)

ev =

ev =

type = 125 (0x7D)

active = { type = 125 (0x7D), gain = 25 (0x19), state = 109 (0x6D) }

key =

type = 125 (0x7D)

keysym = { sym = 1913259, unicode = 42880 (0xA780) }

motion = { type = 125 (0x7D), x = 16493 (0x406D), y = 12715 (0x31AB) }

button =

type = 125 (0x7D)

button = 25 (0x19)

state = 109 (0x6D)

x = 12715 (0x31AB)

y = 29 (0x001D)

resize = { type = 125 (0x7D), w = 1913259 (0x001D31AB), h = 31762304 (0x01E4A780) }

expose = { type = 125 (0x7D) }

quit = { type = 125 (0x7D) }

user = { type = 125 (0x7D), code = 1913259 (0x001D31AB), data1 = 0x01E4A780 }

profile2__ =

m_Name = 0x01E47C74 (see above)

data = (unsupported basic_string<char,char_traits<char> >)

Frame (main.cpp:356)

realTimeSinceLastFrame = 0.000000 (0x0101356B)

need_update = (bool)0xE4

profile2__ =

m_Name = 0x3DD8F88A -> (unavailable - internal error)

need_render = true

profile2__ =

m_Name = 0x003856E4 -> "frame"

profile2__ =

m_Name = 0x003856E4 (see above)

RunGameOrAtlas (main.cpp:507)

argc = 1323332 (0x00143144)

argv = 0x00000001

args =

m_Args = (unsupported vector<pair<CStr8,CStr8> >)

m_Arg0 =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 47 ('/')

paths =

m_root =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 49544

m_rdata =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 0

m_gameData =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 41654

m_userData =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 57232

m_config =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 57212

m_cache =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 1

m_logs =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 31860

replay =

m_Stream = 0x01E47C70 -> (basic_istream<char,char_traits<char> >)

mod =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 63824

zip =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 0

paths =

m_root =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 49544

m_rdata =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 0

m_gameData =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 41654

m_userData =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 57232

m_config =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 57212

m_cache =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 1

m_logs =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 31860

builder =

m_VFS =

px = 0x00000001

pn =

pi_ = 0x00100000 ->

use_count_ = 1263159624 (0x4B4A4948)

weak_count_ = 1330531660 (0x4F4E4D4C)

m_Files = (unsupported vector<Path >)

m_TempDir =

path = (unsupported basic_string<wchar_t,char_traits<wchar_t> >)

separator = 4

main (main.cpp:550)

argc = 3116766 (0x002F8EDE)

argv = 0x00000001

wmain (wseh.cpp:380)

argc = 3458817 (0x0034C701)

argv = 0x00000001

utf8_argv = (unsupported vector<char * >)

ret = 0 (0x00000000)

utf8 = (unsupported basic_string<char,char_traits<char> >)

CallStartupWithinTryBlock (wseh.cpp:397)

ret = 0 (0x00000000)

RtlInitializeExceptionChain (:0)

RtlInitializeExceptionChain (:0)

errno = 13 (Insufficient access rights to open file)

OS error = 0 (no error code was set)

====================================

SVN Revision: custom build

System info:

(generated 2012-09-01 14:03:05 UTC)

[zoot]

That's a completely different error message and should have been posted in a separate topic?

[historic_bruno]

Hi, what were you doing when this error occurred? Was it during startup, resizing, switching fullscreen, etc. The more info you provide the better

[gameboy]

When I select the the Random option inside the map, the map name is: Alpane Valley, and then I chose three qbot game, When I press satrt button to start loading the game, but the game is loaded to 29%, the game is no longerloaded, I waited three minutes, and then switch to the desktop, an error window appears:

By the way: in the game loading process, I did not do anything, I'm just watching the patience to wait for the screen, thank you!

Edited September 3, 2012 by gameboy

[plumo]

ALT-tabbing can give errors , as far as I know.

[myconid]

The error is because SDL is failing to change the window size or resolution, but what isn't clear is if the error is separate from what is causing your game to hang when loading.

So, for starters you should:

1. change your config to run the game in windowed mode, and
   
2. completely clear your cache.
   

[historic_bruno]

(We don't use real SDL in Windows, but a buggy emulation of it)

How did you switch to the desktop? I've seen similar errors occur when people use Ctrl+Alt+Delete while the game is loading, which changes the active desktop thread, and the game loses ability to change display settings. Don't use Ctrl+Alt+Delete while the game is loading, if you're tempted to do so... in fact I'll add this to the known problems topic.

[gameboy]

When the progress of the game to reach 29% of the time, the progress of the game is no longer loaded, I waited for nearly three minutes, and the last before I settle down shift + ctrl + alt key.

The way: Do I need to wait for a longer game load time (to wait more than three minutes or longer)? Thank you!

I have a 4G memory.

I finally found a more specific error message:

By the way, I did not press shift + ctrl + alt key, I've been waiting for.

Edited September 4, 2012 by gameboy

[historic_bruno]

Very large or giant random maps can be very slow to generate, I would try a different random map and if that doesn't help, a smaller size. The out of memory error looks like a bug on that random map and is not related to how much RAM your computer has.

[gameboy]

I have 4G memory.

[Yves]

I have some crashes when loading maps too.

PC1 - Windows - Prebuilt binary --> Crashes most of the time

PC2 - Ubuntu - Manually compiled --> Works

PC 2 is my development client for both Windows and Linux (Dualboot). If I can reproduce the problem there, I can debug it.

Otherwise I'll have to find out what's the problem on PC1.

[historic_bruno]

I have 4G memory.

Doesn't matter, the random map generator is limited to 96 MB currently (we could increase this if necessary, but we'd need to balance that with the consequences of the game using more memory).

[myconid]

(We don't use real SDL in Windows, but a buggy emulation of it)

Yeah, I know. My point was that the error was caused when the window was switched, so it wasn't necessarily relevant to his loading problem.

Doesn't matter, the random map generator is limited to 96 MB currently (we could increase this if necessary, but we'd need to balance that with the consequences of the game using more memory).

Is that a contiguous "mini-heap" of static size that is allocated every time, or is it just a limit on total allocations? If Spidermonkey uses a compacting GC, it's very likely that only half that will ever be available to the javascript program.

[historic_bruno]

Is that a contiguous "mini-heap" of static size that is allocated every time, or is it just a limit on total allocations? If Spidermonkey uses a compacting GC, it's very likely that only half that will ever be available to the javascript program.

Hmm, according to the documentation it seems the full amount will be available to the script runtime.

[myconid]

Hmm, according to the documentation it seems the full amount will be available to the script runtime.

Right, and it also seems that Spidermonkey doesn't even have a compacting GC yet:

SpiderMonkey has a mark-sweep garbage collection (GC) with an optionally enabled incremental marking mode. The mark phase uses a mark stack, as required by incremental marking. Sweeping of objects without finalizers is deferred to a background thread.

Work is underway to build a generational GC and a compacting GC.

I'll go out on a limb and posit that gameboy's memory error wasn't a result of there not being enough free memory in the 96MB limit, it was because that 96MB became so fragmented due to the mark-and-sweep GC that the allocator wasn't able to find enough contiguous memory... It appears this is an issue they are trying to address in future versions (raising the memory limit could also help).

[Yves]

I have some crashes when loading maps too.

PC1 - Windows - Prebuilt binary --> Crashes most of the time

After removing everything related to the new shader effects from local.cfg it didn't crash at loading when we played the next game.

However it crashed later. At the moment it looks like a faulty ram module caused some instability and maybe was also the reason for some of the crashes. We've removed the module, reinstalled windows and played one game on a random map against three aegis-bots without crashing.

Now we could try enabling the shader effects again and see if it still crashes.

[gameboy]

My memory does not have any problems, I have enough memory.

That this problem what is the solution?

[myconid]

Choose a smaller map size! The problem is with the engine, not your computer.

historic_bruno, we shouldn't be hardcoding the JS runtime size, there should be a setting for it in the config.

[historic_bruno]

Choose a smaller map size! The problem is with the engine, not your computer.

historic_bruno, we shouldn't be hardcoding the JS runtime size, there should be a setting for it in the config.

I like config options for everything too, but I'm a programmer Last time I suggested a config for something like this, it was shot down because the game should be smart enough to know how much memory is needed for whatever task, and I understand that argument. In other words, the user shouldn't have to decide how much memory needs to be allocated for a given JS runtime. We could make it variable: specify a minimum and gradually scale it up according to the user's system specs.

[myconid]

Of course, but since the game isn't that smart yet, the choices we have are to either hardcode an arbitrary value, or to expose it as a config setting. gameboy's bug report is an excellent example of why the latter might be a better solution at this stage in development: instead of telling him he can't use the map size he wants, we could have told him to change a value in the config.

[Deiz]

Of course, but since the game isn't that smart yet, the choices we have are to either hardcode an arbitrary value, or to expose it as a config setting. gameboy's bug report is an excellent example of why the latter might be a better solution at this stage in development: instead of telling him he can't use the map size he wants, we could have told him to change a value in the config.

It still ends up being a probability game, though. I've had a few transient OOMs with the 32 MB AI runtime and then it'll get GC'd back down to ~10 MB. The bump to 32 MB mostly alleviates entity collection creep (as more units exist the longer the game goes on).

I think that permanently tackling the terrain analysis OOMs will require a) reworking that code to be friendlier to SpiderMonkey's mark-and-sweep GC, possibly waiting for SpiderMonkey to get a generational GC.

[myconid]

Is the AI runtime the same as the rmgen runtime? I haven't looked too deep into those parts of the engine, but I was under the impression they were separate.

[Deiz]

Oh, whoops. I was thinking of another thread where somebody was reporting AI OOMs.

Yes, the AI and RMS runtimes are separate. The RMS runtime is 96 MB, but some random map scripts still OOM frequently, even at rather small sizes. I'm not sure if it's due to massive memory usage or massive amounts of memory fragmentation (though it's probably a combination of the two).

[gameboy]

Hi,Man! Try to merge them, reduce memory consumption.

Edited September 10, 2012 by gameboy

[historic_bruno]

Of course, but since the game isn't that smart yet, the choices we have are to either hardcode an arbitrary value, or to expose it as a config setting. gameboy's bug report is an excellent example of why the latter might be a better solution at this stage in development: instead of telling him he can't use the map size he wants, we could have told him to change a value in the config.

I disagree that it's a better solution, that sounds like only sweeping the problem under the rug (no pun intended) Since random maps should be deterministic given a seed and the map settings, we should be able to reproduce gameboy's OOM error and debug it. Is the random map script wasting memory, is it generating too many entities, or do we really need to increase the runtime size? It's not something the user needs to control, in fact I would argue they shouldn't, because it's not a user preference bug a flaw somewhere in the game.

When debugging JS OOM errors, I would continue to advise against simply bumping the runtime size (as I did with Aegis Bot) and instead suggest testing with the GC run more frequently and investigating the scripts themselves. It's trivial to write a script that causes OOM errors, why couldn't it happen accidentally?