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.
OSX Xboard 4.7.2 .app
Moderators: hgm, Rebel, chrisw
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
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?
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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!
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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.
-
- Posts: 27809
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
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
Anyway, it is bed time for me too, so indeed a good time to stop.
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);
}
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: OSX Xboard 4.7.2 .app
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.hgm wrote: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
Anyway, it is bed time for me too, so indeed a good time to stop.Code: Select all
FILE *f = fopen(...); if( f == NULL ) { printf("fopen failed; error = %d\n", errno); } else { fprintf(f, ....); fclose(f); }
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]
-
- Posts: 589
- Joined: Tue Jun 04, 2013 10:15 pm
Re: OSX Xboard 4.7.2 .app
Try /Users/joshua/temp.debugJoshPettus wrote: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.
[Account deleted]
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
gah you're right! I must have had ubuntu on the brain...I feel so silly
-
- Posts: 589
- Joined: Tue Jun 04, 2013 10:15 pm
Re: OSX Xboard 4.7.2 .app
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.
[Account deleted]
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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.
I separated each time I opened the file for you myself.
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