bugFreeciv - Bugs: bug #20682, unit_virtual_destroy() assertion...

 
 
Show feedback again

bug #20682: unit_virtual_destroy() assertion '!unit_transported(punit)' failed (launching missile from sub to adjacent tile)

Submitted by:  Jacob Nevins <jtn>
Submitted on:  Fri 29 Mar 2013 02:56:43 PM UTC  
 
Category: generalSeverity: 3 - Normal
Priority: 5 - NormalStatus: Fixed
Assigned to: Marko Lindqvist <cazfi>Open/Closed: Closed
Release: S2_4 r22619Operating System: GNU/Linux
Planned Release: 2.4.0-beta2,2.5.0

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

Fri 19 Apr 2013 07:53:24 PM UTC, SVN revision 22730:

If unit dies attacking out, or is otherwise used directly from, transport,
unload it before destroying it. This fixes client side assert about unit
dying inside transport.

Reported by Jacob Nevins

See bug #20682

(Browse SVN revision 22730)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Fri 19 Apr 2013 07:53:17 PM UTC, SVN revision 22729:

If unit dies attacking out, or is otherwise used directly from, transport,
unload it before destroying it. This fixes client side assert about unit
dying inside transport.

Reported by Jacob Nevins

See bug #20682

(Browse SVN revision 22729)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Tue 16 Apr 2013 11:46:44 PM UTC, comment #7:

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)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Tue 16 Apr 2013 09:14:07 AM UTC, comment #6:

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.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Mon 15 Apr 2013 09:26:45 PM UTC, 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)

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Fri 12 Apr 2013 09:23:24 PM UTC, comment #4:

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.

Marko Lindqvist <cazfi>
Project AdministratorIn charge of this item.
Tue 02 Apr 2013 05:40:07 PM UTC, comment #3:

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


I checked, and it happens similar.

pepeto <pepeto>
Project Member
Fri 29 Mar 2013 03:31:37 PM UTC, comment #2:

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

Jacob Nevins <jtn>
Project Administrator
Fri 29 Mar 2013 02:57:56 PM UTC, comment #1:

(Unit ID 127 is the missile.)

Jacob Nevins <jtn>
Project Administrator
Fri 29 Mar 2013 02:56:43 PM UTC, original submission:

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

Last bit of -d3 log from the same client:

Jacob Nevins <jtn>
Project Administrator

 

(Note: upload size limit is set to 1024 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

Attached Files
file #17752:  UnloadDyingAttacker.patch added by cazfi (5kB - text/x-diff)
file #17591:  SubMissileAttack.sav.bz2 added by jtn (13kB - application/x-bzip)

 

Depends on the following items: None found

Digest:
   bug dependencies.

 

Carbon-Copy List
  • -unavailable- added by cazfi (Posted a comment)
  • -unavailable- added by pepeto (Posted a comment)
  • -unavailable- added by jtn (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 11 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 19 Apr 2013 07:53:37 PM UTCcazfiStatusReady For Test=>Fixed
      Assigned toNone=>cazfi
      Open/ClosedOpen=>Closed
    Tue 16 Apr 2013 11:46:44 PM UTCcazfiAttached File-=>Added UnitDeathInTransport.patch, #17755
    Mon 15 Apr 2013 09:26:45 PM UTCcazfiAttached File-=>Added UnloadDyingAttacker.patch, #17752
      Categoryclient=>general
      StatusNone=>Ready For Test
    Sun 07 Apr 2013 10:10:53 AM UTCjtnDependencies-=>bugs #20722 is dependent
    Sat 06 Apr 2013 11:43:51 PM UTCjtnPlanned Release2.4.0,2.5.0=>2.4.0-beta2,2.5.0
    Sat 06 Apr 2013 11:43:45 PM UTCjtnPlanned Release2.4.0=>2.4.0,2.5.0
    Fri 29 Mar 2013 02:56:43 PM UTCjtnAttached File-=>Added SubMissileAttack.sav.bz2, #17591
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup