11.9007 (commit 16a8ed2) segfault when deleting stop

[MCollett]

As with my previous bug report, this is using the latest 11.x branch commit from Github (16a8ed2), compiled for Mac OS X 10.8.

Completely removing any stop (i.e. demolishing all platforms and buildings, so that it is removed for the list of stops) causes the game to crash with a segmentation fault.  Usually this happens immediately (or almost so); if the stop has very low patronage there may be a small delay.

Best wishes,
Matthew

[neroden]

Do you have access to a debugger?  I can't reproduce this.  If you could get me a backtrace it would help.

----
Got it.  Reproduced successfully.  (It only affects stops near factories.)

Found and fixed (on both merge-from-standard and 11x-fixes branches).  This was a logic error on my part which was hard to see due to shadowed variable names (don't shadow your variable names, kids!).  It probably caused other subtle bugs too; they should all go away on game reload.

[MCollett]

(It only affects stops near factories.)

Well spotted, that man! I did initially observe it at an industrial stop, but also tested on what I thought was a plain bus-stop or two; there must have been some factory within walking distance that I didn't notice.   

Thanks,
Matthew

[jamespetts]

Thank you very much both for the report and the fix! Out of interest, what are shadow variable names - are they two variables which perform similar functions and are members of different objects both having the same name

[neroden]

Thank you very much both for the report and the fix! Out of interest, what are shadow variable names - are they two variables which perform similar functions and are members of different objects both having the same name

Worse.  Variable name shadowing happens within a single function; it's a syntactical feature (bug?) of C and C++.  Write something like this:

Code Select Expand


foo_t pl = WHATEVER;
for (int i=0; i < 10; i++) {
  foo_t pl = SOMETHING_ELSE;
  pl.print_name(); // gets name of SOMETHING_ELSE
}
pl.print_name() // gets name of WHATEVER


The inner declaration of "pl" shadows the outer declaration, so that the outer variable is invisible while inside the brackets.  It gets very confusing very quickly.

The particular piece of code I was working on had, if I remember correctly, three shadowed variables, one of which was in fact "pl" -- each representing some aspect (plan_t, grund_t, gebaeude_t) of a particular square.  The variable defined *outside* the loop was the square where the halt was being deleted, while the variable *inside* the loop with the same name was the square currently being examined to see if it contained a factory.

What happened was that I didn't spot that one of the variables I used was not shadowed at the point of use, and I was grabbing the version defined outside the loop, when I wanted the version defined inside the loop. 

I changed the code so that all the variables declared inside the loop have different names from the ones declared outside the loop.  This makes it a lot easier to tell what's going on.

---
It may amuse you to know that shadowed variable names are one of the classic techniques used in the Obfusticated C Contest, whose goal is to make extremely unreadable programs.

[jamespetts]

Ohh, yes, that's awful. I only ever do that by accident.