gui/common/functions_page_session.js(174): Error: Size only accepts strings or GUISize objects

[Andrei]

When I start a new game, it doesn't matter the map I get only a huge circle: here's a ​screenshot and a ​video with the bug. And the output of pyrogenesis_dbg:

TIMER| InitVfs: 6.28272 ms
TIMER| InitScripting: 2.62648 ms
TIMER| CONFIG_Init: 10.9219 ms
TIMER| write_sys_info: 1.12136 ms
TIMER| ps_console: 5.00708 ms
TIMER| ps_lang_hotkeys: 4.32716 ms
TIMER| common/setup.xml: 13.6533 ms
TIMER| common/styles.xml: 1.8468 ms
TIMER| common/sprite1.xml: 41.6079 ms
TIMER| common/init.xml: 14.132 ms
TIMER| pregame/mainmenu.xml: 75.108 ms
TIMER| common/global.xml: 1.93192 ms
TIMER| InitRenderer: 32.0211 ms
TIMER| SimulationInit: 2.881 ms
TIMER| Init_miscgamesection: 26.0635 ms
SND| alc_init: success, using ALSA Software
TIMER| common/setup.xml: 1.759 ms
TIMER| common/styles.xml: 2.11024 ms
TIMER| common/sprite1.xml: 81.4024 ms
TIMER| common/init.xml: 18.9571 ms
TIMER| loading/loading.xml: 3.22424 ms
TIMER| common/global.xml: 1.27692 ms
TIMER| common/setup.xml: 2.15872 ms
TIMER| common/styles.xml: 2.22512 ms
TIMER| common/sprite1.xml: 77.4852 ms
TIMER| common/init.xml: 23.1116 ms
TIMER| session/session.xml: 68.2606 ms
TIMER| session/manual.xml: 3.00416 ms
TIMER| common/global.xml: 10.2518 ms
ERROR: GUI page 'page_session.xml': Failed to call init() function
GAME STARTED, ALL INIT COMPLETE
gui/common/functions_page_session.js(174): Error: Size only accepts strings or GUISize objects
ERROR: JavaScript Error (gui/common/functions_page_session.js, line 174): Error: Size only accepts strings or GUISize objects
TIMER| shutdown Scheduler: 7.92 us
TIMER| shutdown mouse stuff: 49.04 us
TIMER| shutdown Pathfinder: 180.919 us
TIMER| shutdown game scripting stuff: 14.8534 ms
TIMER| shutdown actor stuff: 11.28 us
TIMER| shutdown TexMan: 5.6 us
TIMER| shutdown Renderer: 582.64 us
TIMER| shutdown ScriptingHost: 7.24432 ms
TIMER| shutdown ConfigDB: 2.08 us
TIMER| shutdown CSocketBase: 229.68 us
TIMER| shutdown CNetLogManager: 45.999 us
TIMER| shutdown I18N: 7.72 us
TIMER| resource modules: 38.0077 ms
TIMER TOTALS (25 clients)
-----------------------------------------------------
  js_timer 19: 0 c (0x)
  js_timer 18: 0 c (0x)
  js_timer 17: 0 c (0x)
  js_timer 16: 0 c (0x)
  js_timer 15: 0 c (0x)
  js_timer 14: 0 c (0x)
  js_timer 13: 0 c (0x)
  js_timer 12: 0 c (0x)
  js_timer 11: 0 c (0x)
  js_timer 10: 0 c (0x)
  js_timer 9: 0 c (0x)
  js_timer 8: 0 c (0x)
  js_timer 7: 99.6559 Mc (598x)
  js_timer 6: 226.475 Mc (598x)
  js_timer 5: 190.2 Mc (106x)
  js_timer 4: 54.9052 Mc (106x)
  js_timer 3: 74.5003 Mc (106x)
  js_timer 2: 128.114 Mc (106x)
  js_timer 1: 1.84467e+10 Gc (106x)
  js_timer 0: 0 c (2x)
  tc_2: 0 c (0x)
  tc_1: 0 c (0x)
  tc_transform: 2108.03 kc (14x)
  tc_plain_transform: 3394.96 kc (14x)
  tc_png_decode: 0 c (0x)
-----------------------------------------------------
TIMER| shutdown misc: 638.841 us

I am building 0ad on Slackware Linux 13 x86_64 from subversion with Revision: 7232

[Philip Taylor]

That's quite peculiar, and I can't reproduce the problem... Could you try editing binaries/data/mods/public/gui/common/functions_page_session.js, and add the following just before line 174 (i.e. before the getGUIObjectByName line):

writeLog("Crd["+i+"].size["+GUIType+"]="+Crd[i].size[GUIType]+"="+uneval(Crd[i].size[GUIType]));

and then run the game then upload the file ~/.config/0ad/logs/mainlog.html ? Hopefully that should help identify the problem.

[Andrei]

These are the only Errors. I've attached also the mainlog.html file

WARNING: Cannot find config file "profiles/default/settings/user.cfg" - ignoring

ERROR: GUI page 'page_session.xml': Failed to call init() function

ERROR: JavaScript Error (gui/common/functions_page_session.js, line 175): Error: Size only accepts strings or GUISize objects

Engine exited successfully on 11 30 2009 at 20:22:57 with 528 message(s), 2 error(s) and 1 warning(s).

[Philip Taylor]

