View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002114 | FSSCP | graphics | public | 2010-02-05 23:12 | 2010-08-27 03:44 |
| Reporter | The_E | Assigned To | Zacam | ||
| Priority | normal | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 3.6.11 | ||||
| Fixed in Version | 3.6.12 | ||||
| Summary | 0002114: 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. | ||||
| Tags | No tags attached. | ||||
|
|
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. |
|
|
Committed potential fix in 5899. RC's should let us know if it holds up or not. |
|
|
Marking as Resolved now that Final is out. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2010-02-05 23:12 | The_E | New Issue | |
| 2010-02-05 23:18 | The_E | Note Added: 0011617 | |
| 2010-02-11 02:18 | Zacam | Status | new => assigned |
| 2010-02-11 02:18 | Zacam | Assigned To | => Zacam |
| 2010-02-11 02:19 | Zacam | Note Added: 0011627 | |
| 2010-02-11 02:19 | Zacam | Status | assigned => feedback |
| 2010-08-27 03:44 | Zacam | Note Added: 0012334 | |
| 2010-08-27 03:44 | Zacam | Status | feedback => resolved |
| 2010-08-27 03:44 | Zacam | Fixed in Version | => 3.6.12 |
| 2010-08-27 03:44 | Zacam | Resolution | open => fixed |
