Re: Segfault in side_material_production

[Lincoln Peters <sampln@sbcglobal.net>]

On Tue, 2003-11-11 at 16:24, Hans Ronne wrote:
> >While testing a new game module, I encountered a bug that I am sure was
> >introduced within the last few months (I'm not exactly how long ago it
> >could have come up, as I have not had time to work on it for a while).
> >Looking at the backtrace (see below), I suspect it has something to do
> >with the recent changes to the material display code, although I cannot
> >reproduce the bug in any of the games currently in the Xconq library.
> >
> >The GDB message is:
> >
> >Program received signal SIGSEGV, Segmentation fault.
> >0x08108369 in side_material_production (side=0x8459e18, m=0) at side.c:3742
> >3742                                    if (user_at(x, y) == unit->id) {
> 
> Thanks! The changes to the material code were massive and did not only
> involve the display, so I have been waiting for bugs to pop up. In fact, I
> just found one myself: the Civ2 game would hang after one or two turns due
> to an infinite while loop. I will check in a fix for that soon.
> 
> Looking at the code, I can see immediately what is wrong. This piece of
> advanced-unit code was taken verbatim from run_advanced_units to make
> Peter's material display work correctly with advanced untis. However,
> run_advanced_units also checks first that the user area layer exists and
> mallocs one if it does not. Unfortunately, this check did not make it to
> the new location. It illustrates the perils of cutting and pasting code
> from one place to another!
> 
> I will check in a fix for this as well later. If you want to test the fix
> right away, just put these lines at the start of side_material_production:
> 
> if (!user_defined()) {
>     allocate_area_users();
> }
> 
> and things should work fine.

And it does work fine.

> 
> Hans
> 
> P.S. I haven't forgotten about the game modules you sent me earlier. There
> were a number of bugs I had to fix, though, before I could finish the game
> modules overhaul. Is this one of these modules, and do you want to update
> it?

Yes, it's the "bolodd.g" module.  As before, it is playable but contains
some odd quirks.  One of them I am sure I could  fix if the change-type
function was implemented (so I wouldn't have to use a time.g-like
upgrade mechanism).  As I recall, the other problems are all
shortcomings in the AI code (I think you mentioned that the AI was
issuing "move" commands to bases).

I can't remember if I made any changes since then, so I'll check my
e-mail archives against the last time I modified any of those games and
get back to you.


By the way, if I can get this thing to work even half as well as I
envisioned it (you don't want to know all of the crazy ideas I had for
using the detonating units), this might qualify as one of the "biggest,
baddest ass projects" that Brandon was looking for.  "Space-civ.g" might
also qualify, but it's going to take even more work to make it playable
at all.