Spring is running in SMP

[andre]

Here is the replay. The game freezes in the exact same spot every time, Just watch player [PYB]Awesome. the game will freeze just before this guy fishes building an advance fusion reactor.

BTW the replay was made with the non SMP build.

I guess it was a core one? If yes it is a the LUPS widget that causes the error


Concerning Linux: just download the sources and build (and make sure you enable "USE_GML" with ccmake)

[zerver]

That means that this branch will nerve get adopted as the default one, as i seriously doubt that all the mod coders will rewrite all they widget to make them compatible with it?

It's not intended to be "default", it's an option.
Whether the incompatibility shall be fixed in the engine or the widgets is still open to discussion.

[zerver]

Concerning Linux: just download the sources and build (and make sure you enable "USE_GML" with ccmake)

... and USE_GML_SIM if u want the separate Sim thread. Recommended.

[[oxnull]Lupus]

Concerning Linux: just download the sources and build (and make sure you enable "USE_GML" with ccmake)

... and USE_GML_SIM if u want the separate Sim thread. Recommended.

Thanks, andre. But ccmake reports only USE_GML. There's no USE_GML_SIM in 0.79.0.2 sources.
Compiled with USE_GML. Spring starts using over 100% cpu, which means it uses second core :) Playing on speedmetal with bot i got up to 160% cpu usage.
Does USE_GML includes separate SIM thread?
EDIT: just noticed label 0.79.0.2 MT (2 threads). I guess SIM is not threaded.
How to turn GML_SIM on then? :)

[zerver]

Use the "079" branch, or insert this in rts/CMakeLists.txt, after the USE_GML stuff.

Code: Select all

SET(USE_GML_SIM FALSE CACHE BOOL "Use independent Simulation thread?")
if (USE_GML_SIM)
	ADD_DEFINITIONS(-DUSE_GML_SIM)
endif (USE_GML_SIM)

Edit: never mind, I have now updated the 0.79-branch also, you can use either one.

[[oxnull]Lupus]

Use the "079" branch, or insert this in rts/CMakeLists.txt, after the USE_GML stuff.

Code: Select all

SET(USE_GML_SIM FALSE CACHE BOOL "Use independent Simulation thread?")
if (USE_GML_SIM)
	ADD_DEFINITIONS(-DUSE_GML_SIM)
endif (USE_GML_SIM)

Edit: never mind, I have now updated the 0.79-branch also, you can use either one.

Thx. I'll try this.
btw, i found strange bug: spring hangs on "Finalizing..." and crashes with "std::bad_alloc" when i start it for the second time. Restarting lobby fixes issue.

[zerver]

Thanks for testing. Linux has not been tested much so bugs are expected...

Edit: I have no idea what caused your crash, but I remember now that you also have to specify this compile flag to make sure it works:

Code: Select all

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mno-tls-direct-seg-refs")

[[oxnull]Lupus]

Thanks for testing. Linux has not been tested much so bugs are expected...

No problems :)

Edit: I have no idea what caused your crash, but I remember now that you also have to specify this compile flag to make sure it works:

Code: Select all

SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mno-tls-direct-seg-refs")

I compiled gml sim btw. That strage bug vanished(try to reproduce?), but i got some random crush just now on DSD. Nothing interesting in infolog and no messages... Maybe it's because of this flag? Where to put this line? in main CMakeList or in one under rts folder?
By the way, label still claims i have 2 threaded MT spring build. May be number must be incremented? :)
I guess you need backtraces for testing to be efficient. Maybe i should compile debug version and make a wrapper script to get backtraces with gdb?

[imbaczek]

