Loading ...
Sorry, an error occurred while loading the content.

Re: [atlantisdev] Release 4.1.0

Expand Messages
  • Alex Loudeo
    Hi Loria! Wednesday, August 20, 2008, 5:20:11 PM, you wrote: L I did setup a testgame running the current release (4.1.0) L for testing purposes. If you
    Message 1 of 17 , Sep 1, 2008
    • 0 Attachment
      Hi Loria!

      Wednesday, August 20, 2008, 5:20:11 PM, you wrote:
      L> I did setup a testgame running the current release (4.1.0)
      L> for testing purposes. If you want to participate in testing,
      L> just let me know. I will then send you the information needed
      L> to participate in the testgame.

      I want !
    • Arno Saxena
      I had a crash today in 4.1.0 Game::RunGame Game::WriteReport Faction::WriteReport ARegion::WriteReport Aregion::GetObservation Unit::GetSkill
      Message 2 of 17 , Feb 22, 2009
      • 0 Attachment
        I had a crash today in 4.1.0

        Game::RunGame
        Game::WriteReport
        Faction::WriteReport
        ARegion::WriteReport
        Aregion::GetObservation
        Unit::GetSkill
        Unit::GetObservation
        Unit::GetRealSkill
        Unit::GetMen

        while writing the reports in
        int Unit::GetMen()
        unit.cpp 751

        I received the signal EXC_BAD_ACCESS

        debuging has given me no more insight into the problem...
        looks like the crash occured while executing the if:

        if (ItemDefs[i->type].type & IT_MAN) {

        (line 756)

        I have absolutely no Idea how to solve this :(

        does anybody have stumbled upon this bug too?
        does anybody know how to solve this?

        greetings
        Arno

        Loriaki wrote:
        > Hi,
        >


        >
        > This is mainly a maintanance release. Also the prediction
        > of it beeing stable (Therefore the version has been turned
        > to 4.1.0 which won't render itself as beta anymore)
        > Mainly the last release (4.0.10k) of JT Traub which was placed
        > to the filespace of the atlantisdev yahoo groups has been compared
        > to the state of the SVN Repository on Sourceforge which discoverd
        > a few changes. See the CHANGELOG file.
        >
        > You may get the Relase from either yahoogroups
        > http://groups.yahoo.com/group/atlantisdev/files/Sources/
        > (you have to be signed in to yahoo to access the Filespace
        >
        > or Sourceforge:
        > http://atlantis.sourceforge.net/
        > (Files have been released to the Download space.)
        > You also may use svn to access the source:
        > svn co https://atlantis.svn.sourceforge.net/svnroot/atlantis/RELEASE_4_1_0 atlantis-4.1.0
        >
        > Work for Atlantis 4 (if needed, will be done to PATCHES_410 branch:
        > https://atlantis.svn.sourceforge.net/svnroot/atlantis/branches/PATCHES_410
        > (So if you want to keep your checked out version of Atlantis 4 current,
        > take this one)
        >
        > Feel free to submit reports to the bugtracker at SourceForge.
        >
        >
        > Loria
        >
      • Loriaki
        ... I still have no crash ... the testgame is now running 3/4 of a year ( 1/2 of it 3 turn/week, now 2/week) which setup (standard ?) are you using ? (I don t
        Message 3 of 17 , Feb 22, 2009
        • 0 Attachment
          On Mon, Feb 23, 2009 at 12:07:01AM +0100, Arno Saxena wrote:
          > I had a crash today in 4.1.0
          >
          > Game::RunGame
          > Game::WriteReport
          > Faction::WriteReport
          > ARegion::WriteReport
          > Aregion::GetObservation
          > Unit::GetSkill
          > Unit::GetObservation
          > Unit::GetRealSkill
          > Unit::GetMen
          >
          > while writing the reports in
          > int Unit::GetMen()
          > unit.cpp 751
          >
          > I received the signal EXC_BAD_ACCESS
          >
          > debuging has given me no more insight into the problem...
          > looks like the crash occured while executing the if:
          >
          > if (ItemDefs[i->type].type & IT_MAN) {
          >
          > (line 756)
          >
          > I have absolutely no Idea how to solve this :(
          >
          > does anybody have stumbled upon this bug too?
          > does anybody know how to solve this?
          >
          > greetings
          > Arno

          I still have no crash ... the testgame is now
          running 3/4 of a year ( 1/2 of it 3 turn/week, now 2/week)
          which setup (standard ?) are you using ?
          (I don't know if it is possible to test the game.in, players.in and
          order files on a different machine ?)


          Loria

          >
          > Loriaki wrote:
          > > Hi,
          > >
          >
          >
          > >
          > > This is mainly a maintanance release. Also the prediction
          > > of it beeing stable (Therefore the version has been turned
          > > to 4.1.0 which won't render itself as beta anymore)
          > > Mainly the last release (4.0.10k) of JT Traub which was placed
          > > to the filespace of the atlantisdev yahoo groups has been compared
          > > to the state of the SVN Repository on Sourceforge which discoverd
          > > a few changes. See the CHANGELOG file.
          > >
          > > You may get the Relase from either yahoogroups
          > > http://groups.yahoo.com/group/atlantisdev/files/Sources/
          > > (you have to be signed in to yahoo to access the Filespace
          > >
          > > or Sourceforge:
          > > http://atlantis.sourceforge.net/
          > > (Files have been released to the Download space.)
          > > You also may use svn to access the source:
          > > svn co https://atlantis.svn.sourceforge.net/svnroot/atlantis/RELEASE_4_1_0 atlantis-4.1.0
          > >
          > > Work for Atlantis 4 (if needed, will be done to PATCHES_410 branch:
          > > https://atlantis.svn.sourceforge.net/svnroot/atlantis/branches/PATCHES_410
          > > (So if you want to keep your checked out version of Atlantis 4 current,
          > > take this one)
          > >
          > > Feel free to submit reports to the bugtracker at SourceForge.
          > >
          > >
          > > Loria
          > >
          >
          >
          >
          > ------------------------------------
          >
          > To Post a message, send it to: atlantisdev@...
          > To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups Links
          >
          >
          >
        • Max Shariy
          Just a suggestion: Can it be caused by corrupted game.in file? Can you add logging to Unit::GetMen() so you will know the offending unit id (and id of the unit
          Message 4 of 17 , Feb 22, 2009
          • 0 Attachment
            Just a suggestion:
            Can it be caused by corrupted game.in file?
            Can you add logging to Unit::GetMen() so you will know the offending unit id
            (and id of the unit before it) and check game.in?

            Max

            On Sunday 22 February 2009 15:07:01 Arno Saxena wrote:
            >I had a crash today in 4.1.0
            >
            >Game::RunGame
            >Game::WriteReport
            >Faction::WriteReport
            >ARegion::WriteReport
            >Aregion::GetObservation
            >Unit::GetSkill
            >Unit::GetObservation
            >Unit::GetRealSkill
            >Unit::GetMen
            >
            >while writing the reports in
            >int Unit::GetMen()
            >unit.cpp 751
            >
            >I received the signal EXC_BAD_ACCESS
            >
            >debuging has given me no more insight into the problem...
            >looks like the crash occured while executing the if:
            >
            >if (ItemDefs[i->type].type & IT_MAN) {
            >
            >(line 756)
            >
            >I have absolutely no Idea how to solve this :(
            >
            >does anybody have stumbled upon this bug too?
            >does anybody know how to solve this?
            >
            >greetings
            > Arno
            >
            >Loriaki wrote:
            >> Hi,
            >>
            >>
            >>
            >>
            >> This is mainly a maintanance release. Also the prediction
            >> of it beeing stable (Therefore the version has been turned
            >> to 4.1.0 which won't render itself as beta anymore)
            >> Mainly the last release (4.0.10k) of JT Traub which was placed
            >> to the filespace of the atlantisdev yahoo groups has been compared
            >> to the state of the SVN Repository on Sourceforge which discoverd
            >> a few changes. See the CHANGELOG file.
            >>
            >> You may get the Relase from either yahoogroups
            >> http://groups.yahoo.com/group/atlantisdev/files/Sources/
            >> (you have to be signed in to yahoo to access the Filespace
            >>
            >> or Sourceforge:
            >> http://atlantis.sourceforge.net/
            >> (Files have been released to the Download space.)
            >> You also may use svn to access the source:
            >> svn co https://atlantis.svn.sourceforge.net/svnroot/atlantis/RELEASE_4_1_0
            >> atlantis-4.1.0
            >>
            >> Work for Atlantis 4 (if needed, will be done to PATCHES_410 branch:
            >> https://atlantis.svn.sourceforge.net/svnroot/atlantis/branches/PATCHES_410
            >> (So if you want to keep your checked out version of Atlantis 4 current,
            >> take this one)
            >>
            >> Feel free to submit reports to the bugtracker at SourceForge.
            >>
            >>
            >> Loria
            >
            >------------------------------------
            >
            >To Post a message, send it to: atlantisdev@...
            >To Unsubscribe, send a blank message to:
            > atlantisdev-unsubscribe@...! Groups Links
            >
            >
            >
          • bioboobies
            Check that the gamedata.cpp itemsdef[] matches exactly the definitions in gamedata.h. I had issues when changing this and there were more items in gamedata.cpp
            Message 5 of 17 , Feb 22, 2009
            • 0 Attachment
              Check that the gamedata.cpp itemsdef[] matches exactly the definitions
              in gamedata.h.

              I had issues when changing this and there were more items in
              gamedata.cpp than gamedefs.h - you can end up being in a spot of
              bother with trying to compare random crap in memory.

              It is a laborious task, but if you need to fix it, then do so.
              Alternatively, send me you game.in, game files and the orders, and I
              can have a go at fixing it for you, by running on a linux box.

              The EXC_BAD_ACCESS is a Mac only error, right?

              d

              --- In atlantisdev@yahoogroups.com, Max Shariy <mshariy@...> wrote:
              >
              > Just a suggestion:
              > Can it be caused by corrupted game.in file?
              > Can you add logging to Unit::GetMen() so you will know the offending
              unit id
              > (and id of the unit before it) and check game.in?
              >
              > Max
              >
              > On Sunday 22 February 2009 15:07:01 Arno Saxena wrote:
              > >I had a crash today in 4.1.0
              > >
              > >Game::RunGame
              > >Game::WriteReport
              > >Faction::WriteReport
              > >ARegion::WriteReport
              > >Aregion::GetObservation
              > >Unit::GetSkill
              > >Unit::GetObservation
              > >Unit::GetRealSkill
              > >Unit::GetMen
              > >
              > >while writing the reports in
              > >int Unit::GetMen()
              > >unit.cpp 751
              > >
              > >I received the signal EXC_BAD_ACCESS
              > >
              > >debuging has given me no more insight into the problem...
              > >looks like the crash occured while executing the if:
              > >
              > >if (ItemDefs[i->type].type & IT_MAN) {
              > >
              > >(line 756)
              > >
              > >I have absolutely no Idea how to solve this :(
              > >
              > >does anybody have stumbled upon this bug too?
              > >does anybody know how to solve this?
              > >
              > >greetings
              > > Arno
              > >
              > >Loriaki wrote:
              > >> Hi,
              > >>
              > >>
              > >>
              > >>
              > >> This is mainly a maintanance release. Also the prediction
              > >> of it beeing stable (Therefore the version has been turned
              > >> to 4.1.0 which won't render itself as beta anymore)
              > >> Mainly the last release (4.0.10k) of JT Traub which was placed
              > >> to the filespace of the atlantisdev yahoo groups has been compared
              > >> to the state of the SVN Repository on Sourceforge which discoverd
              > >> a few changes. See the CHANGELOG file.
              > >>
              > >> You may get the Relase from either yahoogroups
              > >> http://groups.yahoo.com/group/atlantisdev/files/Sources/
              > >> (you have to be signed in to yahoo to access the Filespace
              > >>
              > >> or Sourceforge:
              > >> http://atlantis.sourceforge.net/
              > >> (Files have been released to the Download space.)
              > >> You also may use svn to access the source:
              > >> svn co
              https://atlantis.svn.sourceforge.net/svnroot/atlantis/RELEASE_4_1_0
              > >> atlantis-4.1.0
              > >>
              > >> Work for Atlantis 4 (if needed, will be done to PATCHES_410 branch:
              > >>
              https://atlantis.svn.sourceforge.net/svnroot/atlantis/branches/PATCHES_410
              > >> (So if you want to keep your checked out version of Atlantis 4
              current,
              > >> take this one)
              > >>
              > >> Feel free to submit reports to the bugtracker at SourceForge.
              > >>
              > >>
              > >> Loria
              > >
              > >------------------------------------
              > >
              > >To Post a message, send it to: atlantisdev@...
              > >To Unsubscribe, send a blank message to:
              > > atlantisdev-unsubscribe@...! Groups Links
              > >
              > >
              > >
              >
            • Arno Saxena
              Oh dear, I think I have found the problem ... a mage unit has cast farsight. Also the same mage has been lost in combat. Thus the farsight at time of writing
              Message 6 of 17 , Feb 23, 2009
              • 0 Attachment
                Oh dear, I think I have found the problem ...

                a mage unit has cast farsight. Also the same mage has been lost in
                combat. Thus the farsight at time of writing the report is based on a
                non-existing unit ... pretty specific error, I have no doubt Loria has
                run a game very long without being hit by this bug :)

                I don't have given any thought to a solution, just have found this out
                right this minute ... so any idea would be appreciated!

                yes, EXC_BAD_ACCESS is a Mac error, but normally I do run the turn on a
                Linux box (debian lenny), but the debugging I'm doing on a Mac with
                xcode. The error has occurred on the Linux version first and after that
                on the mac version too...

                As for the bug itself, I'm not exactly sure which access exactly has
                caused the crash, I'll try to reproduce the bug with a minimal test game
                and an also minimal set of orders, so I can debug it better and let you
                know what is going on ...

                greetings
                Arno
              • Loriaki
                ... I think there have not been very much large combats on the testgame. ... So this is a bad bug. ... Standard Unix: SEGFAULT
                Message 7 of 17 , Feb 23, 2009
                • 0 Attachment
                  On Mon, Feb 23, 2009 at 09:32:49PM +0100, Arno Saxena wrote:
                  > Oh dear, I think I have found the problem ...
                  >
                  > a mage unit has cast farsight. Also the same mage has been lost in
                  > combat. Thus the farsight at time of writing the report is based on a
                  > non-existing unit ... pretty specific error, I have no doubt Loria has
                  > run a game very long without being hit by this bug :)

                  I think there have not been very much large combats on the testgame.

                  > I don't have given any thought to a solution, just have found this out
                  > right this minute ... so any idea would be appreciated!

                  So this is a bad bug.

                  > yes, EXC_BAD_ACCESS is a Mac error, but normally I do run the turn on a
                  > Linux box (debian lenny), but the debugging I'm doing on a Mac with
                  > xcode. The error has occurred on the Linux version first and after that
                  > on the mac version too...

                  Standard Unix: SEGFAULT

                  > As for the bug itself, I'm not exactly sure which access exactly has
                  > caused the crash, I'll try to reproduce the bug with a minimal test game
                  > and an also minimal set of orders, so I can debug it better and let you
                  > know what is going on ...
                  >
                  > greetings
                  > Arno
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  >
                  > ------------------------------------
                  >
                  > To Post a message, send it to: atlantisdev@...
                  > To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups Links
                  >
                  >
                  >
                • Loriaki
                  (Sorry, I hit the wrong key) (i wanted to postpone it instead sending it)
                  Message 8 of 17 , Feb 23, 2009
                  • 0 Attachment
                    (Sorry, I hit the wrong key)
                    (i wanted to postpone it instead sending it)

                    On Mon, Feb 23, 2009 at 09:36:14PM +0100, Loriaki wrote:
                    > On Mon, Feb 23, 2009 at 09:32:49PM +0100, Arno Saxena wrote:
                    > > Oh dear, I think I have found the problem ...
                    > >
                    > > a mage unit has cast farsight. Also the same mage has been lost in
                    > > combat. Thus the farsight at time of writing the report is based on a
                    > > non-existing unit ... pretty specific error, I have no doubt Loria has
                    > > run a game very long without being hit by this bug :)
                    >
                    > I think there have not been very much large combats on the testgame.
                    >
                    > > I don't have given any thought to a solution, just have found this out
                    > > right this minute ... so any idea would be appreciated!
                    >
                    > So this is a bad bug.
                    >
                    > > yes, EXC_BAD_ACCESS is a Mac error, but normally I do run the turn on a
                    > > Linux box (debian lenny), but the debugging I'm doing on a Mac with
                    > > xcode. The error has occurred on the Linux version first and after that
                    > > on the mac version too...
                    >
                    > Standard Unix: SEGFAULT
                    >
                    > > As for the bug itself, I'm not exactly sure which access exactly has
                    > > caused the crash, I'll try to reproduce the bug with a minimal test game
                    > > and an also minimal set of orders, so I can debug it better and let you
                    > > know what is going on ...
                    > >
                    > > greetings
                    > > Arno
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > >
                    > > ------------------------------------
                    > >
                    > > To Post a message, send it to: atlantisdev@...
                    > > To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups Links
                    > >
                    > >
                    > >
                    >
                    >
                    > ------------------------------------
                    >
                    > To Post a message, send it to: atlantisdev@...
                    > To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups Links
                    >
                    >
                    >
                  • Loriaki
                    ... could you check if the unit has already been destructed ... ? and its operating on an stray reference ? Otherwise the foreach(&Items) will use stray
                    Message 9 of 17 , Feb 23, 2009
                    • 0 Attachment
                      On Mon, Feb 23, 2009 at 09:32:49PM +0100, Arno Saxena wrote:
                      > Oh dear, I think I have found the problem ...
                      >
                      > a mage unit has cast farsight. Also the same mage has been lost in
                      > combat. Thus the farsight at time of writing the report is based on a
                      > non-existing unit ... pretty specific error, I

                      could you check if the unit has already been destructed ... ? and its
                      operating on an stray reference ?
                      Otherwise the foreach(&Items) will use stray pointers.
                      ======= is a macro ... which dereferences pointers
                      if this is so, the unit needs to either destucted later ( or never ;) )
                      or needs to be cleanly removed from all lists, which might be ugly work,
                      Since AList is not nice.

                      > have no doubt Loria has
                      > run a game very long without being hit by this bug :)

                      seems so ... at least I stil have no crash ... but it will happen one day..

                      > I don't have given any thought to a solution, just have found this out
                      > right this minute ... so any idea would be appreciated!
                      >
                      > yes, EXC_BAD_ACCESS is a Mac error, but normally I do run the turn on a
                      > Linux box (debian lenny), but the debugging I'm doing on a Mac with
                      > xcode. The error has occurred on the Linux version first and after that
                      > on the mac version too...
                      >
                      > As for the bug itself, I'm not exactly sure which access exactly has
                      > caused the crash, I'll try to reproduce the bug with a minimal test game
                      > and an also minimal set of orders, so I can debug it better and let you
                      > know what is going on ...
                      >
                      > greetings
                      > Arno
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      >
                      > ------------------------------------
                      >
                      > To Post a message, send it to: atlantisdev@...
                      > To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups Links
                      >
                      >
                      >
                    • Arno Saxena
                      Ok, I ve just constructed a little testgame with a mage casting farsight and attacking city guards ... without a problem ... It looks like I cannot reconstruct
                      Message 10 of 17 , Feb 23, 2009
                      • 0 Attachment
                        Ok, I've just constructed a little testgame with a mage casting farsight
                        and attacking city guards ... without a problem ... It looks like I
                        cannot reconstruct the bug??!!

                        But still the farsight order in the actual game causes the crash. I have
                        commented out the farsight command and thus avoided the crash. I
                        commented the farsight command in again and gave the mage a amulet of
                        invulnerability thus have him survive the battles (just switching of the
                        attack command did not help, since there had been a battle between
                        multiple factions and after finding a few of their attack commands
                        without stopping the battle I added the xxxx item :) )

                        Anyway, with a surviving mage the game run has also survived and a
                        correct output has been generated ...

                        This tells me there is more to it than only a killed mage, but it must
                        be the key to the problem ...

                        btw, the debug reached

                        AListElem * AList::Next(AListElem * e)
                        {
                        if (!e) return 0;
                        return e->next;
                        }

                        in alist.cpp before stoping the run with the known error ...


                        Arno


                        Loriaki wrote:
                        > On Mon, Feb 23, 2009 at 09:32:49PM +0100, Arno Saxena wrote:
                        >> Oh dear, I think I have found the problem ...
                        >>
                        >> a mage unit has cast farsight. Also the same mage has been lost in
                        >> combat. Thus the farsight at time of writing the report is based on a
                        >> non-existing unit ... pretty specific error, I
                        >
                        > could you check if the unit has already been destructed ... ? and its
                        > operating on an stray reference ?
                        > Otherwise the foreach(&Items) will use stray pointers.
                        > ======= is a macro ... which dereferences pointers
                        > if this is so, the unit needs to either destucted later ( or never ;) )
                        > or needs to be cleanly removed from all lists, which might be ugly work,
                        > Since AList is not nice.
                        >
                        >> have no doubt Loria has
                        >> run a game very long without being hit by this bug :)
                        >
                        > seems so ... at least I stil have no crash ... but it will happen one day..
                        >
                        >> I don't have given any thought to a solution, just have found this out
                        >> right this minute ... so any idea would be appreciated!
                        >>
                        >> yes, EXC_BAD_ACCESS is a Mac error, but normally I do run the turn on a
                        >> Linux box (debian lenny), but the debugging I'm doing on a Mac with
                        >> xcode. The error has occurred on the Linux version first and after that
                        >> on the mac version too...
                        >>
                        >> As for the bug itself, I'm not exactly sure which access exactly has
                        >> caused the crash, I'll try to reproduce the bug with a minimal test game
                        >> and an also minimal set of orders, so I can debug it better and let you
                        >> know what is going on ...
                        >>
                        >> greetings
                        >> Arno
                        >>
                        >>
                        >>
                        >>
                        >>
                        >>
                        >>
                        >>
                        >> ------------------------------------
                        >>
                        >> To Post a message, send it to: atlantisdev@...
                        >> To Unsubscribe, send a blank message to: atlantisdev-unsubscribe@...! Groups Links
                        >>
                        >>
                        >>
                        >
                      • Enno Rehling
                        If this is caused by operating on a unit that s already deleted: don t delete the units until the end of the turn. It s not going to cause any trouble. What I
                        Message 11 of 17 , Feb 23, 2009
                        • 0 Attachment
                          If this is caused by operating on a unit that's already deleted: don't
                          delete the units until the end of the turn. It's not going to cause any
                          trouble.

                          What I do in Eressea is that I have a graveyard list of all the dead
                          units, that way I can still have them in reports at the end in case they
                          were part of some espionage-report or spell or you-name-it. Just don't
                          delete the unit, put it on the graveyard list, then delete it after
                          you're all done with the turn (if you feel that you must clean up).

                          Enno.
                        • Max Shariy
                          Here is the failing code: if (ItemDefs[i- type].type & IT_MAN) If you have a stray pointer to memory which was released, sometimes you can dereference the
                          Message 12 of 17 , Feb 23, 2009
                          • 0 Attachment
                            Here is the failing code:
                            if (ItemDefs[i->type].type & IT_MAN)

                            If you have a stray pointer to memory which was released, sometimes you can
                            dereference the pointer because the memory is still present at that location.
                            Even your old data can still be at that location!

                            Or the memory can be gone, in which case dereferencing i->type will crash.

                            Or something totally different can be in the memory location, in which case
                            ItemDefs[i->type] is likely to crash.

                            Max

                            On Monday 23 February 2009 15:40:24 Arno Saxena wrote:
                            >Ok, I've just constructed a little testgame with a mage casting farsight
                            >and attacking city guards ... without a problem ... It looks like I
                            >cannot reconstruct the bug??!!
                            >
                            >But still the farsight order in the actual game causes the crash. I have
                            >commented out the farsight command and thus avoided the crash. I
                            >commented the farsight command in again and gave the mage a amulet of
                            >invulnerability thus have him survive the battles (just switching of the
                            >attack command did not help, since there had been a battle between
                            >multiple factions and after finding a few of their attack commands
                            >without stopping the battle I added the xxxx item :) )
                            >
                            >Anyway, with a surviving mage the game run has also survived and a
                            >correct output has been generated ...
                            >
                            >This tells me there is more to it than only a killed mage, but it must
                            >be the key to the problem ...
                            >
                            >btw, the debug reached
                            >
                            >AListElem * AList::Next(AListElem * e)
                            >{
                            > if (!e) return 0;
                            > return e->next;
                            >}
                            >
                            >in alist.cpp before stoping the run with the known error ...
                            >
                            >
                            > Arno
                            >
                            >Loriaki wrote:
                            >> On Mon, Feb 23, 2009 at 09:32:49PM +0100, Arno Saxena wrote:
                            >>> Oh dear, I think I have found the problem ...
                            >>>
                            >>> a mage unit has cast farsight. Also the same mage has been lost in
                            >>> combat. Thus the farsight at time of writing the report is based on a
                            >>> non-existing unit ... pretty specific error, I
                            >>
                            >> could you check if the unit has already been destructed ... ? and its
                            >> operating on an stray reference ?
                            >> Otherwise the foreach(&Items) will use stray pointers.
                            >> ======= is a macro ... which dereferences pointers
                            >> if this is so, the unit needs to either destucted later ( or never ;) )
                            >> or needs to be cleanly removed from all lists, which might be ugly work,
                            >> Since AList is not nice.
                            >>
                            >>> have no doubt Loria has
                            >>> run a game very long without being hit by this bug :)
                            >>
                            >> seems so ... at least I stil have no crash ... but it will happen one
                            >> day..
                            >>
                            >>> I don't have given any thought to a solution, just have found this out
                            >>> right this minute ... so any idea would be appreciated!
                            >>>
                            >>> yes, EXC_BAD_ACCESS is a Mac error, but normally I do run the turn on a
                            >>> Linux box (debian lenny), but the debugging I'm doing on a Mac with
                            >>> xcode. The error has occurred on the Linux version first and after that
                            >>> on the mac version too...
                            >>>
                            >>> As for the bug itself, I'm not exactly sure which access exactly has
                            >>> caused the crash, I'll try to reproduce the bug with a minimal test game
                            >>> and an also minimal set of orders, so I can debug it better and let you
                            >>> know what is going on ...
                            >>>
                            >>> greetings
                            >>> Arno
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>>
                            >>> ------------------------------------
                            >>>
                            >>> To Post a message, send it to: atlantisdev@...
                            >>> To Unsubscribe, send a blank message to:
                            >>> atlantisdev-unsubscribe@...! Groups Links
                            >
                            >------------------------------------
                            >
                            >To Post a message, send it to: atlantisdev@...
                            >To Unsubscribe, send a blank message to:
                            > atlantisdev-unsubscribe@...! Groups Links
                            >
                            >
                            >
                          • Max Shariy
                            As far as I remember, Atlantis code contained Hell - a container where all dead units were placed untill the end of processing. It eliminated problems with
                            Message 13 of 17 , Feb 23, 2009
                            • 0 Attachment
                              As far as I remember, Atlantis code contained "Hell" - a container where all
                              dead units were placed untill the end of processing. It eliminated problems
                              with stray pointers to deleted units.

                              So what happened to the hell, I wonder? Does anybody know?

                              Max

                              On Monday 23 February 2009 15:50:05 Enno Rehling wrote:
                              >If this is caused by operating on a unit that's already deleted: don't
                              >delete the units until the end of the turn. It's not going to cause any
                              >trouble.
                              >
                              >What I do in Eressea is that I have a graveyard list of all the dead
                              >units, that way I can still have them in reports at the end in case they
                              >were part of some espionage-report or spell or you-name-it. Just don't
                              >delete the unit, put it on the graveyard list, then delete it after
                              >you're all done with the turn (if you feel that you must clean up).
                              >
                              >Enno.
                              >
                              >
                              >------------------------------------
                              >
                              >To Post a message, send it to: atlantisdev@...
                              >To Unsubscribe, send a blank message to:
                              > atlantisdev-unsubscribe@...! Groups Links
                              >
                              >
                              >
                            • Zorky
                              ... Very true, Hell is still present in the Atlantis code, and is present during the processing of all orders. Unfortunately, Hell gets emptied right before
                              Message 14 of 17 , Feb 23, 2009
                              • 0 Attachment
                                Max Shariy <mshariy@...>:
                                > As far as I remember, Atlantis code contained "Hell"


                                Very true, Hell is still present in the Atlantis code, and is present
                                during the processing of all orders. Unfortunately, Hell gets emptied
                                right before the report generation phase starts.

                                void Game::RunOrders()
                                {
                                EmptyHell();
                                RemoveEmptyObjects();
                                }
                                int Game::RunGame()
                                {
                                Awrite("Running the Turn...");
                                RunOrders();
                                Awrite("Writing the Report File...");
                                WriteReport();
                                }

                                The simple solution is to empty hell a little bit later. Arno, can you
                                test the patch below on the game that crashed to check whether this
                                solves the problem at hand?

                                Regards,
                                Zorky.



                                diff -ru atlantis-4.1.0/game.cpp atlantis-4.1.0a/game.cpp
                                --- atlantis-4.1.0/game.cpp 2008-08-13 18:37:01.000000000 +0200
                                +++ atlantis-4.1.0a/game.cpp 2009-02-24 03:18:04.000000000 +0100
                                @@ -1113,6 +1113,8 @@
                                Awrite("Writing Playerinfo File...");
                                WritePlayers();

                                + EmptyHell();
                                +
                                Awrite("Removing Dead Factions...");
                                DeleteDeadFactions();
                                Awrite("done");
                                diff -ru atlantis-4.1.0/runorders.cpp atlantis-4.1.0a/runorders.cpp
                                --- atlantis-4.1.0/runorders.cpp 2008-08-13 18:37:01.000000000 +0200
                                +++ atlantis-4.1.0a/runorders.cpp 2009-02-24 03:18:06.000000000 +0100
                                @@ -97,7 +97,6 @@
                                Awrite("Post-Turn Processing...");
                                PostProcessTurn();
                                DeleteEmptyUnits();
                                - EmptyHell();
                                RemoveEmptyObjects();
                                }
                              • Arno Saxena
                                yes, the moving of the call of EmptyHell() did the job. I have run the respective turn with the trouble causing cast farsight and the attacks turned on and it
                                Message 15 of 17 , Feb 24, 2009
                                • 0 Attachment
                                  yes, the moving of the call of EmptyHell() did the job. I have run the
                                  respective turn with the trouble causing cast farsight and the attacks
                                  turned on and it has worked fine. All reports and game out files have
                                  been written and are looking good.

                                  Thanks for all the help :)
                                  greetings
                                  Arno

                                  Zorky wrote:
                                  > Max Shariy <mshariy@...>:
                                  >> As far as I remember, Atlantis code contained "Hell"
                                  >
                                  >
                                  > Very true, Hell is still present in the Atlantis code, and is present
                                  > during the processing of all orders. Unfortunately, Hell gets emptied
                                  > right before the report generation phase starts.
                                  >
                                  > void Game::RunOrders()
                                  > {
                                  > EmptyHell();
                                  > RemoveEmptyObjects();
                                  > }
                                  > int Game::RunGame()
                                  > {
                                  > Awrite("Running the Turn...");
                                  > RunOrders();
                                  > Awrite("Writing the Report File...");
                                  > WriteReport();
                                  > }
                                  >
                                  > The simple solution is to empty hell a little bit later. Arno, can you
                                  > test the patch below on the game that crashed to check whether this
                                  > solves the problem at hand?
                                  >
                                  > Regards,
                                  > Zorky.
                                  >
                                  >
                                  >
                                  > diff -ru atlantis-4.1.0/game.cpp atlantis-4.1.0a/game.cpp
                                  > --- atlantis-4.1.0/game.cpp 2008-08-13 18:37:01.000000000 +0200
                                  > +++ atlantis-4.1.0a/game.cpp 2009-02-24 03:18:04.000000000 +0100
                                  > @@ -1113,6 +1113,8 @@
                                  > Awrite("Writing Playerinfo File...");
                                  > WritePlayers();
                                  >
                                  > + EmptyHell();
                                  > +
                                  > Awrite("Removing Dead Factions...");
                                  > DeleteDeadFactions();
                                  > Awrite("done");
                                  > diff -ru atlantis-4.1.0/runorders.cpp atlantis-4.1.0a/runorders.cpp
                                  > --- atlantis-4.1.0/runorders.cpp 2008-08-13 18:37:01.000000000 +0200
                                  > +++ atlantis-4.1.0a/runorders.cpp 2009-02-24 03:18:06.000000000 +0100
                                  > @@ -97,7 +97,6 @@
                                  > Awrite("Post-Turn Processing...");
                                  > PostProcessTurn();
                                  > DeleteEmptyUnits();
                                  > - EmptyHell();
                                  > RemoveEmptyObjects();
                                  > }
                                  >
                                  >
                                Your message has been successfully submitted and would be delivered to recipients shortly.