Strange crash (with certain pak-set)

[Junna]

Start game - load pak. Click away the menu so that you can see the demo.sve. Click any train, and try to open its schedule (line manager).

Instant crash for me.

http://www.mediafire.com/download/27c39cn0zh7twy6/Pak128.Britain-Ex-0.8.4J.rar

Not reproducible with 0.9.0 for some reason.

[Junna]

Is it hard to reproduce or something?

[jamespetts]

Apologies for not replying sooner - I had been away for the week-end and unable to debug.

This is an odd one: I can reproduce this in the released 11.8 version but not on a debug build compiled from the 11.x branch. Two possibilities: either the issue is fixed in the 11.x branch, or it is one of those very difficult bugs that can only be reproduced in release mode.

The best thing to do for now is see whether the next release (11.9) will fix this for you: if it does not, I shall have to try to undertake some more detailed investigation.

[Junna]

It persists in 11.9.

Does it for you?

[jamespetts]

Hmm -  yes, it does, but only in the release version. Very strange, and, sadly, very hard to debug. Can you summarise the changes between the normal 0.8.4 and your version to give me an idea where to look?

Edit: Running this with Dr. Memory on a debug build does not produce anything untoward. Running this with Dr. Memory on a release build produces less useful output, as all the debug symbols are stripped. The output does, however, contain many (320 in total) errors like this:

Code Select Expand

Error #1: INVALID HEAP ARGUMENT: allocated with operator new, freed with operator delete[]
# 0 Simutrans-Experimental.exe!?             +0x0      (0x0042a6fe <Simutrans-Experimental.exe+0x2a6fe>)
# 1 Simutrans-Experimental.exe!?             +0x0      (0x0042a678 <Simutrans-Experimental.exe+0x2a678>)
# 2 Simutrans-Experimental.exe!?             +0x0      (0x00429d3c <Simutrans-Experimental.exe+0x29d3c>)
# 3 Simutrans-Experimental.exe!?             +0x0      (0x00625125 <Simutrans-Experimental.exe+0x225125>)
# 4 Simutrans-Experimental.exe!?             +0x0      (0x005c35a1 <Simutrans-Experimental.exe+0x1c35a1>)
# 5 Simutrans-Experimental.exe!?             +0x0      (0x005c356a <Simutrans-Experimental.exe+0x1c356a>)
# 6 Simutrans-Experimental.exe!?             +0x0      (0x00496dff <Simutrans-Experimental.exe+0x96dff>)
# 7 Simutrans-Experimental.exe!?             +0x0      (0x00461108 <Simutrans-Experimental.exe+0x61108>)
# 8 KERNEL32.dll!BaseThreadInitThunk
# 9 ntdll.dll!RtlInitializeExceptionChain
#10 ntdll.dll!RtlInitializeExceptionChain
Note: @0:00:00.396 in thread 8308
Note: memory was allocated here:
Note: # 0 MSVCR110.dll!operator new
Note: # 1 Simutrans-Experimental.exe!?             +0x0      (0x0042a5f6 <Simutrans-Experimental.exe+0x2a5f6>)
Note: # 2 Simutrans-Experimental.exe!?             +0x0      (0x00429d3c <Simutrans-Experimental.exe+0x29d3c>)
Note: # 3 Simutrans-Experimental.exe!?             +0x0      (0x006250e4 <Simutrans-Experimental.exe+0x2250e4>)
Note: # 4 Simutrans-Experimental.exe!?             +0x0      (0x005c35a1 <Simutrans-Experimental.exe+0x1c35a1>)
Note: # 5 Simutrans-Experimental.exe!?             +0x0      (0x005c356a <Simutrans-Experimental.exe+0x1c356a>)
Note: # 6 Simutrans-Experimental.exe!?             +0x0      (0x00496dff <Simutrans-Experimental.exe+0x96dff>)
Note: # 7 Simutrans-Experimental.exe!?             +0x0      (0x00461108 <Simutrans-Experimental.exe+0x61108>)
Note: # 8 KERNEL32.dll!BaseThreadInitThunk
Note: # 9 ntdll.dll!RtlInitializeExceptionChain
Note: #10 ntdll.dll!RtlInitializeExceptionChain


Sadly, it gives no clue in which methods that these incorrect freeings of objects with delete[] arise (because  of the strippings of debug symbols), and it is unclear why this should arise only in a release build.

There is also then this, which is probably the crash itself:

Code Select Expand



