Update of bug #16100 (project freeciv):
Severity: 3 - Normal = 4 - Important
Priority: 1 - Later = 5 - Normal
Status:None = Fixed
Assigned to:
Update of bug #16100 (project freeciv):
Status: Fixed = Duplicate
___
Reply to this item at:
http://gna.org/bugs/?16100
___
Message sent
Follow-up Comment #11, bug #16100 (project freeciv):
When I commit the fix for bug #16418 I'll close this as duplicate, unless
there are objections -- the cause fits the symptoms. (I'll sort out the
function name separately.)
___
Reply to
Follow-up Comment #10, bug #16100 (project freeciv):
I suspect bug #16418 is the same issue as this, and there's a reproduction
case there. I'll look into that.
___
Reply to this item at:
http://gna.org/bugs/?16100
Follow-up Comment #9, bug #16100 (project freeciv):
Perhaps unit_assign_specific_activity_target(), then?
What of the bug, though? It would be good to track it down for 2.2.2, but I
don't have any idea how the bad data got in there. Were these servers
running the default ruleset? Could they
Follow-up Comment #8, bug #16100 (project freeciv):
Perhaps unit_activity_assign_goal()?
Maybe. Though I believe words target and goal are not usually
interchangeable in Freeciv codebase, but they are used as long term *goal*
(several steps) and immediate *target* (next step).
Follow-up Comment #7, bug #16100 (project freeciv):
Assuming Ulrik's analysis is correct (and I see no reason to doubt it on the
current evidence), it looks like the ACTIVITY_PILLAGE/S_LAST/BASE_NONE
combination has somehow made it into the server's data structures, which
shouldn't now happen. I
Follow-up Comment #3, bug #16100 (project freeciv):
Looking the code there seems to be at least one problem in what happens if
client requests pillage when there is nothing to pillage (client out-of-sync
or client modified to crash server on purpose)
unit_activity_handling_targeted() calls
Follow-up Comment #4, bug #16100 (project freeciv):
Shouldn't unit_activity_assign_target() return boolean instead
of void to tell if it was successful or not?
unit_activity_handling_targeted() could use that information to
decide if it should continue setting activity or not.
Also, I
Follow-up Comment #5, bug #16100 (project freeciv):
unit_activity_handling_targeted() calls
unit_activity_assign_target(), which sets *activity to
ACTIVITY_IDLE if there's nothing to pillage. But then
unit_activity_handling_targeted() continues by calling
set_unit_activity_targeted() to set
Follow-up Comment #6, bug #16100 (project freeciv):
This all sounds like it's tied up with my big pillage rework (bug #15744 et
al), so I should have an opinion. However, I won't be able to look at it
before next week at the earliest, so feel free to have a go fixing it and
I'll look when I'm
URL:
http://gna.org/bugs/?16100
Summary: Crash in territory_claiming_base()
Project: Freeciv
Submitted by: cazfi
Submitted on: Tuesday 06/01/2010 at 12:08
Category: None
Severity: 3 - Normal
Follow-up Comment #1, bug #16100 (project freeciv):
Given the crash site, the passed pbase must be NULL. If you compile with
debug assertions turned on, do you instead hit the following assertion?
assert(punit-activity_base != BASE_NONE);
server/unittools.c : 719
Follow-up Comment #2, bug #16100 (project freeciv):
If you compile with debug assertions turned on, do you instead
hit the following assertion?
assert(punit-activity_base != BASE_NONE);
I'm not going to turn assertions on on non-beta public servers, but as soon
as I have some spare time,
14 matches
Mail list logo
