Assertions in dbuffer.c

[dodon]

In the recent trunk versions I encountered several assertions in dbuffer.c while in battlescape. Most of the time in my second turn.

The location of the assertions change but the circumstances are similat to this code (I changed the code to highlight the problem):

Code: [Select]

static struct dbuffer_element * allocate_element (void)
{
struct dbuffer_element *e;

if (free_elements == 0) {
struct dbuffer_element *newBuf = Mem_PoolAlloc(sizeof(struct dbuffer_element), com_genericPool, 0);
newBuf->next = free_element_list;
free_element_list = newBuf;
free_elements++;
allocated_elements++;
} else {
assert(free_element_list);
}

...
}


The important detail is: when the assertions happens, the value of free_elements is 0 although it should not be 0.


The only way i came up to get such a result is a second thread which accesses an other function in dbuffer.c and channges free_elements. I did some other tests that confirm my assumption.


What's the general strategy to handle multiple thread access of resources in Ufo AI ?
What's the best way to secure the global data in dbuffer.c ?

[Mattn]

have a look at mem.c - we are using mutexes to protect access like this. nice finding btw.

[Mattn]

i hope to have that fixed in http://sourceforge.net/apps/trac/ufoai/changeset/30938

feedback is welcome than welcome

[Mattn]

next none-thread-safe portion is the cmodel.c code - some minor changes were already made, some some stuff is still left.

and last but not least, the round end bug must be thread related, too (rounds get ended without user hitting e)

[Mattn]

another update- the cmodel.c threading issue should be fixed, too - only the other one about the round ending is left now (and maybe others i haven't seen/found yet)

[dodon]

the round end bug must be thread related, too (rounds get ended without user hitting e)

Weren't the buffers unsed to transmit data between client and server?
I compiled the the debug version with free buffer treshold = 0 and got the poblem, that one thread grabed a buffer that an other thread released.
With a higher threshold value it is more likely, that two threads grabed the same buffer and corrupted their message.

feedback is welcome than welcome

I'll test it on monday, no time till then.

[dodon]

I played 14 maps wit r31015 (with smal modifications of the GUI).
Here is what happened:

6x I reached the end of the mission (once a soldier refused to move during the mission til the end)
2x switch to geoscape during the mission (forgot to look at ufoconsole.log so no further information)
1x bufferunderflow in "dbuffer.c line 166" (ufoconsole.log was incomplete so no further information)
1x SIGSEGV in "dbuffer.c line 370" and "program closed it self" - no ufoconsole.log
1x SIGSEGV in "dbuffer.c line 279" and "program closed it self" - no ufoconsole.log
1x  switch to geoscape
        Looks like the "end of roundbug" while one of my soldiers was moving
        ufoconsole.log:

Code: [Select]

...
2010/07/13 10:42:29 Team 7 ended round
2010/07/13 10:42:29 Team 0's round started!
2010/07/13 10:42:29 Team 0 ended round
2010/07/13 10:42:29 Team 1's round started!
2010/07/13 10:44:07 Team 1 ended round
2010/07/13 10:44:07 Team 0's round started!
2010/07/13 10:44:10 ********************
2010/07/13 10:44:10 ERROR: LE_DoEndPathMove: Actor movement is out of sync: 129:119:0 should be 130:119:0 (step 7 of 7) (team 1)
2010/07/13 10:44:10 ********************
2010/07/13 10:44:10 Shutdown server: Server crashed.

1x "end of roundbug" and enemy round did not end:
        high processorusage 90% on one core, 20 % on the other (endles loop?)
1x "end of roundbug" and game froze:
     GUI was not redrawn
     0% processorusage

[shaunc311]

I haven't seen any errors in this since the fix (in trunk).  I do get a lot of other errors though so maybe they just happen first.  It's very rare that a skirmish finishes.