GRRLIB Crash On Exit *SOLVED*

I have a small test program based on GRRLIB template with a lot of generic functions for future easy programming.

My code works like a charm but when I added support for up to 4 controllers my game started to cause a crash (STACK DUMP) on exit.

I am not sure if it actually is related to the controller code or not...it might have been something else that I changed at the time.

I tried, one by one, commenting out each of the commands after the loop but the STACK DUMP occured in each case.

Like I said, the program runs fine except for the exit...

The source code can be found at:

[www.filefactory.com]

Anyone has any ideas why this is happening? I added the Wiimote disconnects just in case but they had no effect on the STACK DUMP.



Edited 1 time(s). Last edit at 03/15/2010 01:37PM by LordAshes.

1)Please upload to a different site in the future so I dont have to spend 20+ minutes closing ads and trying to find the downloaded button obfuscated in even more ads. I recommend mediafire.

2)If I had to guess I would say that your program is crashing because you are still calling GRRLIB functions after you call GRRLIB_Exit(). AFAIK GRRLIB_Exit() needs to be the last GRRLIB function you call.

3)I recommend using exit(0) to exit instead of relying on return 0 to escape your program and return to your loader. Just make exit(0) the line before return 0.

4)I highly recommend using bin2o instead of raw2c

Hope this helps!



Edited 1 time(s). Last edit at 02/14/2010 02:32PM by Arikado.

Yeah I would have taken a look but honestly after clicking on what I thought was the download for a few minutes I gave up.

Sorry about the site...I had no idea that it was doing that...I visited the site many times both logged in and not and I did not get all the ads that you indicate. Maybe my anti-popup software is doing a better job than I thought...I will try mediafire in the future.

I can try moving the GRRLIB_exit further down (as the last entry) but in the GRRLIB example "basic_drawing", which I used as a "template" for my own code, all the GRRLIB_FreeTextures calls are made after the GRRLIB_exit call and it also uses return 0 instead of exit 0.

I have a feeling it has something to do with the IR, Accel and Gforce readings. It seems that when I added that code it started to do the STACK DUMP on exit. I will try commenting those out and seeing if it still happens. I was thinking maybe it has something to do with reading these values for Wiimotes that are not connected but in that case, I would expect it to crash during the program and not at the end. So I am wondering if it does not have something to do with some automatic freeing code that is run at the end of a program related to Wiimotes that are not connected.

I could never get the download from that site, could you pastebin the code so I can take a look?

*UPDATE*

I have narrowed it down to the Wiimote IR read functions. When I comment those out (but keep all the other Wiimote data reads) then the program returns to the loader as expected. When the IR read functions are included I get the STACK DUMP on exit.

Any ideas?


Original Post:

The code is real long but when I commented out the Wiimote IR, Orientation, Accel and GForce calls then the program returns back to the loader without any problems. So it has something to do with reading the Wiimote data but not while reading them but when exiting the program. There code pertaining to this is as follows:

int main()
{

// Some code for defining some functions removed to save space

GRRLIB_Init(); // Initializes graphics
WPAD_Init(); // Initializes WPAD
WPAD_SetDataFormat(WPAD_CHAN_0, WPAD_FMT_BTNS_ACC_IR); // Sets desired WPAD data
WPAD_SetDataFormat(WPAD_CHAN_1, WPAD_FMT_BTNS_ACC_IR); // Sets desired WPAD data
WPAD_SetDataFormat(WPAD_CHAN_2, WPAD_FMT_BTNS_ACC_IR); // Sets desired WPAD data
WPAD_SetDataFormat(WPAD_CHAN_3, WPAD_FMT_BTNS_ACC_IR); // Sets desired WPAD data
WPAD_Rumble(WPAD_CHAN_0, 0); // Turns WPAD rumble off
WPAD_Rumble(WPAD_CHAN_1, 0); // Turns WPAD rumble off
WPAD_Rumble(WPAD_CHAN_2, 0); // Turns WPAD rumble off
WPAD_Rumble(WPAD_CHAN_3, 0); // Turns WPAD rumble off

GRRLIB_texImg *tex_BMfont1 = GRRLIB_LoadTexture(font);
GRRLIB_InitTileSet(tex_BMfont1, 16, 16, 32);

WPAD_SetVRes(0, 640, 480);

room_setup(INITIAL_ROOM);

while(1)
{
WPAD_ScanPads(); // Check for exit request

if(WPAD_ButtonsDown(0) & WPAD_BUTTON_HOME) {break;} // On Exit Request Break Loop

GRRLIB_FillScreen(GRRLIB_BLACK); // Clear the screen

//WPAD_IR(WPAD_CHAN_0,&ir[0]); // Read IR Data for all Controllers
//WPAD_IR(WPAD_CHAN_1,&ir[1]);
//WPAD_IR(WPAD_CHAN_2,&ir[2]);
//WPAD_IR(WPAD_CHAN_3,&ir[3]);
//WPAD_Orientation(WPAD_CHAN_0,&orient[0]); // Read Orientation Data for all Controllers
//WPAD_Orientation(WPAD_CHAN_1,&orient[1]);
//WPAD_Orientation(WPAD_CHAN_2,&orient[2]);
//WPAD_Orientation(WPAD_CHAN_3,&orient[3]);
//WPAD_Accel(WPAD_CHAN_0,&accel[0]); // Read Acceleration Data for all Controllers
//WPAD_Accel(WPAD_CHAN_1,&accel[1]);
//WPAD_Accel(WPAD_CHAN_2,&accel[2]);
//WPAD_Accel(WPAD_CHAN_3,&accel[3]);
//WPAD_GForce(WPAD_CHAN_0,&gforce[0]); // Read GForce Data for all Controllers
//WPAD_GForce(WPAD_CHAN_1,&gforce[1]);
//WPAD_GForce(WPAD_CHAN_2,&gforce[2]);
//WPAD_GForce(WPAD_CHAN_3,&gforce[3]);

obj_frame_code(Obj); // Execute each object's Frame Event code and Wiimote Event code

obj_move(Obj); // Move all applicable objects

obj_draw(Obj); // Draw all applicable objects


GRRLIB_Render(); // Render the frame

FPS = CalculateFrameRate();

}

// Disconnect Wiimotes
WPAD_Disconnect(WPAD_CHAN_0);
WPAD_Disconnect(WPAD_CHAN_1);
WPAD_Disconnect(WPAD_CHAN_2);
WPAD_Disconnect(WPAD_CHAN_3);
// Free Font Texture
GRRLIB_FreeTexture(tex_BMfont1);
// Free All Images Textures
free_all_textures();
// Destory Linked List Freeing Memory
obj_destroy_all(Obj);
// Free initial LInked List object
free(Obj);
// Be a good boy, clear the memory allocated by GRRLIB
GRRLIB_Exit();
// Exit
return 0;
}



