Help please, the game is crashing down on me

[Thralni]

I do hope this is not the formal end of HIM3, but here goes:

 

After taking a long break of HIM3, I decided to start looking at it again. I entered the scenario to test a creatrue script I'd written some time ago. I remember everythign workign all right previously, but now weird things happen in the second town: there is this passage where the party hits a special node, then a quick anination plays, and the party is transferred to a new town. Here, it all continues in the start state, where a dialog box is shown, and another animation is played. Previously, this worked fine. Now, BoA crashes on me right after I click the "OK" of the text box. I have the entire error report, but since it's very long, here's a small piece:

 

Code:

Process:         Blades of Avernum Release [978]Path:            /Applications/Avernum series/Blades of Avernum/Blades of Avernum v1.2.1.app/Contents/MacOS/Blades of Avernum ReleaseIdentifier:      com.SpiderwebSoftware.Blades of Avernum (Univ)Version:         Blades of Avernum v1.1 (1.2.1)Code Type:       X86 (Native)Parent Process:  launchd [102]Date/Time:       2009-04-07 23:19:24.884 +0200OS Version:      Mac OS X 10.5.6 (9G55)Report Version:  6Exception Type:  EXC_BAD_ACCESS (SIGBUS)Exception Codes: KERN_PROTECTION_FAILURE at 0x0000000014f5d000Crashed Thread:  0

 

Oh yes, I'm a Mac, running 10.5.6. I really hope anybody can help. In the meantime, I'll see if I have an older version of HIM3, maybe there's a difference...

 

EDIT: older version/different party doesn't seem to help.

[Niemand]

I think that you've left out both the most important bits, namely the script which causes the crash and the stack trace from the crashed thread. If the problem is in the former, we can help, but if it's in the game itself, as exposed by the stack trace, only Jeff can do anything about it.

[Lazarus.]

You should probably upload a copy of the scenario (or at least that one town where the error occurs) and have another Mac user test it. It may be a problem with your copy of Blades. If this were an unhandled exception like Windows users get I'd say it's a script error, but as far as I know these random crashes don't happen on the Mac version.

[Thralni]

Thanks for the quick responses,

 

Niemand: What bit in particualr do you want? I really don't quite know what's in the report. May I send you the entire report, so you can see for yourself?

 

Laz: I can send it to you, or both of you if you wish, so you can see.

 

I tried reinstalling the program (not a clean one, I admit, but I copied in new BoA files, and the program itself, leaving the scenario folder intact)

 

EDIT: Well, after a short test of Nikki, it appears to be working okay on Windows. So either this is a Mac bug or just my copy.

[Lazarus.]

I'm also on Windows, so I can't help you any further. I was volunteering others for the job.

[Niemand]

@Thralni: I can test for you, if you want. The stack trace is the part of the crash report that begins with a line "Thread # Crashed:". There can be many traces, since there is one for each thread the program had when it crashed, but usually only the one labeled 'Crashed' is important. By all means, though, send me the entire report. Extra data is very rarely a bad thing.

[Ishad Nha]

As I recall, the Mac and Windows versions of a scenario differ mainly in their graphics. A Windows user could test it if he improvised graphics.

(There was a post about the differences between the Mac and Windows versions of the same scenario, I forget where it is.)

[nikki.]

Quote:

Ishad Nha said:

As I recall, the Mac and Windows versions of a scenario differ mainly in their graphics. A Windows user could test it if he improvised graphics.

Quote:

Thralni said:

EDIT: Well, after a short test of Nikki, it appears to be working okay on Windows.

[Ishad Nha]

Possibly we should make a note about that "sticky" so people know exactly what the differences between the two versions are?

[Kelandon]

Some of the error-handling code is different or at least behaves different (hence Unhandled Exceptions on Windows, not on Mac). I've seen the equivalent of UEs on Mac, though, sometimes in really, really bizarre situations.

 

Heck, I could take a look, too, if for some reason Niemand can't replicate the crash.

[Thralni]

So, niemand, I'll send you the scnerio + the error report. I do hope you don't get the error. If you don't, I'll send it to you, kelandon.

 

Thanks in advance for the help!

[Niemand]

Thralni, I haven't gotten a chance yet to test play your scenario to see if it crashes, but I bet I know what's happening. As hoped, the stack trace tells us what to be on the look-out for:

Code:

