Segfault in side_material_production

Segfault in side_material_production

[Lincoln Peters]

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) {

And the backtrace says:

#0  0x08108369 in side_material_production (side=0x8459e18, m=0) at side.c:3742
        unit = (Unit *) 0x81c5d54
        x = 3
        y = 39
        production = 0
#1  0x0805173b in update_material_display () at tkmain.c:2524
        m = 0
        supply = 1300
        production = 134545874
        storage = -1073749432
#2  0x08050227 in update_side_display (side=0x8459e18, side2=0x81c5918,
    rightnow=1) at tkmain.c:2005
        m = 10
        sidebuf = "Independents", '\0' <repeats 16 times>, "2\r\a\n�_\001@", '\0' <repeats 16 times>, "�\v@@i\001@\217\177\000@�\001@\000\000\000\000_\001@�O�000@\224a\001@\001\000\000\000\001", '\0' <repeats 35 times>, " U\032\b\222\000\000\000\225\004\b�\v@ \001\000\000\004\000\000\00085\017@\b�p�000@8s\227\b�R\b*5\017@ \001\000\000\b��\006\b\213\233\b\204\t\200\003`\207\e\b\204\t\200\003�214\233\b8�Y\005\b�\026\b\001\000\000\000\001\000\000\000\000"...
        playerbuf = "-\000tion 0\000`\002@@ \000\000 $\023Bh#\023B)\000\000\000g\227\b\006\000\000\000-\000\000\000 #\023B\024\032\023B #\023Bh#\023B\210��\227\b\003\000\000\000\035\000\000\000 #\023B\024\032\023B #\023B\024\000\000\000---�\v6\aB #\023B\024\000\000\000�$\006B\000\000\000\000!\224\000@0�v@\225\004\b\024\032\023B\000\000\000\000\000\000\000\000�000\f@\214�v@\034\226\v@@i\001@\r\000\000\0005,@�\001@\224a\001@\225\004\b\200�s\200\000@\225\004\b2\r\a\n\\\217\004\bh�"...
#3  0x08051343 in init_redraws () at tkmain.c:2432
        u = 0
        side2 = (Side *) 0x81c5918
        map = (Map *) 0xbfffe278
#4  0x08056b9b in launch_game () at tkmain.c:4416
        player = (Player *) 0x18
#5  0x0804da2d in tk_launch_game (cldata=0x0, interp=0x81d01b0, argc=1,
    argv=0xbfffe2c0) at tkmain.c:1281
No locals.
#6  0x4004a78b in TclInvokeStringCommand () from /usr/lib/libtcl8.3.so
No symbol table info available.
#7  0x400675b5 in TclExecuteByteCode () from /usr/lib/libtcl8.3.so
No symbol table info available.
#8  0x4004b233 in Tcl_EvalObjEx () from /usr/lib/libtcl8.3.so
No symbol table info available.
#9  0x4008d6cb in TclObjInterpProc () from /usr/lib/libtcl8.3.so
No symbol table info available.
#10 0x400675b5 in TclExecuteByteCode () from /usr/lib/libtcl8.3.so
No symbol table info available.
#11 0x4004b233 in Tcl_EvalObjEx () from /usr/lib/libtcl8.3.so
No symbol table info available.
#12 0x4010bbe8 in TkInvokeButton () from /usr/lib/libtk8.3.so
No symbol table info available.
#13 0x4010af6f in Tk_RadiobuttonObjCmd () from /usr/lib/libtk8.3.so
No symbol table info available.
#14 0x40086517 in TclExpandTokenArray () from /usr/lib/libtcl8.3.so
No symbol table info available.
#15 0x40086638 in Tcl_EvalObjv () from /usr/lib/libtcl8.3.so
No symbol table info available.
#16 0x4004afd6 in Tcl_EvalObjEx () from /usr/lib/libtcl8.3.so
No symbol table info available.
#17 0x4008d075 in Tcl_UplevelObjCmd () from /usr/lib/libtcl8.3.so
No symbol table info available.
#18 0x400675b5 in TclExecuteByteCode () from /usr/lib/libtcl8.3.so
No symbol table info available.
#19 0x4004b233 in Tcl_EvalObjEx () from /usr/lib/libtcl8.3.so
No symbol table info available.
#20 0x4008d6cb in TclObjInterpProc () from /usr/lib/libtcl8.3.so
No symbol table info available.
#21 0x40086517 in TclExpandTokenArray () from /usr/lib/libtcl8.3.so
No symbol table info available.
#22 0x40086c02 in Tcl_EvalEx () from /usr/lib/libtcl8.3.so
No symbol table info available.
#23 0x40086f66 in Tcl_Eval () from /usr/lib/libtcl8.3.so
No symbol table info available.
#24 0x4004cae2 in Tcl_GlobalEval () from /usr/lib/libtcl8.3.so
No symbol table info available.
#25 0x400ce89f in Tk_BindEvent () from /usr/lib/libtk8.3.so
No symbol table info available.
#26 0x400d3e1f in TkBindEventProc () from /usr/lib/libtk8.3.so
No symbol table info available.
#27 0x400daaa5 in Tk_HandleEvent () from /usr/lib/libtk8.3.so
No symbol table info available.
#28 0x400dae7c in TkQueueEventForAllChildren () from /usr/lib/libtk8.3.so
No symbol table info available.
#29 0x4008400d in Tcl_ServiceEvent () from /usr/lib/libtcl8.3.so
No symbol table info available.
#30 0x4008426d in Tcl_DoOneEvent () from /usr/lib/libtcl8.3.so
No symbol table info available.
#31 0x0804fc6e in ui_mainloop () at tkmain.c:1866
No locals.
#32 0x0804aec3 in main (argc=1, argv=0xbffff884) at tkunix.c:126
No locals.
#33 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
No symbol table info available.

Re: Segfault in side_material_production

[Hans Ronne]

>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.

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?

Re: Segfault in side_material_production

[Lincoln Peters]

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.