Mysterious train crash

[DeeDee]

Hello everybody

I have played OTTD a few years now, but never saw such a strange crash.
Train #10 just crashed without colliding with anoter train.
Maybe it's a bug in some patch of the GonozalIn (which I use), it's quite mysterious, though.

The crash occured suddenly, without any intervention of me. That train (and others) has passed that location many times before safely.
Breakdowns are disabled, it was no UFO (it's just 1936). I use the DBSetXL.
If I load the last autosave, it will happen again.
Do you have any explanation about this crash or experienced something similar?

Greetz
DeeDee

[Lordmwa]

Well that is odd.

I can see that you are using YAPP? If so you may want to consider adding a few more signals. What is at the other end of that signal block?

Lordmwa

[XeryusTC]

Try posting a savegame, people can actually see if something happens then.

[DeeDee]

Thx for your replies

I attach a savegame just a few days before the crash and a screenshot of the track- and signal-layout (which is rather uncomplicated)
Remember it's made with the GonozalIn (r12180M) so it might not be loadable with recent versions

Yes, I'm using YAPP. As these tracks are only used by one line, there is no need to place more signals. The trains are timetable-based separated, and if this fails, the signals will seperate them

Greetz
DeeDee

[PhilSophus]

That's funny. If you open the train list you'll notice that Train 10 collides with Train 29 which is at a totally different location.

Anyway, as this is a very old patch pack (including an outdated version of YAPP) with a lot of patches it may well be, that the bug wasn't ever in trunk at all or has long been fixed before it produced such a result.

Edit: Given that both trains are at the same y-coordinate and the x-coordinates are considerably larger than 2048 I have the feeling that it could have something to do with the large map patch, but I don't see in which way the x-coordinates could wrap to each other (they are not the same modulo some power of two AFAICS).

[SmatZ]

Indeed, it is caused by the big maps patch.

train_cmd.cpp : 3418
if (x_diff * x_diff + y_diff * y_diff > 25) return NULL;

x_diff * x_diff doesn't fit in int32
temporal solution would be to cast to uint, better to int64

or you may try any other solution, like
if (abs(x_diff) > 5 || abs(y_diff) > 5) return NULL;

(r12180 is heavily outdated...)

[PhilSophus]

train_cmd.cpp : 3418
if (x_diff * x_diff + y_diff * y_diff > 25) return NULL;

x_diff * x_diff doesn't fit in int32

So, I guess x_pos is measured in 16*number of tiles. Anyway, you have found one reason, why the longer map border should not be longer than 2048. This kind of issue could arise in other places, too.

temporal solution would be to cast to uint, better to int64

At least int64, uint would also break on map sizes larger than 4096.

or you may try any other solution, like
if (abs(x_diff) > 5 || abs(y_diff) > 5) return NULL;

Probably the better approach. And BTW, why the hell, does this place use Euclidean distance, when almost any other place in OpenTTD uses Manhattan distance?

(r12180 is heavily outdated...)

I just noticed Bilbo already fixed that bug, as can be read in the comments from 03/22/08 and 06/30/08 here.

[SmatZ]

And BTW, why the hell, does this place use Euclidean distance, when almost any other place in OpenTTD uses Manhattan distance?

If you had a look at the sources, you wouldn't have to ask and use these strong words...

Manhattan distance would allow either crashing of competitors' trains (trains far from each other), or not crashing trains too near to each other.
Similiar, only x > 5 || y > 5 check alone isn't sufficient. And each further comparation inserts a branch instruction.

[DaleStan]

And each further comparation inserts a branch instruction.

Which is likely faster than performing two 32-bit multiplications every time, and (on 32-bit processors, at least) almost certainly faster than performing two true 64-bit multiplications every time.

Aside: All x86 processors with 32-bit registers support the generation of 64-bit integer results when multiplying two 32-bit integer operands. Do any compilers/compiler settings exist to take advantage of this trick?

[SmatZ]

And each further comparation inserts a branch instruction.

Which is likely faster than performing two 32-bit multiplications every time, and (on 32-bit processors, at least) almost certainly faster than performing two true 64-bit multiplications every time.

Surprisingly, the penalty for multiplying isn't that big:
from "Software Optimization Guide for AMD64 Processors"
IMUL reg16/32/64, mreg16/32/64 has latency 3/3/4

Of course 64bit multiplication done at 32bit computers is very expensive (I somehow forgot to mention this).

Aside: All x86 processors with 32-bit registers support the generation of 64-bit integer results when multiplying two 32-bit integer operands. Do any compilers/compiler settings exist to take advantage of this trick?

I tried to find a solution, and I failed... that doesn't mean there isn't a sulution edit: not true
Similiar with using carry flag when adding long integers.

edit 2: fixed quote (thanks planetmaker) (you see how mindless I was this morning )

[PhilSophus]

And BTW, why the hell, does this place use Euclidean distance, when almost any other place in OpenTTD uses Manhattan distance?

If you had a look at the sources, you wouldn't have to ask and use these strong words...

Sorry, the words weren't meant as strong as they were perceived apparently. I actually looked shortly at the sources, but didn't get the reason. So, thanks you for your explanations.

And each further comparation inserts a branch instruction.

Which is likely faster than performing two 32-bit multiplications every time, and (on 32-bit processors, at least) almost certainly faster than performing two true 64-bit multiplications every time.

Due to how memory and cache architectures of modern processors work, branches are actually much worse than arithmetical operations, AFAIK. If the processor can not predict the branch it will not be able to take the following instructions from the cache but will need to restart prefetching at the destination of the branch.

I tried to find a solution, and I failed... that doesn't mean there isn't a sulution
Similiar with using carry flag when adding long integers.

I could imagine that when casting the operands from int32 to int64, the multiplication is actually reduced to a 32x32->64 bit multiplication by the optimizer. But I have never looked at the output of the compiler, so I don't know.

[SmatZ]

I could imagine that when casting the operands from int32 to int64, the multiplication is actually reduced to a 32x32->64 bit multiplication by the optimizer. But I have never looked at the output of the compiler, so I don't know.

Now I am the one who to blame, with higher optimisation level the multiplication is done right this way... at least in my simple test case (so 32bit * 32bit -> 64bit uses regular imul at 32bit x86). I was in a hurry this morning and I did the test wrongly...

So it should be interesting even for DaleStan:

Code: Select all

int64 mul(int32 a, int32 b) { return (int64)a * b; }

compiles as single imul. (gcc 3.4.6 with -O0, gcc 4.3.1 with -O1)

[DaleStan]

Surprisingly, the penalty for multiplying isn't that big:
from "Software Optimization Guide for AMD64 Processors"
IMUL reg16/32/64, mreg16/32/64 has latency 3/3/4

Do you have any similar links for other x86 processors? The only Intel timings I've ever been able to find stopped at the 486, which is less than interesting.

Also, good to know that at least one compiler does it right.

Due to how memory and cache architectures of modern processors work, branches are actually much worse than arithmetical operations, AFAIK. If the processor can not predict the branch it will not be able to take the following instructions from the cache but will need to restart prefetching at the destination of the branch.

If it guesses wrong, it'll have to clear the pipelines, yes, but, at least for short jumps, it's unlikely to have a cache miss. Short jumps are never more than +127/-128 bytes; well within the usual size of a cache line. ... EDIT: Well, a data line, at least.

[SmatZ]

Do you have any similar links for other x86 processors? The only Intel timings I've ever been able to find stopped at the 486, which is less than interesting.

For Intel, I found IA-32 Intel® Architecture Optimization Reference Manual