2019-12-10 03:14 EST


View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0002114FSSCPgraphicspublic2010-08-26 23:44
ReporterThe_E 
Assigned ToZacam 
PrioritynormalSeveritycrashReproducibilityalways
StatusresolvedResolutionfixed 
Product Version3.6.11 
Target VersionFixed in Version3.6.12 
Summary0002114: Assert(num == bm_bitmaps[n].handle) in bmpman.cpp line 2459
Description(This is The E)

While betatesting the BLuie Planet re-release, we've run into this assertion when testing the mission "Sacrifices". The assertion was hit when going from command briefing to gameplay (no regular briefing in this mission).

Tracing through the crash using Visual Studio, the cause was that bm_bitmaps[0].handle was set to 4750 ( == MAX_BITMAPS) for some reason. The function calling the Assertion (int bm_is_compressed(int num)) expects the handle of the bitmap to be checked as a parameter.

My understanding of the code is that usually, the handle is equal to the position of the bitmap in bm_bitmaps[]. However, in the case of bm_bitmap[0], that is, the very first thing bmpman loads, the handle will be set to 4750. When bm_is_compressed() is called with the parameter 0, the assertion will be triggered, since 0 != 4750.

The reason for this behaviour is the assignment of the handle in bm_load(). Handles are generated using the following formula: bm_get_next_handle() * MAX_BITMAPS + free_slot, which for the very first bitmap evaluates to 1 * 4750 + 0. Changing the initial value of bm_next_handle from 1 to 0 seems to fix this, Yet it raises an interesting point:
Based on the observed behaviour, and the fact that the first texture loaded will always be cursorweb.ani, why isn't it crashing all the time? It _should_ crash every time bm_is_compressed() is called with a parameter of 0, yet these crashes are infrequent at best. I do not know what combination of factors came into play that caused this particular combination of assets to spawn the error, and so I fear that the proposed solution (initializing bm_next_handle to 0) will simply hide some underlying problem.
TagsNo tags attached.
Attached Files

-Relationships
+Relationships

-Notes

~0011617

The_E (administrator)

Actually, I just realized that I was a bit stupid in my understanding. The position of a bitmap in bm_bitmaps[] can always be derived from its handle by simply looking at the handle modulo 4750.

~0011627

Zacam (administrator)

Committed potential fix in 5899. RC's should let us know if it holds up or not.

~0012334

Zacam (administrator)

Marking as Resolved now that Final is out.
+Notes

-Issue History
Date Modified Username Field Change
2010-02-05 18:12 The_E New Issue
2010-02-05 18:18 The_E Note Added: 0011617
2010-02-10 21:18 Zacam Status new => assigned
2010-02-10 21:18 Zacam Assigned To => Zacam
2010-02-10 21:19 Zacam Note Added: 0011627
2010-02-10 21:19 Zacam Status assigned => feedback
2010-08-26 23:44 Zacam Note Added: 0012334
2010-08-26 23:44 Zacam Status feedback => resolved
2010-08-26 23:44 Zacam Fixed in Version => 3.6.12
2010-08-26 23:44 Zacam Resolution open => fixed
+Issue History