Mantis Bugtracker

Viewing Issue Simple Details Jump to Notes ] View Advanced ] Issue History ] Print ]
ID Category Severity Reproducibility Date Submitted Last Update
0000044 [Homeworld SDL] Gameplay major always 2007-04-29 05:33 2007-04-29 07:05
Reporter lmop View Status public  
Assigned To shevek
Priority immediate Resolution fixed  
Status resolved  
Summary 0000044: New Task manager changes crash multiplayer
Description If you choose the multiplayer option from Homeworld's main menu then the game crashes due an assertion failure:

Task.c: L409 - called from mgStartMultiPlayerGameScreens()

void taskResume(taskhandle handle)
{
    taskInitCheck();
    dbgAssertOrIgnore(handle >= 0);
    dbgAssertOrIgnore(handle < taskMaxTask);
    dbgAssertOrIgnore(taskData[handle] != NULL); // << fails assertion


Also:

handle = 9;
taskMaxTask = 12;
taskData[0 .. 11] are all non-NULL except for [9].
Additional Information
Tags No tags attached.
Affected: Linux No
Affected: Mac Yes
Affected: Windows Unknown
gcc version used n/a
In Original Game Unknown
revision or version first noticed 598
system type: 64 bit or 32 bit 32 bit
Attached Files

- Relationships

-  Notes
(0000066)
shevek (developer)
2007-04-29 06:16

Does not happen for me. I was able to get a vs. CPU skirmish started. All the network game options fail with an error dialog though (no crash).
(0000067)
lmop (developer)
2007-04-29 06:32

The resumed task was previously stopped due to it having a NULL context so shouldn't be being resumed. It's possible this is a Mac OS X specific issue related to the butchered Titan code... Out of curiousity, under Linux, when you reach the main menu, is this NULL?

    taskData[ handle index stored in ProccessCallback (MultiplayerGame.c L459) ]

Thanks.
(0000068)
shevek (developer)
2007-04-29 06:35

taskResume itself has not changed. This is probably an attempt to resume a task that has exited. In the current implementation, a task that calls taskExit or reaches the end of the function (the taskEnd macro) terminates itself.

The culprit would seem to be mgProcessCallBacksTask. Was _MACOSX_FIX_ME enabled?
(0000069)
shevek (developer)
2007-04-29 06:48

Does r600 fix it?
(0000070)
lmop (developer)
2007-04-29 06:57

Yes, _MACOSX_FIX_ME is defined (it's equivalent to _MACOSX but indicates that the code is trying to get something (anything) working, as opposed to being inherently required by the platform). r600 would probably fix it but given your pointer to that bit of code I'd already elected to try removing the test completely and to my surprise it worked! Other parts of the code must be nobbled sufficiently to let it run as-is. :) Thanks for your assistance.

- Issue History
Date Modified Username Field Change
2007-04-29 05:33 lmop New Issue
2007-04-29 05:33 lmop Affected: Linux => Unknown
2007-04-29 05:33 lmop Affected: Mac => Yes
2007-04-29 05:33 lmop Affected: Windows => Unknown
2007-04-29 05:33 lmop gcc version used => n/a
2007-04-29 05:33 lmop In Original Game => Unknown
2007-04-29 05:33 lmop revision or version first notice => 598
2007-04-29 05:33 lmop system type: 64 bit or 32 bit => 32 bit
2007-04-29 05:55 shevek Issue Monitored: shevek
2007-04-29 06:16 shevek Note Added: 0000066
2007-04-29 06:17 shevek Affected: Linux Unknown => No
2007-04-29 06:17 shevek Status new => feedback
2007-04-29 06:32 lmop Note Added: 0000067
2007-04-29 06:35 shevek Note Added: 0000068
2007-04-29 06:48 shevek Note Added: 0000069
2007-04-29 06:57 lmop Note Added: 0000070
2007-04-29 07:00 shevek Status feedback => resolved
2007-04-29 07:00 shevek Resolution open => fixed
2007-04-29 07:00 shevek Assigned To => shevek


Mantis 1.1.8[^]
Copyright © 2000 - 2009 Mantis Group
Powered by Mantis Bugtracker