Thread 0 Crashed:0   ...re.Blades of Avernum (Univ)	0x0002ad07 transbitblit(OpaqueGrafPtr*, Rect, OpaqueGrafPtr*, Rect, short, short) + 7771   ...re.Blades of Avernum (Univ)	0x0007f799 draw_one_pc_icon(short, short, short, short, Rect) + 8932   ...re.Blades of Avernum (Univ)	0x0004500a draw_chars(location, Rect) + 5403   ...re.Blades of Avernum (Univ)	0x0004c411 draw_terrain(short) + 55614   ...re.Blades of Avernum (Univ)	0x0004d3c1 do_full_terrain_redraw() + 575   ...re.Blades of Avernum (Univ)	0x000108de script_type::run_procedure(short, short) + 174226   ...re.Blades of Avernum (Univ)	0x00011a98 script_type::run_script(short) + 14907   ...re.Blades of Avernum (Univ)	0x0001347b script_type::run_town_script() + 2918   ...re.Blades of Avernum (Univ)	0x00013558 run_current_town_script() + 389   ...re.Blades of Avernum (Univ)	0x0003819f start_town_mode(short, short, short, location) + 355710  ...re.Blades of Avernum (Univ)	0x00071837 change_level(short, short, short) + 17111  ...re.Blades of Avernum (Univ)	0x00072c5e check_special_terrain(location, location, short, unsigned char, short*, unsigned char*) + 502212  ...re.Blades of Avernum (Univ)	0x00073365 char_try_move(short, location, short) + 178913  ...re.Blades of Avernum (Univ)	0x00018726 move_party(short) + 262214  ...re.Blades of Avernum (Univ)	0x00018fbb process_terrain_gworld_click(Point, unsigned char, unsigned char*, unsigned char) + 75515  ...re.Blades of Avernum (Univ)	0x0001aae9 handle_action(EventRecord, short, short) + 96316  ...re.Blades of Avernum (Univ)	0x0001c1e6 handle_keystroke(unsigned char, unsigned char, EventRecord) + 390617  ...re.Blades of Avernum (Univ)	0x0008614b Handle_One_Event() + 91318  ...re.Blades of Avernum (Univ)	0x000864a5 main + 70119  ...re.Blades of Avernum (Univ)	0x00002832 _start + 21620  ...re.Blades of Avernum (Univ)	0x00002759 start + 41

 

The stack trace records what the progrma was doing from bottom to top. Scanning up it, we see that the program started up (start, _start, main), and then began dealing with user input (Handle_One_Event, handle_keystroke, handle_action, process_terrain_gworld_click). Apparently, your last action before the crash was to move the party into a town (move_party, char_try_move, check_special_terrain, change_level, start_town_mode) at which point the game began to run the town's script (run_current_town_script, script_type::run_town_script, script_type::run_script, script_type::run_procedure). The script must have contained a force_instant_terrain_redraw(), becuase the game sets about redrawing the screen (do_full_terrain_redraw, draw_terrain, draw_chars) until it comes to drawing a PC (draw_one_pc_icon). To do this it calls a system drawing call (transbitblit), in which the crash happens. So, we learn that the crash happens when your town script requests a full redraw and the game tries to draw a player character, for which the graphic is somehow bad.

 

Jump over to your town script:

Code:

	//some relocate_character calls	force_instant_terrain_redraw();	pause(10);	message_dialog("[Text redacted]","");	z = 0;	while(z<5) {		da = 15;		if (char_ok(z) == 1) {			//some conditional calls to run_animation_sound			while(da>11) {				set_character_pose(z,da);				force_instant_terrain_redraw();				pause(2);				da = da - 1;			}			set_character_pose(z,0);		}		z = z + 1;	}

 

The first force_instant_terrain_redraw() looks harmless; all you did was move the PCs around well within the bounds of the town. So far so good. The next one comes after you set a PC's pose. This is the key: Setting a pose messes with which part of the PC's graphic is being displayed. Indeed, according to the editor appendicies, the highest valid pose number is 14, but you are starting at 15 then counting down. I bet what's happening is that Jeff forgot to put in any bounds checking (does this sound familiar?) and so given a pose number, he blindly computes a rectangle to cut the right graphic out of the sheet accrding to a formula. When given an out or range pose number, the computation can yield a rectangle that is off the edge of the sheet, which means it may involve memory addresses the program doesn't own. Jeff's code hands the rectangle off to the system function with orders to copy that data to the screen, but when it tries it tries to access memeory it doesn't have rights to, and the kernel stops it. (That would be your KERN_PROTECTION_FAILURE.) So, I'm betting changing 'da= 15;' to 'da = 14;' will make a big difference.

 

One other point: You use run_animation_sound() when you haven't actually set up any animations to play. Are you sure that you don't mean play_sound()?

[Kelandon]

Originally Posted By: Niemand

I bet what's happening is that Jeff forgot to put in any bounds checking (does this sound familiar?)

Ach, any time you get a crash like this (game fully quits), an out-of-bounds parameter is responsible 99% of the time.

[Lazarus.]

I'm amazed Windows BoA didn't keel over from this one. If there's anything it hates more than out of bounds parameters it's nonexistant images, and this one has both.

[Niemand]

I suspect that whether an out of bounds pose actually causes a crash may depend on whther the character is an NPC or a PC, and if the latter, what equipment the PC is using. Depending on exactly how Jeff's code computes the rectangle on the sheet for the out of bounds pose number, setting an unarmored PC to pose 15-18 might be gauranteed not to crash anyway, since it might just pick out the death poses for the PC with armor. In addition a crash is never certain, since you might also just end up refering to some other random chunk of memeory that the program does own, and drawing that to the screen, likely producing gibberish, but not upsetting the kernel.

 

Generally speaking, I think we can agree that the best solution is just to only use valid pose numbers.

[Thralni]

Oh god, I feel so embarrased now. Niemand, thanks very much! I changed 15 to 14, and it works now. It's not as fluid as I had hoped (the animation), so I'll be tweaking that, but anyway, it all works now.

 

What's puzzlign me, is that a while back BoA didn't crash because of this. I'm wondering of OS 10.5.6 might have something to do with it. I don't really remember, but it might well be that I had 10.5.5 last time I tested HIM3.

 

Anyway, thanks again, you saved me.

[Ephesos]

Out of bounds values are strange on Macs... I remember having a similar problem with DoK back when I first released it. Something to do with group numbers and a mistake between 0 and 1000. Weird thing was that the Macs could take it and it made Windows cry.