Complete.Org: Mailing Lists: Archives: freeciv-dev: August 2003:
[Freeciv-Dev] Re: (PR#4758) client crash on goto
Home

[Freeciv-Dev] Re: (PR#4758) client crash on goto

[Top] [All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index] [Thread Index]
To: jdorje@xxxxxxxxxxxxxxxxxxxxx
Subject: [Freeciv-Dev] Re: (PR#4758) client crash on goto
From: "Gregory Berkolaiko" <Gregory.Berkolaiko@xxxxxxxxxxxx>
Date: Wed, 6 Aug 2003 04:19:33 -0700
Reply-to: rt@xxxxxxxxxxxxxx

On Tue, 5 Aug 2003, Jason Short wrote:

> With the "return to nearest city" operation:
> 
> [1]+  Segmentation fault      (core dumped) ./civ

The problem here is that find_nearest_allied_city finds a city to which 
more rigourous client-goto cannot find a path.

The code itself is ridiculous, find_nearest_allied_city should return the 
path and not ask update_last_path to recompute everything from scratch.

It should, of course, use standard client-goto callbacks rather then 
simple_unit_path_iterate, which is called simple for a reason.

G.

> 
> #0  pft_concat (dest_path=0x8672c00, src_path=0x0) at pf_tools.c:398
> 398       dest_path->length = src_path->length;
> (gdb) bt
> #0  pft_concat (dest_path=0x8672c00, src_path=0x0) at pf_tools.c:398
> #1  0x0806dedc in send_goto_route (punit=0x8471a88) at goto.c:501
> #2  0x0806b17c in request_unit_return (punit=0x1) at control.c:671
> #3  0x401a5bb8 in gtk_item_factory_callback_marshal (widget=0x82b8fe0,
>      func_data=0x8672bf8) at gtkitemfactory.c:263
> 
> (gdb) select 1
> 
> (gdb) p goto_map.num_parts
> $2 = 1
> 
> (gdb) p goto_map.parts[0]
> $3 = {start_moves_left = 0, start_x = 25, start_y = 30, end_moves_left = 
> 101,
>    end_x = 25, end_y = 30, path = 0x0, map = 0x86807f0}
> 
> (gdb) p *goto_map.parts[0].map
> $5 = {x = 25, y = 30, index = 617, params = 0x8659cf0, queue = 0x8681f70,
>    lattice = 0x8692760, status = 0x8685a98 "", danger_queue = 0x0,
>    d_lattice = 0x0}
> 
> (gdb) p *punit
> $7 = {type = 4, id = 519, owner = 0, x = 25, y = 30, veteran = true,
>    homecity = 338, moves_left = 0, hp = 7, unhappiness = 0, upkeep = 0,
>    upkeep_food = 0, upkeep_gold = 0, foul = false, fuel = 0, bribe_cost 
> = 0,
>    ai = {control = false, ai_role = AIUNIT_NONE, ferryboat = 0, 
> passenger = 0,
>      bodyguard = 0, charge = 0}, activity = ACTIVITY_IDLE, goto_dest = 
> {x = 27,
>      y = 32}, activity_count = 0, activity_target = S_NO_SPECIAL,
>    focus_status = FOCUS_AVAIL, ord_map = 0, ord_city = 0, moved = false,
>    paradropped = false, connecting = false, transported_by = -1, pgr = 0x0
> 
> I've seen this before, but I don't know what causes it.  Why does the 
> goto_map 'part' have the same starting and ending position?
> 
> jason
> 
> 
> 
> 




[Prev in Thread] Current Thread [Next in Thread]