Error #321: UNADDRESSABLE ACCESS: reading 0xc8085610-0xc8085611 1 byte(s)
# 0 <not in a module>   (0x0f9bb01e)
# 1 Simutrans-Experimental.exe!?     +0x0      (0x005b2ec8 <Simutrans-Experimental.exe+0x1b2ec8>)
# 2 Simutrans-Experimental.exe!?     +0x0      (0x005e2c54 <Simutrans-Experimental.exe+0x1e2c54>)
# 3 Simutrans-Experimental.exe!?     +0x0      (0x005c0482 <Simutrans-Experimental.exe+0x1c0482>)
# 4 Simutrans-Experimental.exe!?     +0x0      (0x0060f69e <Simutrans-Experimental.exe+0x20f69e>)
# 5 Simutrans-Experimental.exe!?     +0x0      (0x005c03a2 <Simutrans-Experimental.exe+0x1c03a2>)
# 6 Simutrans-Experimental.exe!?     +0x0      (0x0060d516 <Simutrans-Experimental.exe+0x20d516>)
# 7 Simutrans-Experimental.exe!?     +0x0      (0x005c4fd1 <Simutrans-Experimental.exe+0x1c4fd1>)
# 8 Simutrans-Experimental.exe!?     +0x0      (0x005c356a <Simutrans-Experimental.exe+0x1c356a>)
# 9 Simutrans-Experimental.exe!?     +0x0      (0x00496dff <Simutrans-Experimental.exe+0x96dff>)
#10 Simutrans-Experimental.exe!?     +0x0      (0x00461108 <Simutrans-Experimental.exe+0x61108>)
#11 KERNEL32.dll!BaseThreadInitThunk +0x11     (0x757a33aa <KERNEL32.dll+0x133aa>)
Note: @0:01:07.120 in thread 8308
Note: instruction: test   0x05(%ebx) %dl


Again, no clues where this actually arises, but it does suggest that the issue is reading a deleted, rather than a NULL, pointer, which might be related to the previous 320 errors. There are also some leaks reported, but these are unlikely to be relevant.

If anyone has any clues how to track this down further, I should be very grateful.

[Junna]

Well, actually, I haven't really changed anything apart from modifying capacities (particularly increasing maximum overload to 200%) and removing retirement dates, as well as modifying all running costs that I considered too high (standardised locos around 5(+-3) or so). A few test things too... I tried to increase electricity production per unit consumed for an oil power station (decrease the speed of its consumption, I mean), but I messed something up with that one I think, well, my changes didn't seem to work the way I expected them to judging by the .dat.

There aren't that many other changes (and technically it's 0.9.0, and most are compiled from recent .dats and .png's), I just haven't changed the folder name, etc.

[jamespetts]

Hmm - which version of Makeobj do you use?

[Junna]

Hmm - which version of Makeobj do you use?

Various different ones have been used for various files. I use the most recent now, but not all things are entirely up to date (but most vehicles, at least, are) - though surely there ought to be backwards compatibility for older versions?

I've tried to make sure there were nothing wrong with the config files and so on, but I have not managed to determine anything as the cause, the crash persists.

[jamespetts]

There should be backwards compatibility for older versions, but it helps to narrow down the cause of the bug (which might be a failure in that backwards compatibility) to know the versions that you have used.

Do you not use the automated compile Python script, makeall.mos? This rebuilds all files with the latest version of Makeobj automatically. Try doing that and see whether you still get the problem. If you do, we can eliminate versioning issues.

[Junna]

I've been able to pin-point the problem to the way. paks. Not sure exactly which of them yet, but it's one of them that is causing the problem.

[jamespetts]

Thank you. May I ask what method that you have used?

[Junna]

Thank you. May I ask what method that you have used?

The long and arduous process of removing (adding others from a working pak) and testing!

[jamespetts]

Have you tried recompiling the ways with the latest Makeobj?

[Junna]

Have you tried recompiling the ways with the latest Makeobj?

I have indeed done so, but it didn't help. I will try recompiling from source without modifications and see if that works better...

[jamespetts]

Thank you - that is very helpful indeed. If you can find which specific modification causes the crash, that would be extremely helpful.

[greenling]

Hello Jamespetts
I think that the problem, that junna be posted have come from the new axlelloadcode.

[jamespetts]

Why do you think that?

[Junna]

I have managed to pin-point the problem specifically now, it is related to the first add-on on this page, which I used because it included a monorail with matching graphics to fit with the pak.britain:

http://japanese.simutrans.com/index.php?Addon128%2FMonorailTools%201

I did not compile these myself. The download includes sources, however.

[jamespetts]

Junna,

thank you - that is helpful. It would help me greatly if you could run a test by compiling these yourself and using your own compiled version instead of the binary version. If the problem persists, then the issue is the treatment of the content itself: if the problem is cured by this, the problem is in the handling of legacy pak file formats.

[Junna]

Recompiling it does not help. So I'd say there's something specific that is causing the issue.

[jamespetts]

Thank you for checking that. Hmm - this is a rather difficult one to track down given that it does not appear in debug. When you compiled it yourself, did you compile all of the objects, or did you do them one by one?

[Junna]

I use a bat to execute "makeobj pak128 ./ ./" in the folder of any .dats.

Seeing as the crash occurs on the line manager, maybe it has something to do with the display of monorail within that?

[jamespetts]

Yes, I was wondering that - but the little monorail icon is defined separately in the GUI .dat files, so it is difficult to see what is happening here.

Can you try compiling each object one by one and just using that single object to see which specific object(s) cause the crash? I should be extremely grateful.

[Junna]

It's the track and elevated track files that are responsible. All the others work out all right.

[jamespetts]

Thank you - that is helpful.

Edit: Further testing suggests odd things going on with release builds generally: I have requested help in that respect on this thread.

[prissi]

This failing in release builds in MSVC could be very well a compiler/optimiser error. Does a mingw release build work?