Edited 3 time(s). Last edit at 02/15/2010 12:35PM by LordAshes.

If you need all those information from the Wii Remote you should use the WPAD_Data function. It will return you a WPADData structure:

typedef struct _wpad_data
{
	s16 err;

	u32 data_present;
	u8 battery_level;

	u32 btns_h;
	u32 btns_l;
	u32 btns_d;
	u32 btns_u;

	struct ir_t ir;
	struct vec3w_t accel;
	struct orient_t orient;
	struct gforce_t gforce;
	struct expansion_t exp;
} WPADData;

You could try WPAD_Shutdown() after the WPAD_Disconnect()s

Crayon,

Thanks for the heads up. I think I was initially using this function and got the STACK DUMP so I switched to trying the individual functions but I will double check that (i.e. swap back to using the WPAD_Data). The other reason why I was seperating the function calls is because the code is actually a generic template for use with a PC based program that will allow Beginner Programmers to use a drag and drop type environment to write C code (with automatic code for displaying objects, doing animation, moving objects, etc). There is already at least one product like that for the Wii but it has gotten a bad rap (for trying to hide the fact that the compiling is done by DevKitPro and for having a free for the Pro version) and it lacks a lot of basic features that users are asking for. My program just helps write the C code (so that there is no hiding the fact that DevKitPro does the compiling) which can the be compiled using a compiler such a the DevKitPro tool set.

For this reason it might be better for me to keep the function calls seperate because then I can add some optimization code which executes these functions only if they are actually needed.

Arikado,

I will give that a try to see if it makes any difference.


I am wondring if it has something to do with reading the IR data for Wiimotes that are not connected. Don't know, if that was the case, why the problem would occur at end of the program instead of while running...but that is the only thing I can think of.


* UPDATE *

Yup. Its the IR code and it appears to be only if you check IR for Wiimotes that are not connected. When I commented out the IR reading code, the program exited fine. When I put them back in, it produces the STACK DUMP on exit. However, when I uncommented the IR read for the first Wiimote then the program also exited fine. I am guessing that the program has a exit problem if you read IR data for Wiimotes that are not connected...So all I have to do now is figure out a which Wiimote Channels are being used only only read those. I am sure there is a function for determining connected Wiimotes. I'll post the correct once I get it working.



Edited 1 time(s). Last edit at 02/17/2010 01:34PM by LordAshes.

Okay...I am trying to figure out how to determine what devices (Wiimotes, Classic Controller, Balanceboard, etc) are connected.

I am guessing I need to use WPAD_GetStatus() or WPAD_Probe() but I can't see to find any documentation on these functions.

Anyone know were I can get details on these functions? (wiipad.h and wiiuse.h did not seem to cover any explanation)

* UPDATE *

