To pradu (bis)

[Michel]

If you have time could you check if the unicode version of PSWBTM I posted above compiles for you under Linux?

There are probably still bugs. But the GUI should fire up fine. And configuring engines etc should work.

Regards,
Michel

[H.G.Muller]

I could try that tonight, but I am not really used to Linux, and I will proably get a lot of error messages for missing libraries or include files, and then I would not know what to do. (I could not even compile the test.c you gave above...)

[Michel]

could try that tonight, but I am not really used to Linux, and I will proably get a lot of error messages for missing libraries or include files, and then I would not know what to do. (I could not even compile the test.c you gave above...)

Normally for Ubuntu you need the wx development packages. I think they are

Code: Select all

libwxbase2.8-dev
libwxgtk2.8-dev

These contain headers and libraries for wx.

Doing

Code: Select all

apt-get install libwxbase2.8-dev   libwxgtk2.8-dev

should install them (there are also GUI ways of doing this) .

[H.G.Muller]

Well, on the Ubuntu I have running in my VirtualBox I don't get the test.c example running. Giving the compile command that you specify, I get

g++: wx-config --cflags: No such file or directory
g++: wx-config --libs: No such file or directory
test.c:1:19: error: wx/wx.h: No such file or directory

and then some undeclared variable errors.

Yet apt-get did say I already had the latest versions of the two packages you mentioned. I might have broken them. I now remember having renamed some links to libraries that PSWTBM was complaining were not there, a few months ago, because I did find libraries of nearly the same name on my system. (That did not work; it started complaining about the version in stead.) Is there a way to reinstall them?

[edit] I guess this was not the reason: I also tried it on an Ubuntu that runs on the bare machine, for which the packages really did install. But I get exactly the same errors.

[Michel]

Hmm that is extremely weird.

g++: wx-config --cflags: No such file or directory
g++: wx-config --libs: No such file or directory

Were you really using back quotes here? I mean ` .... `. Not ' .... '.

Can you execute wx-config in a terminal?

error: wx/wx.h: No such file or directory

This a corollary of the previous errors. g++ does not know the correct include path
since wx-config did not execute.

Michel

[H.G.Muller]

Were you really using back quotes here? I mean ` .... `. Not ' .... '.

Oops! That seemed to be the problem. At least I can compile test.c now.

[H.G.Muller]

OK, I have gotten to the bottom of this. It is very subtle, but in the end it is in error in xboard. This is good news, as it means I can fix it!

What happens is that xboard does the standard thing to set up a pipe:

Code: Select all

void SetUpChildIO(to_prog, from_prog)
     int to_prog[2], from_prog[2];
{
    signal(SIGPIPE, SIG_IGN);
    pipe(to_prog);
    pipe(from_prog);
}

xboard()
{  ...
    SetUpChildIO(to_prog, from_prog);

    if ((pid = fork()) == 0) {
   /* Child process */
   dup2(to_prog[0], 0);
   dup2(from_prog[1], 1);
   close(to_prog[0]);
   close(to_prog[1]);
   close(from_prog[0]);
   close(from_prog[1]);
   dup2(1, fileno(stderr)); /* force stderr to the pipe */

   if (dir[0] != NULLCHAR && chdir(dir) != 0) {
       perror(dir);
       exit(1);
   }

        execvp(argv[0], argv);
   
   /* If we get here, exec failed */
   perror(argv[0]);
   exit(1);
    }
   
    /* Parent process */
    close(to_prog[0]);
    close(from_prog[1]);
   
    cp = (ChildProc *) calloc(1, sizeof(ChildProc));
    cp->kind = CPReal;
    cp->pid = pid;
    cp->fdFrom = from_prog[0];
    cp->fdTo = to_prog[1];


Xboard sets up 2 pipes, then forks off child process for the engine. Both parent and child are then in possession of both in and output of each pipe, and they close the end they do not need. Finally the child duplicate the descriptors it kept as 1 (the input of the pipe to xboard) or 0 (the output of the pipe from xboard), so that it becomes standard input and output. After this, the child becomes the engine. Absolutely standard.

If xboard is started up from the shell, stdin and stdout are open (but not used). Creating the pipes uses the lowest unused file descrptors, which are 4, 5, 6 and 7. Two od these are duplicated to 0 an 1, which closes the original 0 and 1 as a side effect. Perfect,

But now comes the crux:

If xboard is started by PSWBTM, the wxwidgets exec all closes some descriptors, in particular 1. When the pipes are created, they have descriptors 1, 3, 4 and 5. This means that in closing the unused pipe end, you actually close he newly created standard output!

So the bottom line is that the xboard code is not resistant to 0 or 1 being amongst the descriptors of the created pipes. To make it mor resistant the unused pipe ends should be closed before the dup2() calls, to prevent them closing a just created stdin or stdout. Even then there is a risk, as the first used pipe end we duplicate might inadvertently close the end we wanted to duplcate next. I guess this can be prevented by first duplicating to 0 the end of the pipe that was created first, as the pipe that was created second can never hav received file descriptor 0.

I will change the xboard code accordingly.

[Pradu]

It seems like you guys have gotten to the root of this problem. Great job! I'll wait for a new xboard and make both a Windows and a Linux executable (statically-linked) for the next PSWBTM release.

[Michel]

Nice catch!

I think it is debatable whether this should be called a bug in xboard since numerous
other programs use the same idiom. Including my own ucibench.

I'll forward your comment to the wxWidgets mailing list.

Regards,
Michel

[Michel]

Hi Pradu,

Wouldn't it be better to use unicode? As I showed it is a relatively trivial change. That way PSWBTM can be easily compiled by Linux users themselves. Linux users do not really like static executables.

Regards,
Michel

[Pradu]

Hi Pradu,

Wouldn't it be better to use unicode? As I showed it is a relatively trivial change. That way PSWBTM can be easily compiled by Linux users themselves. Linux users do not really like static executables.

Regards,
Michel

Ok, I will look at your changes and see if I can merge them in.

[Michel]

Ok, I will look at your changes and see if I can merge them in.

Ok please have a look.

Reading the documentation I noticed that to convert a wxString 'str' from unicode to ascii (for printf) one might probably also use

(const char *)str.ToAscii()

instead of the more wordy.

(const char *)str.mb_str(wxConvUTF8))

which I have used.

I have not tested the ToAscii form. But ToAscii agrees nicely with FromAscii.

Regards,
Michel