[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-19 Thread Marko Lindqvist 
Update of bug #20682 (project freeciv):

  Status:  Ready For Test => Fixed  
 Assigned to:None => cazfi  
 Open/Closed:Open => Closed 


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-16 Thread Marko Lindqvist 
Follow-up Comment #7, bug #20682 (project freeciv):

Caravan & Diplomat cases tested and found to spit out the same assert. They,
however, are not made visible to everyone like battling units are. It would
also be rare situation where their action would cause themselves to get fogged
on some player's client. Thus the wipe_unit() unloading of wiped transported
units (that should be added anyway) handled them in my tests

I didn't try to setup situation where C seeing diplomat inside transport of A
through shared vision from B would lose the vision when diplomat bribes unit
or incites revolt in a city.

(file #17755)
___

Additional Item Attachment:

File name: UnitDeathInTransport.patch Size:5 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-16 Thread Marko Lindqvist 
Follow-up Comment #6, bug #20682 (project freeciv):

For the record: I tested version where simply wipe_unit() always unloaded
units being wiped if they are currently inside transport. That might still be
a good idea, but it didn't stop all the asserts here - I suspect that it's
because defender gets killed first losing vision and thus missile gets fogged
already before it's getting wiped.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-15 Thread Marko Lindqvist 
Update of bug #20682 (project freeciv):

Category:  client => general
  Status:None => Ready For Test 

___

Follow-up Comment #5:

Attached patch causes attacker to be unloaded if it's going to die.

I have not investigated if non-combat "using" of unit directly from transport
causes similar problems - diplomats and caravans may need fixing too.

(file #17752)
___

Additional Item Attachment:

File name: UnloadDyingAttacker.patch  Size:4 KB


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-12 Thread Marko Lindqvist 
Follow-up Comment #4, bug #20682 (project freeciv):

I don't think it's possible to simply unload the unit before it attacks. Or at
least it should be loaded back if it wins the battle and does not move
(occupychance). Otherwise we would have aircrafts easily left behind carriers
and even Marines on Ocean tiles.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-06 Thread Jacob Nevins 
Update of bug #20682 (project freeciv):

 Planned Release: 2.4.0,2.5.0 => 2.4.0-beta2,2.5.0  


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-06 Thread Jacob Nevins 
Update of bug #20682 (project freeciv):

 Planned Release:   2.4.0 => 2.4.0,2.5.0


___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-04-02 Thread pepeto 
Follow-up Comment #3, bug #20682 (project freeciv):

> Haven't checked if something similar happens with Marines.

I checked, and it happens similar.


___

Reply to this item at:

  

___
  Message posté via/par Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-03-29 Thread Jacob Nevins 
Follow-up Comment #2, bug #20682 (project freeciv):

Don't see this with 2.4.0-beta1, I think because bug #20085 was fixed since
then.

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-03-29 Thread Jacob Nevins 
Follow-up Comment #1, bug #20682 (project freeciv):

(Unit ID 127 is the missile.)

___

Reply to this item at:

  

___
  Message sent via/by Gna!
  http://gna.org/


___
Freeciv-dev mailing list
Freeciv-dev@gna.org
https://mail.gna.org/listinfo/freeciv-dev

[Freeciv-Dev] [bug #20682] unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

2013-03-29 Thread Jacob Nevins 
URL:
  

 Summary: unit_virtual_destroy() assertion
'!unit_transported(punit)' failed (launching missile from sub to adjacent
tile)
 Project: Freeciv
Submitted by: jtn
Submitted on: Fri Mar 29 14:56:43 2013
Category: client
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Assigned to: None
Originator Email: 
 Open/Closed: Open
 Release: S2_4 r22619
 Discussion Lock: Any
Operating System: GNU/Linux
 Planned Release: 2.4.0

___

Details:

Found a reproducible assertion failure on S2_4: with a submarine carrying a
missile adjacent to to enemy units on the coast, move the missile to the units
(i.e. attack). Both attacker and defender clients hit this assertion failure.

I assume the problem is that the previously invisible missile unit becomes
visible only to be destroyed, and that the transported status at the client
ends up not what we want.

I suspect this isn't related to bug #20542.

Haven't checked if something similar happens with Marines.

Backtrace from one of the clients (with -F):


#0  0x7f9aa8ac87bb in raise (sig=)
at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42
No locals.
#1  0x005cd9cc in fc_assert_fail (file=0x65a209 "unit.c", 
function=0x65acc0 "unit_virtual_destroy", line=1718, 
assertion=, message=0x65bec0 "nologmsg:%s")
at log.c:520
level = LOG_FATAL
#2  0x005c74fd in unit_virtual_destroy (punit=0x7bb53a0) at
unit.c:1718
__FUNCTION__ = "unit_virtual_destroy"
#3  0x0045e240 in client_remove_unit (punit=0x7bb53a0) at
climisc.c:96
pcity = 
ptile = 0x3c3d0a0
hc = 0
old_unit = {utype = 0x9dc270, tile = 0x3c3d0a0, 
  facing = DIR8_SOUTHEAST, owner = 0x3aded80, id = 127, homecity = 0,

  upkeep = {0, 0, 0, 0, 0, 0}, moves_left = 36, hp = 10, veteran = 1,

  fuel = 1, goto_tile = 0x0, activity = ACTIVITY_IDLE, 
  activity_count = 0, activity_target = S_LAST, activity_base = -1, 
  changed_from = ACTIVITY_IDLE, changed_from_count = 0, 
  changed_from_target = S_ROAD, changed_from_base = 0, 
  ai_controlled = false, moved = false, paradropped = false, 
  done_moving = false, transporter = 0x7bb98f0, 
  transporting = 0x3c25eb0, battlegroup = -1, has_orders = false, 
  orders = {length = 0, index = 0, repeat = false, vigilant = false, 
list = 0x0}, {client = {focus_status = FOCUS_AVAIL, 
  transported_by = 126, occupied = false, colored = false, 
  color_index = 0, asking_city_name = false}, server = {
  debug = false, adv = 0x0, ais = {0x0, 0x0, 0x0}, birth_turn = 0,

  ord_map = 0, ord_city = 0, vision = 0x0, action_timestamp = 0, 
  action_turn = 0}}}
old = 1
__FUNCTION__ = "client_remove_unit"
#4  0x00487de0 in client_handle_packet (type=, 
packet=0x0) at packhand_gen.c:150
No locals.
#5  0x004592fe in client_packet_input (packet=, 
type=64) at client_main.c:654
__FUNCTION__ = "client_packet_input"
#6  0x0045f7a5 in input_from_server (fd=)
at clinet.c:421
result = true
packet = 0x0
type = PACKET_UNIT_SHORT_INFO
nb = 
__FUNCTION__ = "input_from_server"
#7  0x0044e7e0 in get_net_input (source=, 
condition=, data=)
at gui_main.c:1882
No locals.
#8  0x7f9aa28a19d2 in g_main_context_dispatch () from
/lib/libglib-2.0.so.0
No symbol table info available.
#9  0x7f9aa28a5858 in ?? () from /lib/libglib-2.0.so.0
No symbol table info available.
#10 0x7f9aa28a5d65 in g_main_loop_run () from /lib/libglib-2.0.so.0
No symbol table info available.
#11 0x7f9aa4e48bc7 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0
No symbol table info available.
#12 0x00451ce9 in ui_main (argc=1, argv=0x7fffca56a428)
at gui_main.c:1673
home = 
sig = 
__FUNCTION__ = "ui_main"
#13 0x004597e3 in client_main (argc=, 
argv=0x7fffca56a428) at client_main.c:590
i = 9
loglevel = LOG_VERBOSE
ui_options = 
ui_separator = 128
option = 
user_tileset = false
fatal_assertions = 6
__FUNCTION__ = "client_main"
#14 0x7f9aa696fc4d in __libc_start_main (main=, 
argc=, ubp_av=, 
init=, fini=, 
rtld_fini=, stack_end=0x7fffca56a418)
at libc-start.c:226
result = 
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, 5730541663988160977, 
4513376, 140736588063776, 0, 0, -5730428219023746607, 
-5714025152484271663}, mask_was_saved = 0}}, priv = {pad = {
  0x0, 0x0, 0x60d4c0, 0x7fffca56a428}, data = {prev = 0x0,