you could enable coredumps in ulimit (they'll probably be huge tho).

also when getting backtraces remember to post backtraces of all threads and/or with more info (source):

Advanced gdb commands

If the program youÔÇÖre backtracing is multi-threaded, you might want to get a backtrace for all threads:

(gdb) thread apply all bt

Another thing which is quite helpful to report is what parameters came on the stack of function calls:

(gdb) bt full

You might want to report the output of the combination of the preceding options:

(gdb) thread apply all bt full

And if this is too much irrelevant output, you might want to keep only a few calls, such as the top 10:

(gdb) thread apply all bt full 10

[[oxnull]Lupus]

Compiled back to
USE_GML 1
USE_GML_SIM 0
Bug is reproducable. Caught it with simple script(moved spring binary to spring.bin and used this script instead):

Code: Select all

#!/bin/bash
echo run $@ > spring.gdb
screen -A -m -d -S spring_gdb gdb -x spring.gdb /usr/local/bin/spring.bin

infolog and backtrace are attached, although i could not find something meaningful in it... Debug build btw.

[zerver]

OK, it was some time since I tried without the USE_GML_SIM. May very well be a bug, will look into it!

By the way, label still claims i have 2 threaded MT spring build.

If you have 2 cores, it will be 2 threads. Before you had 1 extra rendering helper thread, and now you have the separate Sim thread instead.

You can try ingame:
/multithreadsim - disable/enable the sim thread
if everything is right, it should respond when you enter this command, and you should also see that the CPU usage is changes.

[[oxnull]Lupus]

Played on speed metal with GML_SIM. Compiled with flag you told. Seems stable. I'll post report if i get that crash.

[[oxnull]Lupus]

Got it! Everything attached.
Don't know a way to reproduce it. Some random crash.

[zerver]

You are using incompatible widgets too.

If you see "GML error" in the infolog or the console, it means some widget is trying to do run OpenGL from inside Sim. This is currently not permitted. You could start by disabling LUPS manager.

Also, did you try my suggestion of compiling with the -mno-tls-direct-seg-refs flag?

[[oxnull]Lupus]

You are using incompatible widgets too.

If you see "GML error" in the infolog or the console, it means some widget is trying to do run OpenGL from inside Sim. This is currently not permitted. You could start by disabling LUPS manager.

Also, did you try my suggestion of compiling with the -mno-tls-direct-seg-refs flag?

Well, LUPS manager and LUPS itself are turned off. I don't have any graphics widgets i guess. There were some GML errors in chat, but they don't cause a crash. I played twice with one configuration. First time it was okay. Second time it was a crash.
I compiled with this flag.
Btw, i got major performance boost with this stuff. Good job :)

[zerver]

Remove widgets until you no longer have GML errors. Then we can begin debugging.

[zerver]

I did some thinking and the bad_alloc crash could possibly be caused by some widget creating projectiles or special effects in a rendering thread.

Therefore, please disable ALL widgets and see if the problem still remains.

[[oxnull]Lupus]

Now i'm trying to get rid of GML errors. Turned off practically every widget, that has "gl" in it :)
SpeedMetal ran smoothly, but when i blowed AI's comm, it hanged in the middle of explosion. GML errors in infolog just at that point. Backtrace seems to be like last posted. Segmentation fault in CMemPool::Alloc().
Is there a way to get widget's name, that caused improper call?
And btw, can't you just ignore wrong calls and avoid them crushing?

[zerver]

And btw, can't you just ignore wrong calls and avoid them crushing?

Yes I possibly could, but I think this crash is related to unsynced special effects or projectiles, and that is much harder to ignore.

If you disable all widgets, there should be no errors (BA 6.92). Make sure you scroll the list with the mouse wheel and disable them all...

Regarding printing the widget name in console, I will see what I can do. I may even be able to automatically disable the widget :)

[[oxnull]Lupus]

Regarding printing the widget name in console, I will see what I can do. I may even be able to automatically disable the widget :)

That would be perfect, cause it's rather tricky to turn them off one by one guessing "is it that one broken?" :)

Yes I possibly could, but I think this crash is related to unsynced special effects or projectiles, and that is much harder to ignore.
If you disable all widgets, there should be no errors (BA 6.92). Make sure you scroll the list with the mouse wheel and disable them all...

I'll try it a bit later.
Shokwing started a very interesting experiment couple of minutes ago :) He hosted a game called "50 PLAYERS TEST"(or something similar, i dont remember exactly:). Well, we got 32 players on DSD Rev X3. Clobber's com died in FPS mode. The game crashed.
The second time we were playing 4 teams 6 players each on Nation v1. Clobber died again in FPS - again a crash. I'm not sure it's right topic for this reports, but as far as i was the only one playing it with MT spring, i decided to post it here :)