Hmm, still seems inexplicable (and I've not seen anyone else with the same problem) :-(

Could you try editing source/gui/scripting/JSInterface_IGUIObject.cpp line 428 so it says

	case GUIST_CClientArea:
		{
printf("# vp=%p *vp=%p IS_STRING=%d IS_OBJECT=%d Type=%d\n", vp, *vp, JSVAL_IS_STRING(*vp), JSVAL_IS_OBJECT(*vp), JS_TypeOfValue(cx, *vp));
printf("# Class=%p GUISize=%p\n", JS_GetClass(cx, JSVAL_TO_OBJECT(*vp)), &JSI_GUISize::JSI_class);
			if (JSVAL_IS_STRING(*vp))

and compile and run and upload the terminal output (hopefully it'll have some lines like "# vp=0x7ffff221f558 *vp=0x8114de0 ...")?

[Andrei]

Here's the output: ​http://trac.wildfiregames.com/attachment/ticket/442/pyrogenesis_dbg

[Philip Taylor]

# vp=0x7fff424fcb00 *vp=0x3f70b80 IS_STRING=0 IS_OBJECT=1 Type=1
# Class=(nil) GUISize=0xd6a520

Aha, that might actually make sense. JS_GetClass(cx, JSVAL_TO_OBJECT(*vp)) is returning NULL for an object that really does have a class, and that could be caused by a mixup of threadsafe and non-threadsafe versions of SpiderMonkey. When it's compiled without JS_THREADSAFE the function is JS_GetClass(obj) instead of JS_GetClass(cx, obj), but the game expects JS_THREADSAFE, and so it will be misinterpreting cx as obj and will give the wrong result.

But if that's the problem, it ought to give linker errors about JS_BeginRequest before getting this far. Did you get any problems like that? If not, I suppose it's doing something a bit weirder, but this seems the most likely cause.

In any case, the game's current linking of SpiderMonkey is a bit broken. You might get better results with the (very recent and experimental) new version, by doing

cd .../libraries/spidermonkey-tip/
./build.sh
cd .../build/workspaces/
./update-workspaces.sh --with-spidermonkey-tip

and then make clean and make as normal, which should hopefully avoid the linking bugs and give more consistent behaviour.

[Andrei]

I recompiled it again and I found a problem with the linker:

 -lplds4 -lplc4 -lnspr4 -lpthread -ldl -Lfdlibm/Linux_All_DBG.OBJ -lfdm -L../../dist/Linux_All_DBG.OBJ/lib -lnspr4 -Lfdlibm/Linux_All_DBG.OBJ -lfdm -L../../dist/Linux_All_DBG.OBJ/lib -lnspr4                                                        
ld: skipping incompatible /usr/lib64/libplds4.so when searching for -lplds4       
ld: skipping incompatible /usr/lib64/libplds4.a when searching for -lplds4        
ld: skipping incompatible /usr/lib64/libplds4.so when searching for -lplds4       
ld: skipping incompatible /usr/lib64/libplds4.a when searching for -lplds4        
ld: skipping incompatible /usr/lib64/libplds4.so when searching for -lplds4       
ld: skipping incompatible /usr/lib64/libplds4.a when searching for -lplds4        
ld: cannot find -lplds4                                                           
make[1]: *** [Linux_All_DBG.OBJ/libjs.so] Error 1                                 
make[1]: Leaving directory `/home/oz/svn/0ad/libraries/spidermonkey/src/js/src'   
make: *** [all] Error 2      

and also I have this package on my system ​js-1.8.0-rc1.tar.gz which is Spider Monkey.

I cannont find any package named lplds4. What is that?

[Andrei]

sorry I have those 2 libraries.

/usr/lib64/libplds4.a
/usr/lib64/seamonkey-2.0.1/libplds4.so

but why are they incompatible?

[Andrei]

/usr/lib64/libplds4.so /usr/lib64/libplds4.a

[Philip Taylor]

Ah, okay, if the local SpiderMonkey build fails then I guess it'll fall back on the system library (which in your case doesn't seem to have JS_THREADSAFE set). Hopefully the newer spidermonkey-tip build process will avoid that danger, but it's nice if the current version could work now.

libplds4 is from NSPR. The "skipping incompatible" messages are usually caused by mixing 32-bit and 64-bit files. The game's build process just uses the default, so on x86_64 it should be doing 64-bit compilation. If you do "file -L /usr/lib64/libplds4.so", does that say whether the library is 32 or 64?

[Andrei]

it's 32bit

/usr/lib64/libplds4.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, stripped

I guess that I need to recompile for 64bit?

BTW: I made my Slackware distribution multilib, because I needed wine for 32bit windows programs. This could be the problem? I need some flags to set on compiling?

[Philip Taylor]

Yeah, you'll need a 64-bit version of it. Putting 32-bit libraries in /usr/lib64 seems like a possibly bad idea ;-). It looks like the SpiderMonkey build ought to work normally once a 64-bit version of NSPR is there. But I have no idea how package installation and multilib etc work on Slackware, so I'm afraid I can't suggest anything about how to do that.

[Andrei]

this is the flag for CXXFLAGS= and CFLAGS= \-O2 -fPIC and for configure this are the flags that the builder uses ./configure \

--prefix=/usr \ --libdir=/usr/lib64 \ --localstatedir=/var \ --sysconfdir=/etc \ --mandir=/usr/man \

# --docdir=/usr/doc/$PRGNAM-$VERSION \

--enable-shared \ --disable-static \ --program-prefix= \ --program-suffix= \ --build=64-slackware-linux \

I'll find a way to deal with this ;)

[Andrei]

Yuppy. Finally it works :) I've build 0ad with spidermonkey-tip and also configured nspr with

./configure --enable-64bit

[(none)]

Milestone ASAP deleted