I tried to named topic (by editing the subject line) to indicate both the original problem (crash on exit) and how to implement a soution (detect wiimotes so you don't read IR info for a non connected wiimote) but it did not change...maybe this needs administrator intervention?



Edited 2 time(s). Last edit at 02/19/2010 02:41PM by LordAshes.

WPAD_GetStatus() returns the initialization status of the library. But not for each wiimote. So it won't help you.

WPAD_Probe(s32 chan,u32 *type)
returns WPAD_ERR_NO_CONTROLLER when there is no controller connected to that channel. WPAD_ERR_NONE when there is a controller connected. And WPAD_ERR_NOT_READY when the extension controller is still initiating.

If you give in a none NULL value for type then it puts the extension controller type in that variable.

Suggest we rename this subject to have something to do with the Wiimote like "WPAD causing weird crashes" so that other folks with similar problems can learn from this thread and not skip over it because they think it is about GRRLIB.

Just a thought...

I switched to using WPAD_Probe and WPAD_Data. There relevant section of code is as follows...

I tried:

u32 ext;

WPAD_Init();

int active1=(WPAD_Probe(WPAD_CHAN_0, &ext)!=WPAD_ERR_NO_CONTROLLER);
int active2=(WPAD_Probe(WPAD_CHAN_1, &ext)!=WPAD_ERR_NO_CONTROLLER);
int active3=(WPAD_Probe(WPAD_CHAN_2, &ext)!=WPAD_ERR_NO_CONTROLLER);
int active4=(WPAD_Probe(WPAD_CHAN_3, &ext)!=WPAD_ERR_NO_CONTROLLER);

if(active1){WPAD_SetDataFormat(WPAD_CHAN_0, WPAD_FMT_BTNS_ACC_IR);}
if(active2){WPAD_SetDataFormat(WPAD_CHAN_1, WPAD_FMT_BTNS_ACC_IR);}
if(active3){WPAD_SetDataFormat(WPAD_CHAN_2, WPAD_FMT_BTNS_ACC_IR);}
if(active4){WPAD_SetDataFormat(WPAD_CHAN_3, WPAD_FMT_BTNS_ACC_IR);}

WPADData *wiimote_data[4];

WPAD_SetVRes(0, 640, 480);

if(active1){wiimote_data[0]=WPAD_Data(WPAD_CHAN_0);}
if(active2){wiimote_data[1]=WPAD_Data(WPAD_CHAN_1);}
if(active3){wiimote_data[2]=WPAD_Data(WPAD_CHAN_2);}
if(active4){wiimote_data[3]=WPAD_Data(WPAD_CHAN_3);}


But it is hanging somewhere. It never gets to my main look to actually draw any graphics (i.e. I get a black screen). In this state, when I press any buttons on the wiimote, I get the led flasshing for a while but no apparent controller number showing.

Is the value returned by WPAD_Probe a single value so I can use a comparison such as equal to or not equal to (as in the above code) or is it a values that represents multiple possible states so you have to use a bit mask to check for a specific state (e.g. WPAD_Probe(WPAD_CHAN_0, &ext) & WPAD_ERR_NO_CONTROLLER != 0). In either case that could lead to a faulty active status but it should not lead to a hang.

My graphics drawing code is after the above partial code and it runs fine if I change the active variable calculations to a hard coded 1 (as opposed to using the WPAD_Probe function)...So the hang up must be related to the WPAD_Probe. Do I need to do a WPAD_ScanPads first?

I did notice, however, that my original problem is gone. Now, when I set the active variable for a 4 controllers to 1 (i.e. I don't use WPAD_Probe) and the I use WPAD_DATA to read all the data (inclduign IR) for all 4 wiimotes then it does not crash on exit anymore. So really my problem is solved but for code optimization I would like to get the WPAD_Probe check working so that I don't, unncecessarily, try to read data from wiimotes that are not connected.



Edited 2 time(s). Last edit at 02/20/2010 01:56PM by LordAshes.

You are using the r19 (latest official release) builds of devkitPPC, libogc, and libfat, correct?

Not sure how to check but I used the DevKitProUpdater 1.5.0 to download the version.

I believe I have the latest version.

You didn't declare a structure to hold the 4th controller's data:

	ir_t ir[3];  //<=== change 3 to a 4 for all of these
	orient_t orient[3];
	vec3w_t accel[3];
	gforce_t gforce[3];

Your 'active' pointer is never assigned to a valid address that I can see in your program. You need some place to store what active points to. I think I'd just make that a normal int, instead of a pointer to an int, but I don't know what you had in mind here.

typedef struct node
{
    int ID;		
    int *active;   //<==== where is this assigned to a valid address?
 ....

I don't get a crash/hang when I fixed those issues. Good luck with your project.

Thanks for the catch on the first issue. I keep forgetting that in C array dimensions represent the number of elements (4 elements from 0 to 3) instead of the highest element number (like in VB). Yes...I am a VB programmer and I am not ashamed to say so .

The second fix (re active), however, should not be necessary. There are only 4 controllers and thus I created (hard coded) 4 variables (active1, active2, active3, and active4). Now that I think about it, I am not sure why I didn't just use an array.

However, this "active" status would not go in the object structure. The object structure is for different objects that are going to be displayed but they have no direct connection to wiimotes so storing the wiimote status in the object structure is not only unnecessary but also a memory waste. You may have a lot more than 4 object instances in the project and thus each object instance after the 4th would be reserving this variable without using it.

I will try implementing the first fix only and see if that solves my problem.

Thanks for your help.

Reply Quote