OSX Xboard 4.7.2 .app

[JoshPettus]

oh dang I put

FILE *f = fopen("/home/joshua/temp.debug", "a");
in both places

but when I opened xboard it just crashed. I take that's not what I was suppose to do.

[hgm]

That is weird. I see nothing wrong with the code. It could be that somehow the opening of the file fails, although I cannot imagine why. Then fprintf would crash because f is not pointing to a valid file. What happens when you comment out both fprintf lines?

[JoshPettus]

really weird stuff happens. It opens, but nothing loads, fairymax, board doesn't render. And no temp.debug file was generated. I think I'll have to call it a night for now. We have to run some errands, It must be really late over there Thank-you for your help today!

[JoshPettus]

I feel so bad that this has taken so much of your time. I thought it was going to be an easier problem then the menu.

[hgm]

That probably means it still crashes, but not in a way that is immediately fatal. Actually I don't know if an invalid file f (because the opening failed) can crash fclose(f). I suspect that somehow the fopen() does not work to oprn the file. Problem is that XBoard is completely dumb at this stage (we can also not popup an error dialog, as the GUI was not initialized yet), and opening the file was supposed to be the only means of communication. Opening the file could fail because the path name is wrong, or because we don't have the required permissions. I cannot think of any other reasons. Normally you would test if the fopen was successful, and print an error message with the reason if it was not. But if it was not successful, we have no way to print here...

It is very annoying that we are side-tracked into this problem. Nevertheless it is very important to be able to print something, to get an idea what is happening, and why the first OpenFile signal is ignored.

To do debugging of the debugging code, perhaps it would be possible to start XBoard from a terminal. Then we could alter the code to

Code: Select all

  FILE *f = fopen(...);
  if( f == NULL ) {
    printf("fopen failed; error = %d\n", errno);
  } else {
    fprintf(f, ....);
    fclose(f);
  }

Anyway, it is bed time for me too, so indeed a good time to stop.

[bob]

That probably means it still crashes, but not in a way that is immediately fatal. Actually I don't know if an invalid file f (because the opening failed) can crash fclose(f). I suspect that somehow the fopen() does not work to oprn the file. Problem is that XBoard is completely dumb at this stage (we can also not popup an error dialog, as the GUI was not initialized yet), and opening the file was supposed to be the only means of communication. Opening the file could fail because the path name is wrong, or because we don't have the required permissions. I cannot think of any other reasons. Normally you would test if the fopen was successful, and print an error message with the reason if it was not. But if it was not successful, we have no way to print here...

It is very annoying that we are side-tracked into this problem. Nevertheless it is very important to be able to print something, to get an idea what is happening, and why the first OpenFile signal is ignored.

To do debugging of the debugging code, perhaps it would be possible to start XBoard from a terminal. Then we could alter the code to

Code: Select all

  FILE *f = fopen(...);
  if( f == NULL ) {
    printf("fopen failed; error = %d\n", errno);
  } else {
    fprintf(f, ....);
    fclose(f);
  }

Anyway, it is bed time for me too, so indeed a good time to stop.

On every unix box I have used, if you call fopen() and it fails, it returns a NULL pointer. Passing a NULL to fclose() will instantly crash. I just verified on my linux box... It produces a segmentation fault instantly.

BTW, for more Apple amusement, first here is the note from man fclose() on mavericks:

NOTES
The fclose() function does not handle NULL arguments; they will result in
a segmentation violation. This is intentional - it makes it easier to
make sure programs written under FreeBSD are bug free. This behaviour is
an implementation detail, and programs should not rely upon it.

Of course when I compile and run on mavericks, here is what I get:

scrappy% ./tst
fopen() failed
scrappy%


Here's the simple test source:

#include <stdio.h>
int main(void)
{
FILE *f;
f=fopen("file.dat", "r");
if (!f)
printf("fopen() failed\n");
fclose(f);
}


I suppose that calling fclose() with a NULL argument is undefined on Mavericks. [/b]

[mvk]

oh dang I put

FILE *f = fopen("/home/joshua/temp.debug", "a");
in both places

but when I opened xboard it just crashed. I take that's not what I was suppose to do.

Try /Users/joshua/temp.debug

[JoshPettus]

gah you're right! I must have had ubuntu on the brain...I feel so silly

[mvk]

No problem. Your project is absolutely great. You deserve a lot more support from people who would benefit from it (such as me), and I regret that I've been paying so little attention to the technical threads.

[JoshPettus]

Thanks for the help guys!
We should just assume I'm doing something wrong. It would save time.

This debug output looks interesting: I opened the game against myself and crafty (crafty is kicking my behind in it btw, not that I'm a proficiently strong player or anything) 3 times.

Code: Select all

 82572 Start XBoard: argc = 1, arg = NONE
-------------------
 82572 Signal: suppress = 0, path = /Applications/Xboard/Josh-Crafty-23.5.pgn
 82583 Start XBoard: argc = 2, arg = /Applications/Xboard/Josh-Crafty-23.5.pgn
 82583 Signal: suppress = 1, path = /Applications/Xboard/Josh-Crafty-23.5.pgn
--------------------------
 82572 Signal: suppress = 0, path = /Applications/Xboard/Josh-Crafty-23.5.pgn
 82594 Start XBoard: argc = 2, arg = /Applications/Xboard/Josh-Crafty-23.5.pgn
 82594 Signal: suppress = 1, path = /Applications/Xboard/Josh-Crafty-23.5.pgn

I separated each time I opened the file for you myself.