hgm wrote:Note that originally, when this -xrm option was still understood, you also were using a \n in the string. Apparently the X-server does perform escape expanding on its options that the shell doesn't do.
sje wrote:I removed the autocomm option from the xboard invocation and restarted the program both on FICS and ICC. The idea is to see if this will make the modify-after-free bug hide in shame.
My hopes have been dashed, for a segmentation fault has appeared in absence of the autocomm option.
Well, that is actually good, because I scrutized the code called on -autoComment, and I have not been able to find anything suspicious there.
Note that in WinBoard free'ing a non-malloc'ed or damaged piece of memory causes no error, as apparently the malloc/free system on Windows uses a checksum to judge the validity of the free request, and just ignores requests with corrupted data. So the whole system is in practice only weakly tested.
So with autocomm, I see the modify-after-free bug, and without it I see a segmentation fault. Too bad there are only a limited number of data points here.
This leads me to wonder: How many people are using xboard vs winboard? Also, how many are using xboard under Mac OS/X vs xboard under Linux? I must be in a small minority here as surely others would have reported these problems earlier.
I have no real information on that, but I expect there to be about 10 times as many WinBoard users than XBoard users. Also about 10 times as many PC as Mac users. But it also matters a lot what they are using XBoard for. Not many people run ICS bots, and it could very well be that the problem only occurs when you run with a certain option that almost no one uses.
But however bleak the testing situation might be, the key to getting it repared is to have the xboard.debug file, to see what event triggers it. Without that we will remain completely in the dark.
Perhaps these bugs would be easier to re-create under Windows if it were possible to substitute a super-paranoid memory allocation library for the standard malloc/free code.
Indeed, I should replace the malloc/free funtions with my own wrappers. Iconsidered that anyway, because it seemed on my XP laptop that the free header lines in the game list was not working, causing a huge memory leak when loading big (40k games) PGN files. The code seemed OK, though.Just malloc and an accompanying free. But when I quoted those out and used a static array, the leak disappeared...
sje wrote:Perhaps these bugs would be easier to re-create under Windows if it were possible to substitute a super-paranoid memory allocation library for the standard malloc/free code.
Yes, but note that this memory leak is no fault of the program. The free call is there. It just doesn't seem to work (based on how I see the memory footprint expand in the task manager).
hgm wrote:Yes, but note that this memory leak is no fault of the program. The free call is there. It just doesn't seem to work (based on how I see the memory footprint expand in the task manager).
It could be that the Windows runtime is trying to "help" you by doing lazy deallocation. Maybe there is a Windows addition to the C library: instead of using free(), you need to use free_it_right_now_or_else().
Seriously, have you considered getting a used, older Macintosh with Mac OS/X installed? I've got a iMac PowerPC G3 that's eleven years old and runs OS/X 10.4.11 with the whole development toolchain and X Windows. Machines like this can be had for under US$25 here in the States. Using a machine with a different CPU family and a different Unix to assist with testing can save enough time to easily repay the purchase price.
