#261 Repeatable crash by running out of objIDs

[Malignant Manor]

Rafaelvetuff at the forums reports that he gets a consistent crash to desktop in Windows 7. His game version is 2.12 and mine is prepatched to 2.13 so I can't confirm this.

His steps to reproduce are, recall to central tenebrae and walk to east tenebrae.

[Malignant Manor]

2.12 save named Rafael

[Matthias Wilhelm]

I have the same problem, after playing successfully for a while (after meeting Lithos), the game segfaults when entering a new area. In the console appears lots of
Unable to allocate id (max = 32766),
so maybe there some objects piling up over time.

The game crashed on
0 net.sourceforge.pentagram 0x0000000100627cd6 std::vector<Map*, std::allocator<Map*> >::_M_fill_insert(__gnu_cxx::__normal_iterator<Map**, std::vector<Map*, std::allocator<Map*> > >, unsigned long, Map* const&) + 10038
1 net.sourceforge.pentagram 0x000000010062dd84 AvatarGravityProcess::~AvatarGravityProcess() + 1764
2 net.sourceforge.pentagram 0x000000010000d079 JoystickCursorProcess::GetClassType() + 905
3 net.sourceforge.pentagram 0x000000010065ff72 signed char* Timidity_Pentagram::safe_Malloc<signed char>(unsigned long) + 50178
4 net.sourceforge.pentagram 0x0000000100668d27 std::_Rb_tree<std::string, std::pair<std::string const, Process* (*)(IDataSource*, unsigned int)>, std::_Select1st<std::pair<std::string const, Process* (*)(IDataSource*, unsigned int)> >, std::less<std::string>, std::allocator<std::pair<std::string const, Process* (*)(IDataSource*, unsigned int)> > >::_M_insert_unique(std::_Rb_tree_iterator<std::pair<std::string const, Process* (*)(IDataSource*, unsigned int)> >, std::pair<std::string const, Process* (*)(IDataSource*, unsigned int)> const&) + 1303

I'm running svn-r2510 on OSX 10.5, I also have logs and a save, but I cant figure out how to use the attachments.

[Anonymous]

Having the same issue.

Began for me shortly after arriving at Argentrock Isle.

Symptom:
- Game will seemingly crash at random, generally when moving.

Info:
- When pulling up the ingame log (F5) you see the stream of "Unable to allocate id (max = 32766)"

Have reverted to an earlier save game but the same problem reoccured at Argentrock.

Generally the game only crashes at Argentrock, but after the condition starts game will also crash in previously explored areas.

Condition occurred on Mac 10.7 but the same savefile triggers crash on Windows XP.

Mac crash log

Crashed Thread: 0 Dispatch queue: com.apple.main-thread

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Application Specific Information:
objc[1453]: garbage collection is OFF
Assertion failed: (widget), function NextText, file gumps/BarkGump.cpp, line 121.

[Willem Jan Palenstijn]

I guess we may have to revert the 32k objID limit... (and fix bug #3116767 some other way)

[Willem Jan Palenstijn]

(and/or figure out why exactly we're allocating more objects than the original U8, of course)

[Anonymous]

In hopes that it's helpful, here's a screen capture of the bug (and map loading corruption that seems to accompany it)

http://youtu.be/0tYoKhryT38

Also, I'm using the U8 from the GOG.com release.

[Willem Jan Palenstijn]

Strangely the number of allocated objects according to the ObjectManager::objects is 5658, while according to ObjectManager::objIDs it's 32511.

[Willem Jan Palenstijn]

Found the cause: when gumps are labelled DONT_SAVE, they are not actually saved (unsurprisingly), but their objIDs are still in use according to the idMan.

[Shadowblade]

That's good. Can it be fixed?

@khawkins98 I get that screen corruption with some saves but I also cannot use the menu to load another save and if I press ESC several times the screen goes darker until it is black. I'm using the GOG version as well.

The saves I can load just crash, sometimes with an assertion failure of various different sorts.

~

[Willem Jan Palenstijn]

This should now be fixed. I'm keeping this bug report open since I also want to add sanity checks to prevent this from happening in the future.

The relevant comment in ObjectManager for completeness:

// ObjectManager::save() doesn't save Gumps with the DONT_SAVE flag, but
// their IDs are still marked in use in objIDs.
// As a workaround, we clear all IDs still in use without actual objects.
// We only do this with IDs >= 1024 because below there are truly reserved
// objIDs (up to 511 is reserved by U8Game, 666 is reserved for Guardian
// barks).
// FIXME: Properly fix this objID leak and increment the savegame number.
// This check can then be turned into an savegame corruption check
// for saves with the new savegame version.
// We also fail loading when we're out of objIDs since this could
// have caused serious issues when critical objects haven't been created.