Crash when building a new industry
Moderator: TTDPatch Moderators
Crash when building a new industry
I'm testing out the new Desal plant, (the GRF is indeed broken), and managed to produce this crash when I attempted to build the plant in the scenario editor.
I thought it was just something wrong with the GRF file, but the last line of the crashlog proves otherwise.
I have been unable to reproduce the problem, but hopefully all the relevant stuff is here.
I thought it was just something wrong with the GRF file, but the last line of the crashlog proves otherwise.
I have been unable to reproduce the problem, but hopefully all the relevant stuff is here.
- Attachments
-
- stuff.rar
- (22.06 KiB) Downloaded 41 times
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
I don't have time right now to look at this in detail, but it seems to be in an action 3 that didn't get defined correctly. Did it possibly get skipped by an action 9?
In any case, the patch is attempting to locate the definition of an action 3, but only finds zeroes, and dereferencing those causes the crash.
If that's not enough clue, I'll have to look at it in detail, but I'm pretty sure that it's a bad action 3 somewhere.
[edit] Hmm, it seems to be a generic callback actually. I can't tell what feature. Possibly it's one of the action 3's in the chained callback that's broken.
[edit2] Actually, if it was a chained callback, the crash log should show the previously processed sprite as error location. Since there is no error location, it must be the first entry in the chain, i.e. the last action 3 to define a generic callback.
In any case, the patch is attempting to locate the definition of an action 3, but only finds zeroes, and dereferencing those causes the crash.
If that's not enough clue, I'll have to look at it in detail, but I'm pretty sure that it's a bad action 3 somewhere.
[edit] Hmm, it seems to be a generic callback actually. I can't tell what feature. Possibly it's one of the action 3's in the chained callback that's broken.
[edit2] Actually, if it was a chained callback, the crash log should show the previously processed sprite as error location. Since there is no error location, it must be the first entry in the chain, i.e. the last action 3 to define a generic callback.
Well, then, I'm pretty sure it's not my fault. (no generic 3s, no 9s.)
OTOH, I'm having trouble getting the generic callback thing make sense; this was in the scenario editor, and the only generic callback of which I'm aware is called by the AI, which I would have guessed was inactive. BICBW.
In a slightly related department, is this really the error message that's supposed to appear? (This is, BTW, nowhere near the edge of the map.)
OTOH, I'm having trouble getting the generic callback thing make sense; this was in the scenario editor, and the only generic callback of which I'm aware is called by the AI, which I would have guessed was inactive. BICBW.
In a slightly related department, is this really the error message that's supposed to appear? (This is, BTW, nowhere near the edge of the map.)
- Attachments
-
- message.png (18.69 KiB) Viewed 1167 times
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
I did a little debugging with your files, and I found the reason for the "Too close to edge of map" bug. It was a "sleeper bug" in original TTD code (something done incorrectly, but luckily not causing a bug) that allowed bogus messages to appear instead of "Site unsuitable". The bug got "woken up" by the callback 2F code, that's why it wasn't found before. The next alpha will fix the TTD bug, so "Site unsuitable" will be displayed correctly.
OTOH, I couldn't reproduce your crash, so I couldn't debug that.
OTOH, I couldn't reproduce your crash, so I couldn't debug that.
Reality is that which, when you stop believing in it, doesn't go away.—Philip K. Dick
The bug is now reproducable. It seems to require a certain land shape to be triggered.
To cause this crash, load the included scenario (Title: "Crash"), and build a desal plant at the Build Here sign (see image).
It seems to require that three GRFs be loaded; I included all three in morestuff, and a minimal newgrfw.cfg. Changing the order of the GRFs does not appear to change the crash. (Most notably, no "While processing file ..., sprite ..." line appears.)
I also tossed in all the crashlogs.
In case it's meaningful, I'll point to the fact that 5 and 13 compressed larger than the remainder of the crashlogs[0]; they may be different. All were created the same way, though, just with different newgrfw.cfgs.
[0] Well, except 0, which is large because it is first.
To cause this crash, load the included scenario (Title: "Crash"), and build a desal plant at the Build Here sign (see image).
It seems to require that three GRFs be loaded; I included all three in morestuff, and a minimal newgrfw.cfg. Changing the order of the GRFs does not appear to change the crash. (Most notably, no "While processing file ..., sprite ..." line appears.)
I also tossed in all the crashlogs.
In case it's meaningful, I'll point to the fact that 5 and 13 compressed larger than the remainder of the crashlogs[0]; they may be different. All were created the same way, though, just with different newgrfw.cfgs.
[0] Well, except 0, which is large because it is first.
- Attachments
-
- buildhere.png (37.15 KiB) Viewed 1099 times
-
- morestuff.rar
- (139.31 KiB) Downloaded 31 times
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Well, now I'm confused...
The crash indeed occurs with the official a58, but the same thing works fine with my devel version, even when I turn off the debugging help.
Either it's a very obscure bug, or I happened to fix it without knowing what I was doing
The crash indeed occurs with the official a58, but the same thing works fine with my devel version, even when I turn off the debugging help.
Either it's a very obscure bug, or I happened to fix it without knowing what I was doing

Reality is that which, when you stop believing in it, doesn't go away.—Philip K. Dick
I found the bug. Callback 30 is called with garbage in bits 8..31 of eax and so getnewsprite dies. It seems to not be fixed in your a59 changes, it just happens that this garbage is now zero by coincidence.
Csaba: Is there a reason why getindustileid returns only al and not eax? It's easy enough to fix in this instance, but it seems to be safer if it returned the value in eax.
Csaba: Is there a reason why getindustileid returns only al and not eax? It's easy enough to fix in this instance, but it seems to be safer if it returned the value in eax.
Who is online
Users browsing this forum: No registered users and 16 guests