This position crashes Houdini 1.5 and Stockfish

[bob]

That will cause many problems for programs that don't at least sanity-check the FEN before starting a search.

No, we don't sanity-check the FEN string.

Personally I don't believe in fixing downstream, I believe more in fixing upstream (read the GUI)...incidentally that's the reason why SF currently experiences time losses with Arena and, if it is up to me, it will experience also in the future

Sorry but that violates basic software engineering principles. A "robust" program can't be crashed by _any_ possible input errors. It would be much more helpful for an engine to point out input errors rather than just crashing, since many users use UCI engines directly without a GUI (you can find references here in CCC where some type UCI commands in directly).

My approach is to fix any problem I can. One can't solve all GUI problems, but one can avoid crashes that result from a GUI mistake, or possibly an end-user mistake. It isn't reasonable to expect end users to be perfect.

I've watched Linus Torvalds have this same argument with the glibc group. They made a change to memcpy() that caused the adobe 64 bit flash player to misbehave. The change was not necessary. But with the standard saying that memcpy() should not have overlapping strings, and with Adobe using overlapping strings, the change to glibc caused the flash player to start screwing up sound conversions. Torvalds said "why break something that worked." The glibc folks said both ways follow the standard, so this is something Adobe needs to fix. Linus said glibc was working fine before the change, there is no justification to copying the strings right to left rather than left to right, so why not revert. You are causing _real users_ a problem here, and finger-pointing is not helping. He was dead on...

[Tom Barrister]

I didn't notice the FEN string, either. That would explain a lot of other crashes. Both engines work fine when that's fixed.

Thanks.

[IWB]

Hello

I wanted to see the engines crash with the original false FEN and found out that Houdini and Stockfish were not crashing in the Classic. I was a bit suprised to find, that the Shredder CLessic GUI is automaticaly correcting the FEN to this:

2r2q1k/6pp/Q4pn1/3p4/2p1n3/5P2/PPP4P/4R1K1 b - -

... and of course both Engines run flawlesly here.

So the question is, how did you get that wrong FEN, was the GUI producing it? Then is would be a Bug in the GUI you used. Another question is if a wrong FEN should be accepted by a GUI at all?

Bye
Ingo

[stevenaaus]

Yes.. the GUI should do the sanity checking.

Scid vs. PC does perform castling sanity checks from the "Edit->SetupBoard" menu, and i'll add these checks to the more often used "Edit->Paste FEN" feature.

[michiguel]

Hello

I wanted to see the engines crash with the original false FEN and found out that Houdini and Stockfish were not crashing in the Classic. I was a bit suprised to find, that the Shredder CLessic GUI is automaticaly correcting the FEN to this:

2r2q1k/6pp/Q4pn1/3p4/2p1n3/5P2/PPP4P/4R1K1 b - -

... and of course both Engines run flawlesly here.

So the question is, how did you get that wrong FEN, was the GUI producing it? Then is would be a Bug in the GUI you used. Another question is if a wrong FEN should be accepted by a GUI at all?

Bye
Ingo

The engine should not "accept" the wrong FEN string because it is wrong, but according the the UCI protocol it should "ignore" it rather than "crash". The engine should never crash. That violates UCI

Miguel

[mcostalba]

The engine should not "accept" the wrong FEN string because it is wrong, but according the the UCI protocol it should "ignore" it rather than "crash". The engine should never crash. That violates UCI

In software development there are cases when to crash is better then to silently ignore...and this is one of them.

But I don't want to be tedious on this tecno-philosophical matters (also because a proper argumentation would be very long and pedantic), so please assume I accept the comment of Bob and the your.

[michiguel]

The engine should not "accept" the wrong FEN string because it is wrong, but according the the UCI protocol it should "ignore" it rather than "crash". The engine should never crash. That violates UCI

In software development there are cases when to crash is better then to silently ignore...and this is one of them.

But I don't want to be tedious on this tecno-philosophical matters (also because a proper argumentation would be very long and pedantic), so please assume I accept the comment of Bob and the your.

I read Tord's explanation a while ago and it made sense, Bob opinion makes sense too. There is a different design philosophies and I understand both. However, there is a protocol and unfortunately, that should be respected. Of course, you are not at fault that the UCI protocol had weird decisions (like it is valid for the GUI to send crap), but that is what we have.

Code: Select all

* if the engine or the GUI receives an unknown command or token it should just ignore it and try to
  parse the rest of the string in this line.
  Examples: "joho debug on\n" should switch the debug mode on given that joho is not defined,
            "debug joho on\n" will be undefined however.

* if the engine receives a command which is not supposed to come, for example "stop" when the engine is
  not calculating, it should also just ignore it.

I really doubt that every engine supports the silliness that "#e$%^&HgtbTG debug on" is valid.

Having said that (and I am realizing about this now), the protocol is poorly written and because of that, you have a point if you say that the engine could crash. That line that says "will be undefined however" gives you the freedom to crash, format the HD, an other things , but it is contradictory to the previous sentences...
I do not think it is meant here to say "undefined behavior", though.

Miguel

[Houdini]

I was a bit suprised to find, that the Shredder CLessic GUI is automaticaly correcting the FEN to this:

2r2q1k/6pp/Q4pn1/3p4/2p1n3/5P2/PPP4P/4R1K1 b - -

... and of course both Engines run flawlesly here.

Note that the FEN strings produced by Shredder are equally invalid, the move number and 50-move count are not present.

Robert

[mcostalba]

Code: Select all

* if the engine or the GUI receives an unknown command or token it should just ignore it[/quote]

This is correct and is a good rule (it allows protocol to expand keeping working old engines), but we are talking of something _completely_ different.

Sending an illegal FEN is _not_ sending an unknown command.

We are _not_ talking of UCI protocol issues, UCI protocol has _nothing_ to do with sending an illegal FEN string.

The protocol is just the transport mechanism and it works flawless, it is the _content_, the payload that is incorrect. A good protocol should be transparent to the content it carries and so is UCI that has some weak point, for sure, but _not_ in this example.

[Dann Corbit]

The correct approach is to diagnose the problem and report it.
Maybe 1 out of 50 engines will do that.

Crashing on bad input is sometimes lazy programming. The other alternative is a bad interface specification, which leaves the programmer literally no choice to repair the problem.

The case in hand is in the gray area between these two extremes, but some programs handle it correctly (IMO).

I think that every PGN, EPD, and FEN parser should have tests for reasonableness.

Optimally (for example), if the castle rights are bad, they should be reported as incorrect, corrected, and then processing should proceed against the corrected record.

I doubt if any engine does this.