Segfault when deleting a ship design

[cordawyn]

Hi! When I go to the ship design screen, then press “load” and try to delete a ship design from the list, the game immediately segfaults. Somehow, it is not 100% reproducible, but I’d say, it would crash 9 times of 10. I’m using the 64-bit version of the game (v 1.56.0), on Ubuntu 11.10.
P.S.: This crash is not reproducible with a 32-bit version of the game.

[urkle]

@cordawyn

Hi! When I go to the ship design screen, then press “load” and try to delete a ship design from the list, the game immediately segfaults. Somehow, it is not 100% reproducible, but I’d say, it would crash 9 times of 10. I’m using the 64-bit version of the game (v 1.56.0), on Ubuntu 11.10.
P.S.: This crash is not reproducible with a 32-bit version of the game.

When it crashes did it delete the ship or is it still there?

[cordawyn]

It’s still there.

[urkle]

I’ve traced down the cause of this issue and am getting it fixed.

[offsides]

@urkle

I’ve traced down the cause of this issue and am getting it fixed.

If you don’t mind my asking, what was the problem? Just curious…

[urkle]

@offsides

@urkle

I’ve traced down the cause of this issue and am getting it fixed.

If you don’t mind my asking, what was the problem? Just curious…

casting a pointer to an object into an “int” storage variable. There were some that I missed fixing apparently. that is why it only appeared in the 64bit build. and only sometimes… Most likely you have a LOT more ram in your linux box than I have in mine (only 4GB here) so you system triggered it more frequently.

[offsides]

@urkle

@offsides

@urkle

I’ve traced down the cause of this issue and am getting it fixed.

If you don’t mind my asking, what was the problem? Just curious…

casting a pointer to an object into an “int” storage variable. There were some that I missed fixing apparently. that is why it only appeared in the 64bit build. and only sometimes… Most likely you have a LOT more ram in your linux box than I have in mine (only 4GB here) so you system triggered it more frequently.

Only hit me once, but I haven’t deleted many ship designs myself. I just wasn’t sure what had been involved in porting the game to Linux, and figured this was an opportunity to find out a bit more

Thanks for the answer!

[urkle]

@offsides

Only hit me once, but I haven’t deleted many ship designs myself. I just wasn’t sure what had been involved in porting the game to Linux, and figured this was an opportunity to find out a bit more

Thanks for the answer!

This is more of a “port to 64bit” issue than port to linux issue.

Basically the “practice” I see is this.

typedef void CALLBACK(int data);
void Button::AddButtonCallback(CALLBACK *func, int data);

void myCallback(int data);

myButton->AddButtonCallback(myCallback, (int)someObjectPtr);

which is to allow any method to be registered as a callback when the button is clicked, and have some piece of “data” passed into the callback. However this is often an object pointer… which works fine on 32bit as sizeof(void *) == sizeof(int)… However, 64bit sizeof(void *) != sizeof(int)… (8 != 4). This half of the pointer is lost.

So, there are two ways to solve this… rewrite all reference to int data and (int)objptr) to long data and (long)objptr… Or rewrite all those references to void*.

void* will be either 4 OR 8 depending on the architecture and long will be 4 or 8 depending on the architecture.

Another option would be to make it “long long” which will ALWAYS be 8 bytes regardless. And this is not the FIRST game I’ve had to do that with either. it’s a common bad practice to case pointers into INT fields.

In reality the BEST option is to use void *.

[xian27]

I an being fun of making design I’ve traced down the cause of this issue and am getting it fixed…!

[offsides]

@urkle

@offsides

Only hit me once, but I haven’t deleted many ship designs myself. I just wasn’t sure what had been involved in porting the game to Linux, and figured this was an opportunity to find out a bit more

Thanks for the answer!

This is more of a “port to 64bit” issue than port to linux issue.

Basically the “practice” I see is this.

typedef void CALLBACK(int data);
void Button::AddButtonCallback(CALLBACK *func, int data);

void myCallback(int data);

myButton->AddButtonCallback(myCallback, (int)someObjectPtr);

which is to allow any method to be registered as a callback when the button is clicked, and have some piece of “data” passed into the callback. However this is often an object pointer… which works fine on 32bit as sizeof(void *) == sizeof(int)… However, 64bit sizeof(void *) != sizeof(int)… (8 != 4). This half of the pointer is lost.

So, there are two ways to solve this… rewrite all reference to int data and (int)objptr) to long data and (long)objptr… Or rewrite all those references to void*.

void* will be either 4 OR 8 depending on the architecture and long will be 4 or 8 depending on the architecture.

Another option would be to make it “long long” which will ALWAYS be 8 bytes regardless. And this is not the FIRST game I’ve had to do that with either. it’s a common bad practice to case pointers into INT fields.

In reality the BEST option is to use void *.

I’ve gotten bit by that type of assumption before (no pun intended). I’m a sysadmin by trade and not a programmer, but I hack enough code that I’ve dealt with things like this before. Thanks for the info!