Register forum user name Search FAQ

Gammon Forum

Notice: Any messages purporting to come from this site telling you that your password has expired, or that you need to "verify" your details, making threats, or asking for money, are spam. We do not email users with any such messages. If you have lost your password you can obtain a new one by using the password reset link.
 Entire forum ➜ Programming ➜ General ➜ Cygwin and STATUS_ACCESS_VIOLATION
Cygwin and STATUS_ACCESS_VIOLATION

It is now over 60 days since the last post. This thread is closed.     Refresh page

Posted by Nick Cash   USA  (626 posts)  Bio
Date Thu 19 Jun 2008 01:47 AM (UTC)
Message
Hello once again everyone. I apologize for my absence, but my internet access is very limited this summer (interning with Lockheed Martin).

I've been working on my own server for quite a while now, and truth be told it isn't too far along. However, I've hit kind of a strange wall. I want it to run in cygwin due to my lack of internet connectivity. It compiles and runs, but any time I try to quit out it dies on me with this stackdump:

$ cat BattleMUD.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at eip=00407869
eax=102026C0 ebx=00000000 ecx=61106B24 edx=3E312E34 esi=611001A0 edi=00419A80
ebp=0022CA98 esp=0022CA70 program=C:\cygwin\home\Nick\battle_trunk_svn\src\BattleMUD.exe, pid 2964, thread main
cs=001B ds=0023 es=0023 fs=003B gs=0000 ss=0023
Stack trace:
Frame     Function  Args
0022CA98  00407869  (10202398, 102026C0, 00000000, 10202A04)
0022CB28  004075BA  (10202398, 00000005, 00000BB8, 00457F68)
0022CBA8  00408AA0  (10202398, 1020245C, 0045B5DC, 00000BB8)
0022CC98  00409424  (00000001, 10201E30, 10200090, 61166990)
0022CD98  61006198  (00000000, 0022CDD0, 61005510, 0022CDD0)
61005510  61004416  (0000009C, A02404C7, E8611001, FFFFFF48)
 416634 [main] BattleMUD 2964 _cygtls::handle_exceptions: Exception: STATUS_ACCESS_VIOLATION
 423101 [main] BattleMUD 2964 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack)


The odd thing is that this code has never been a problem on my host machine (which runs some flavor of Fedora). Since I have no internet access regularly, I'll provide some clues with code. GDB intercepted the seg fault:

Program received signal SIGSEGV, Segmentation fault.
0x00407869 in Server::ClosePlayer (this=0x10202398, pPlayer=<incomplete type>) at server.cpp:281
281           delete (cPlayer*)pPlayer;
(gdb) bt
#0  0x00407869 in Server::ClosePlayer (this=0x10202398, pPlayer=<incomplete type>) at server.cpp:281
#1  0x004075ba in Server::ProcessPlayers (this=0x10202398) at server.cpp:199
#2  0x00408aa0 in Server::Run (this=0x10202398) at server.cpp:450
#3  0x00409424 in main (argc=1, argv=0x10201e30) at main.cpp:88
(gdb) frame 1
#1  0x004075ba in Server::ProcessPlayers (this=0x10202398) at server.cpp:199
199             ClosePlayer(player);
(gdb) list
194         {
195           player = i->second;
196
197           // if we are logging off or have no socket, go ahead and delete
198           if ( player->GetLogOff() || !player->ValidSocket() )
199             ClosePlayer(player);
200           else // Process input
201           {
202             std::string str = player->GetInCommand();
203
(gdb)
204             // Send the string to the command handler
205             if ( !str.empty() )
206               player->Handle( str );
207
208             // Command has been run, clear it
209             player->ClrInCommand();
210           }
211         }
212     }
213
(gdb) frame 0
#0  0x00407869 in Server::ClosePlayer (this=0x10202398, pPlayer=<incomplete type>) at server.cpp:281
281           delete (cPlayer*)pPlayer;
(gdb) list 275
270     }
271
272     // Correctly remove a player from the server
273     void Server::ClosePlayer(cPlayer *pPlayer)
274     {
275        if ( pPlayer )
276        {
277           // remove from list
278           players.erase(pPlayer->GetID());
279
(gdb)
280           // delete
281           delete (cPlayer*)pPlayer;
282       }
283       else
284           LOG_ERROR("Server::ClosePlayer", "%s", "Null Player Provided" );
285     }
286
287     void Server::Accept()
288     {
289       cSocket *pSocket;
(gdb)


Toss out some ideas. If you want more code I can show it, but there is some more subtle problem here as the code runs quite well on the host machine.
~Nick Cash
http://www.nick-cash.com
Top
Posted by Nick Cash   USA  (626 posts)  Bio
Date Reply #1 on Thu 19 Jun 2008 01:52 AM (UTC)

Amended on Thu 19 Jun 2008 01:54 AM (UTC) by Nick Cash

Message
To clarify, I can connect and do some basic commands. The problem occurs when I try to exit while being logged in.

cPlayer inherits cCharacter, the base class for mobile functionality. cCharacter inherits cActor, the base class for any object that has interaction within the game.

There is a single server object that keeps track of the game state, and thusly is responsible for keeping track of sockets and characters.

All of this code is based on the extremely barebone release of Socketmud II, and thusly is in C++.

The game is mostly still a learning experience, and I don't mind reworking things to get them the way I like it. There is obviously a lot of revision that needs to be done, but it should be a better and far more flexible system then SMAUG. It is also completely query driven, allocating the least amount of things possible. Eventually I'll get around to adding scripting functionality, but I can only do one small step at a time. :)
~Nick Cash
http://www.nick-cash.com
Top
Posted by Nick Gammon   Australia  (23,057 posts)  Bio   Forum Administrator
Date Reply #2 on Thu 19 Jun 2008 02:32 AM (UTC)
Message
First, why the cast here?

