Game does not exit properly after a game

[fabio]

Start 0 A.D. from a shell, start a game and then try to exit. The window close but it doesn't completely exit to the shell, you must press CTRL-C. Works OK on alpha 9.

Tested on current SVN on Ubuntu 12.04.

[historic_bruno]

Can you run it in gdb and break at the point it locks up, seeing what the call stack of all threads is?

I can't reproduce on Ubuntu 11.10

[fabio]

$ gdb ./pyrogenesis
... start a game, press ALT + F4 ...
... window close, but program doesn't exit ...
... CTRL+C ...
(gdb) thread apply all bt

bt attached.

[historic_bruno]

Is that the full output of bt? Can you also paste the console debug output? That should tell us which phases of the engine shut down have finished, if any.

[fabio]

full game + gdb output

[fabio]

Replying to historic_bruno:

Is that the full output of bt?

Yes.

Can you also paste the console debug output? That should tell us which phases of the engine shut down have finished, if any.

Attached.

[Philip]

Do you have the gamin package installed, or the older fam?

[fabio]

Replying to Philip:

Do you have the gamin package installed, or the older fam?

Gamin 0.1.10-4 (from Ubuntu 12.04). Also note that I am building with:

--with-system-enet --with-system-mozjs185 --with-system-nvtt

using the Ubuntu provided libs.

[historic_bruno]

Can you try building with the --without-fam flag, too?

[fabio]

Replying to historic_bruno:

Can you try building with the --without-fam flag, too?

It works fine with it.

Also note that without it the problem is reproducible only when quitting after a short time of game start. When quitting after a longer time the problem doesn't happen.

[historic_bruno]

Is feedback enabled? The user report system is triggered almost immediately after the game starts, so it may be causing a problem. There's a delay on any OS because of that but it should only be 10-15 seconds at most.

If FAM is to blame, perhaps #1316 will resolve this.

[historic_bruno]

Any chance some other threading issue may be at fault? Maybe FAM is not the problem but the symptom (if I'm not mistaken --without-fam will both disable the hotloading mechanism on Linux and remove the processing thread, thus one less chance for deadlock).

[historic_bruno]

This shouldn't be closed yet, it's still an active problem (in fact I encountered it a few days ago on an Ubuntu VM).

[k776]

I marked it as "needsinfo" because the reporter of the issue hasn't replied to you in 2 months. But I can leave it open for now.

[fabio]

Still reproducible after the FAM disabling of some days ago. Strangely I was saying I cannot longer reproduce this but after many attempts it reappeared.

[historic_bruno]

Replying to fabio:

Still reproducible after the FAM disabling of some days ago. Strangely I was saying I cannot longer reproduce this but after many attempts it reappeared.

Hmm, in that case I'd say a gdb backtrace is very important so we can see what if not FAM is responsible.

[fabio]

Replying to historic_bruno:

Replying to fabio:

Still reproducible after the FAM disabling of some days ago. Strangely I was saying I cannot longer reproduce this but after many attempts it reappeared.

Hmm, in that case I'd say a gdb backtrace is very important so we can see what if not FAM is responsible.

I still wasn't able to get a backtrace since it's very difficult to reproduce this bug.

Also, I have both alpha 10 (deb package) + build from svn tree. Strangerly I noticed that when I am able to trigger the bug in the svn I am later also able to trigger it in alpha 10. After a while it disappear on both... maybe it depends on some condition not strictly related to 0 A.D.?

[fabio]

I am no longer able to reproduce it, supposing fixed. I'll reopen if needed.