This is the mail archive of the
xconq7@sources.redhat.com
mailing list for the Xconq project.
Re: Segfault in side_material_production
- From: Lincoln Peters <sampln at sbcglobal dot net>
- To: Hans Ronne <hronne at comhem dot se>
- Cc: Xconq list <xconq7 at sources dot redhat dot com>
- Date: Tue, 11 Nov 2003 16:59:30 -0800
- Subject: Re: Segfault in side_material_production
- References: <l03130301bbd7253ded1f@[212.181.162.155]>
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.