delete (cPlayer*)pPlayer;

Isn't that already the correct type?

What sort of container are the players in? Since it is crashing on the delete line, I suspect you are deleting items out of a list, while you are iterating through it.

See: http://www.gammon.com.au/forum/?id=3079

And in particular: 


// safe_for_each.  Apply a function to every element of a range.
// should handle correctly an element deleting itself 

template <class ITER, class F>
F safe_for_each (ITER first, ITER last, F func) 
  {
  while (first != last)
    func (*first++);
  return func;
  }


Try modifying your loop so that the iterator is still valid.

Instead of whatever you have, which is probably something like:



for (i = players.begin (); i != players.end (); i++)
  { 
  player = i->second;

  // blah blah
  }


Try:



for (i = players.begin (); i != players.end (); )
  { 
  player = i->second;
  i++;


  // blah blah
  }


That way the iterator is still valid if you remove a player from the container.

- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Cash   USA  (626 posts)  Bio
Date Reply #3 on Thu 19 Jun 2008 07:38 PM (UTC)
Message
Quote:

First, why the cast here?

delete (cPlayer*)pPlayer;

Isn't that already the correct type?


It is indeed. That was a remnant of me playing with GDB and I guess I forgot to switch it back. It has since been removed.

I seem to recall having a similar problem to this before, but it is strange that it works on my host. I spent quite a bit of time getting players to delete correctly (and sockets) out of their respective processing loops. I guess whatever change I was working on is either on my host or another machine, but not my laptop and it never made it into my repository.

Anywho, I'll try modifying the loops later and see what comes of it.

Thanks for the idea.
~Nick Cash
http://www.nick-cash.com
Top
Posted by Nick Gammon   Australia  (23,057 posts)  Bio   Forum Administrator
Date Reply #4 on Thu 19 Jun 2008 08:29 PM (UTC)
Message
Not that strange. It depends a bit on what is left lying around once something is deleted. It might be the iterator stumbles across a zero or something fairly quickly, and stops iterating.

Usually a crash on "just one platform" is really an indication of an underlying problem, and you have been lucky it hasn't happened sooner.
- Nick Gammon

www.gammon.com.au, www.mushclient.com
Top
Posted by Nick Cash   USA  (626 posts)  Bio
Date Reply #5 on Mon 23 Jun 2008 11:46 PM (UTC)
Message
I looked by in my repository and found out I had gone through a lot of revision changes for how I was processing players and sockets. I had spent time fixing this exact issue, but due to large code reforms I had lost those fixes. Thanks for pointing it out :)
~Nick Cash
http://www.nick-cash.com
Top

The dates and times for posts above are shown in Universal Co-ordinated Time (UTC).

To show them in your local time you can join the forum, and then set the 'time correction' field in your profile to the number of hours difference between your location and UTC time.

33,539 views.

It is now over 60 days since the last post. This thread is closed.     Refresh page

Go to topic:           Search the forum

[Go to top] top

Information and images on this site are licensed under the Creative Commons Attribution 3.0 Australia License unless stated otherwise.

Home