Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
Hi, i have a very weird fatal exception happening very rarely on my application (compiled under gcc - Ubuntu linux)
it seems that this this function :
Code:
bool GetConnect( ) {return m_Connected;}
causes a Segmentation Fault sometimes (not all the times)
There is nothing weird about these errors. When you corrupt memory, use pointers incorrectly, or other errors that cause memory corruption, then the behaviour of the application is undefined. It could work all the time, fail sometimes, work on one machine and fail on another. So nothing is "weird".
Quote:
No the instance of the class is not deleted when i call that function.
Great, but how are we, persons who know nothing about the rest of your code, the state of your program at the time of the crash, what really happened before the problem occurred, can confirm this? Too many times, we get persons taking oaths that they are doing this or that, and when it comes time to actually see their code in action, they are not doing what they say they are doing.
Quote:
I tried declaring m_Connected as volatile bool m_Connected but still the error happens.
several different threads also access the function that calls this function.
So are you or do you use proper synchronization in this multithreaded program? The usage of "volatile" is not a substitute for proper thread synchronization (mutexes, semaphores, etc.).
Quote:
to make sure that another thread doesnt crash the application i also tried creating the other threads in completely different timings. It crashes every time on the same line.
First, does your program run correctly using one thread? If not, then you need to correct that first.
After that, use proper synchronization objects in your code. Trying to outguess when to create a thread by using "different timings" (whatever that is), or using "volatile" as a poor man's synchronization object isn't going to get the job done.
Quote:
Although it makes no sense at all
If this indeed a threading problem, and you are not familiar with what parts of the code are not thread safe, then anything can happen that may not seem to make sense. Racing conditions, re-entrancy issues, etc. are all of the things that a programmer must be aware of when writing or maintaining multithreaded applications, and little to no experience in these issues will make a seemingly OK looking multithreaded program into one that will fail.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
I use multiple threads for mysql operations such as inserting rows, updating rows, deleting rows etc.
i am aware of synchronization methods such as mutexes. i use boost::thread mutexes.
but i'm keeping my code clean of object sharing because mutexes with mysql can lead to really bad performance (tested before)
so instead i just use volatile booleans to check the state of something which worked just fine in most of my applications.
again i'm not some expert in c++ , i taught myself over the past 2 years and it's my first programming language, but i have experimented a long time with this stuff and i never state anything if i haven't experienced it firsthand.
the application fails at some point when i compile it in gcc (linux) but works just fine with the VC compiler on windows (based on a 24 hour runtime) so debugging all this has become a real pain in the arse as i have to wait at least 24 hours for it to ''crash'' with that segmentation fault.
i will try to make the function non-virtual and run it again tonight for another 24 hours...
just wondered if anyone experienced the same annoying problem.
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
the application fails at some point when i compile it in gcc (linux) but works just fine with the VC compiler on windows (based on a 24 hour runtime) so debugging all this has become a real pain in the arse as i have to wait at least 24 hours for it to ''crash'' with that segmentation fault.
That is the issue with multithreaded programs. If you have a threading issue, you may never have it come up when you compile with one compiler as opposed to another. You can't even predict if you change compiler settings in Visual C++, the error won't shows up. As a matter of fact, even if it isn't a threading issue, you shouldn't be fooled into thinking your program is OK if it runs on a compiler but fails to run with another compiler. That other compiler where it is not working is giving you the red flag that your program has a bug and you need to fix it.
And as I stated earlier, any corruption bugs leads to undefined behaviour. This means the application may seem to work, but as soon as you change compiler options, or add/remove code, or use another version or brand of compiler, or you run the program on a different machine, all sorts of "weird" bugs could crop up at runtime (I put "weird" in quotes, since as I stated, there are no weird bugs in C++, unless the compiler itself is producing broken code, and the possibility of that happening is fairly remote).
Quote:
just wondered if anyone experienced the same annoying problem.
Yes, it's called "debugging multithreaded programs". Again, any issue with threading will occur at random times, times that you cannot predict. Every programmer who has worked with multithreaded programs has encountered this issue.
Quote:
I use multiple threads for mysql operations such as inserting rows, updating rows, deleting rows etc. i am aware of synchronization methods such as mutexes. i use boost::thread mutexes.
but i'm keeping my code clean of object sharing because mutexes with mysql can lead to really bad performance (tested before)
You never mentioned anything about racing conditions, reentrancy, etc. Just because you used synchronization objects doesn't mean you used them correctly.
Proper usage of synchronization objects, and the usage of the correct synchronization objects is not a trivial topic. When you write the code, you have to identify before even running the program where the potential problems may exist.
Just to let you know, in the industry, if a company uses multithreading heavily, they will not hire a programmer if they have little to no experience in multithreaded applications, regardless of how much C++ they've done, 2 years or 20 years. A 24-hour wait time before a crash is generated would be considered unacceptable -- you need to identify in the code all of the issues that could occur, and then write the proper code to overcome these issues. If you missed anything, then you go through the code again and attempt to see what parts of the code are using the corrupted variable(s) and identify what could cause the corruption.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
so instead i just use volatile booleans to check the state of something which worked just fine in most of my applications.
But now it doesn't work. You get what you pay for -- the usage of volatile is IMO a poor substitute for real multithreaded synchronization.
Just this line alone is suspect:
Code:
if(client->m_Deleting) // before we delete our instance of Clients* we set this flag. the instance is deleted 240 seconds later.
Reading that comment, it seems you're relying on specific timings to do certain things. That is not the way to write a multithreaded program. What is 240 seconds on one machine may be 2 seconds on another.
You cannot predict anything in terms of timing -- you have to write code that works, regardless if it's 240 seconds or 0.2 seconds later (or before). That requires you to look at your code, and determine if there is any potential for a racing condition or re-entrancy issues.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
Like you can see in the function, the instance of that class is never ever used/referred/dereferred if the flag DeleteMe is set because every time we wanna see or change data or anything on that instance we call the CBoolExpr( ) function that checks the flag.
2 seconds / 240 seconds / 1200 seconds it doesnt matter. It's just a precaution method of dereferrencing memory in 1 thread out of the multiple and safely.
i already solved the problem by making the function non-virtual and volatile.
thanks for the feedback however, it helped me solve some other problems i had.
knowledge once again is infinite, we keep on learning. best regards.
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
the application fails at some point when i compile it in gcc (linux) but works just fine with the VC compiler
That's quite interesting. If anything I'd expect it to be the other way around. I use VC++ as well as gcc and one thing I've noticed about VC++ is that it will almost never allow you to access memory you've deleted. This is especially true for Debug builds. gcc unfortunately is a different kettle of fish. In my experience, it seems perfectly happy to let you to carry on using deleted pointers until the memory gets re-used for something else - at which point you get a sudden and apparently inexplicable crash.
As Paul described, corrupted pointers give you exactly this kind of problem. Your app works perfectly most of the time but crashes at random for no obvious reason. Or the app works fine on your machine but not on somebody else's.
If you're confident that this isn't a synchronisation issue, the other most likely cause is that Clients.m_socket is getting overwritten by garbage. Is there a buffer in front of it that's too small? Maybe the buffer is 10 bytes but somewhere, you're writing 11 bytes of data into it. Because of structure packing, this is the kind of problem that might show up in one compiler but not the other.
Try building the gcc version with the --mms-bitfields flag. This forces your gcc app to use the same structure packing as VC++. It's not a fix but if that causes the problem to go away, it might indicate a data member getting overwritten somehow.
Of course if you had access to a decent debugger you could track this problem down in a few minutes. Sadly, you're stuck with gdb. :(
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
Like you can see in the function, the instance of that class is never ever used/referred/dereferred if the flag DeleteMe is set because every time we wanna see or change data or anything on that instance we call the CBoolExpr( ) function that checks the flag.
And what happens if that function is called after the object has been deleted? What do you think the value of m_Deleting will be?
Regardless of when you actually call delete, at the moment you decide that an object should be destroyed, you should consider the object to be invalid. That means no part of your code should access that object. You cannot check this inside the object, because it is invalid. At best, you could use the m_Deleting flag as a debugging tool, i.e. you assert that it is false. However, the only way to assure that assertion would work properly is to prevent any CPDC from being deleted (for debugging purposes only).
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
Like you can see in the function, the instance of that class is never ever used/referred/dereferred if the flag DeleteMe is set because every time we wanna see or change data or anything on that instance we call the CBoolExpr( ) function that checks the flag.
So is JohnE and D_Drmmr correct in that you're deleting the instance, and then checking a member of this deleted instance for a value? If that's the case, then that is undefined behaviour.
When you delete an instance of an object, you cannot use that object any longer.
Code:
#include <iostream>
class foo
{
public:
bool m_bDeleting;
};
int main()
{
foo *pFoo = new foo;
pFoo->m_bDeleting = true;
delete pFoo;
std::cout << pFoo->m_bDeleting; // behaviour is undefined
}
That last line of code, where the m_bDeleting flag is being checked, has undefined behaviour. You cannot point to a deleted object and assume you can use its remains for anything.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
i think you didn't pay attention at all at the code.
i do not use the object instance without checking if First : object instance not null
Code:
if( !foo )
return false;
which works 100%
Second : if it's indeed not null, object flag for collection is not true
Code:
if( foo->DeleteMe )
return false;
the only way the the object is deleted right after the
if( !foo ) line is that the function that called it took about 240.00001 seconds to check if the object instance is null.
and if that happens then there's some serious performance issue with my application. There's no way remotely even for a primitive CPU with primitive RAM to take 240 seconds to find a memory location.
Again, i solved the problem.
object->GetConnected( ) was a virtual function so i made it non virtual and it works great now.
been running the server a day and no problems so far.
i think that there's some sort of conflict on multi-threaded applications and virtual functions... since these functions are resolved on runtime... Can't really tell but something similar is happening.
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
i think you didn't pay attention at all at the code.
The problem is that you didn't post enough code without us having to guess what you're doing. All we see is the code you posted. There is no context whatsoever in the posted code as to what you have done or what you are about to do.
Quote:
i do not use the object instance without checking if First : object instance not null
And what makes this object NULL? Do you set it to NULL? I don't see that anywhere.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
if( !foo ) line is that the function that called it took about 240.00001 seconds to check if the object instance is null.
and if that happens then there's some serious performance issue with my application.
If it takes 240 seconds to check if a pointer is NULL, it means you have memory corruption bugs in your application, not a performance issue.
Quote:
Again, i solved the problem.
object->GetConnected( ) was a virtual function so i made it non virtual and it works great now.
This indicates to me that you've messed up the virtual mechanism by corrupting the v-table. There should not be an issue whether the function is virtual or not.
Quote:
been running the server a day and no problems so far.
I'll be honest with you -- with all you've described, your application is still faulty, and all you did was to temporarily mask the faults by changing from virtual to non-virtual.
Quote:
i think that there's some sort of conflict on multi-threaded applications and virtual functions... since these functions are resolved on runtime... Can't really tell but something similar is happening.
Virtual functions have nothing to do with threads. As I stated, it sounds as if your application has either corrupted the v-table or using an invalid v-table.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
Quote:
Originally Posted by
Paul McKenzie
Quote:
Originally Posted by
JacobNax
i think that there's some sort of conflict on multi-threaded applications and virtual functions... since these functions are resolved on runtime... Can't really tell but something similar is happening.
Virtual functions have nothing to do with threads. As I stated, it sounds as if your application has either corrupted the v-table or using an invalid v-table.
To be frank, there's very little about gcc that would surprise me but this certainly would. Really Jacob, you need to listen to Paul. gcc has been around a long time. If it had a fundamental conflict between virtual functions and threads, someone would have noticed it by now.
You said in your original post that the segmentation faults were very rare occurrences and yet you claim you've fixed the problem on the basis of just one test.! This really is the worst kind of programming. There's only one way to fix bugs in your program and that's to analyse and understand them - not to make arbitrary changes which seem to make the problem go away. You'd have probably got the same result by compiling with -mms-bitfields as I suggested a few posts back but that wouldn't have been a solution either. It would just have been an indicator of what might be wrong.
Don't take this criticism too harshly. Most of us go through a phase like this when we're inexperienced programmers. It feels a bit like alchemy - trying to understand the workings of nature when you don't have sufficient knowledge. But the answer is to gain the knowledge, not to carry on believing in alchemy.
Re: Segmentation Fault ??
Quote:
Originally Posted by
John E
You said in your original post that the segmentation faults were very rare occurrences and yet you claim you've fixed the problem on the basis of just one test.! This really is the worst kind of programming. There's only one way to fix bugs in your program and that's to analyse and understand them - not to make arbitrary changes which seem to make the problem go away.
To Jacob:
What JohnE has described is the classic case in C++ of moving a bug around to another part of your code by making arbitrary changes that have nothing to do with the cause of the problem.
In your case, you changed from virtual to non-virtual. In other cases, a simple adding or removing of a member variable to a class is enough to mask a bug and seemingly make a program "work". The problem is that you didn't fix the bug -- you just moved it to another part of the application. As soon as you change code again or run it on another computer, that bug is ready to crop up again.
These problems are due to memory corruption. That corruption can be caused by
1) accessing arrays beyond the boundaries of the array.
2) Mismanaging pointers and dynamically allocated memory.
3) illegal (but syntactically correct) C++ coding, i.e. using malloc() or memcpy() on non-POD types, returning pointers or references to local variables, etc.
4) In rare cases, not compiling your entire application (you have object code that contains two different definitions of the same variables), causing a conflict when you run your program.
5) Corruption due to thread issues.
We have no idea if the rest of your code has not done any of the above. The one that would be of real concern is 3), since an inexperienced C++ programmer would believe he/she is doing things correctly when they are actually wrong. The compiler gives no warning or errors, so the programmer never realizes the error to begin with.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
heres some clue about the life-cycle of the Clients* object
Code:
CTCPSocket *NewSocket = pdcc->m_CTCPS->Accept( (fd_set *)&fd );
if( NewSocket )
{
NewSocket->NoDelay(true);
Clients *client = new Clients(NewSocket, pdcc);
client->m_Identified = false;
client->m_Chat = pdcc->m_DefaultChat;
CONSOLE_Print("[SERVER] New client has connected to the server [ " + NewSocket->GetIPString( ) + "].");
m_Clients.push_back(client);
}
client connects to the server...
Code:
for(vector<Clients*> :: iterator i = m_Clients.begin( ); i != m_Clients.end( );)
{
if( (*i)->m_Socket && (*i)->m_Socket->GetConnected( ) && !(*i)->m_Socket->HasError( ) )
{
(*i)->m_Socket->SetFD(&fd, &send_fd, &nfds);
nfds++;
i++;
}
else
{
cout << "A client connection was lost." << endl;
CleanUpUser((*i));
i = m_Clients.erase( i );
}
}
client connection lost
Code:
void CPDC :: CleanUpUser(Clients *client)
{
client->m_DeleteTime = GetTime();
client->m_Deleting = true;
m_ClientsDeleting.push_back(client);
}
dereferrencing the instance safely later
Code:
for(vector<Clients*> :: iterator i = m_ClientsDeleting.begin( ); i != m_ClientsDeleting.end( ); )
{
if( (*i) )
{
if( GetTime() - (*i)->m_DeleteTime >= 240 )
{
delete *i;
(*i) = NULL;
i = m_ClientsDeleting.erase( i );
}
else
i++;
}
else
i = m_ClientsDeleting.erase( i );
}
seg fault happens on the CBoolExpr( ) function that validates the Client
i use that whenever a client sends a 'special' package and when the client disconnects ( we got chat channels that remove Clients if their delete flag is on. )
Code:
for(vector<CChat*> :: iterator i = m_ChatRooms.begin( ); i != m_ChatRooms.end( );)
{
if(!(*i))
i = m_ChatRooms.erase( i );
else
{
for(vector<Clients*> :: iterator j = (*i)->m_Users.begin( ); j != (*i)->m_Users.end( );)
{
if( (*j) && !CBoolExpr( (*j) ) )
{
Event_UserLeft2( (*j), (*i) );
j = (*i)->m_Users.erase( j );
}
else
j++;
}
i++;
}
}
the socket wrapper
Code:
class CSocket
{
protected:
SOCKET m_Socket;
struct sockaddr_in m_SIN;
bool m_HasError;
int m_Error;
public:
CSocket( );
CSocket( SOCKET nSocket, struct sockaddr_in nSIN );
~CSocket( );
virtual BYTEARRAY GetPort( );
virtual BYTEARRAY GetIP( );
virtual string GetIPString( );
bool HasError( );
virtual int GetError( ) { return m_Error; }
virtual string GetErrorString( );
virtual void SetFD( fd_set *fd, fd_set *send_fd, int *nfds );
virtual void Allocate( int type );
virtual void Reset( );
};
class CTCPSocket : public CSocket
{
protected:
bool m_Connected;
private:
string m_RecvBuffer;
string m_SendBuffer;
uint32_t m_LastRecv;
uint32_t m_LastSend;
public:
CTCPSocket( );
CTCPSocket( SOCKET nSocket, struct sockaddr_in nSIN );
virtual ~CTCPSocket( );
virtual void Reset( );
bool GetConnected( );
virtual string *GetBuffer( ) { return &m_RecvBuffer; }
virtual void PutBytes( string bytes );
virtual void PutBytes( BYTEARRAY bytes );
virtual void ClearRecvBuffer( ) { m_RecvBuffer.clear( ); }
virtual void ClearSendBuffer( ) { m_SendBuffer.clear( ); }
virtual uint32_t GetLastRecv( ) { return m_LastRecv; }
virtual uint32_t GetLastSend( ) { return m_LastSend; }
virtual void DoRecv( fd_set *fd );
virtual void DoSend( fd_set *send_fd );
virtual void Disconnect( );
virtual void NoDelay( bool noDelay );
};
i dont use memcpy( ) or malloc( )
and also i don't use arrays because arrays are evil.
just memset
Code:
CSocket :: CSocket( )
{
m_Socket = INVALID_SOCKET;
memset( &m_SIN, 0, sizeof( m_SIN ) );
m_HasError = false;
m_Error = 0;
}
Re: Segmentation Fault ??
I have not taken a really good look at your code, but just a warning: the CSocket destructor should be declared virtual. Declaring the destructor of its derived class as virtual is not enough.
Re: Segmentation Fault ??
One other thing.... how does your program know that the object will need to be deleted in precisely 4 minutes' time? Generally speaking, you delete an object when you no longer need it and you don't normally know this, four minutes in advance.
The 4 minute delay suggests to me that some other process is somehow still using the object and you're just making a guess about how long it might need it for.
Or to put it another way, try re-instating the virtual function from yesterday but increase 240 to 360. My guess is that this will also make the problem magically go away. So will a lot of other arbitrary changes. You need to look for the kind of thing that Laserlight suggested. It'll end up being something like that or a pointer corruption problem.
It's a great shame that you can't reproduce the problem in VC++ because it's much better for debugging this kind of problem than gdb.
Re: Segmentation Fault ??
m_ClientsDeleting.push_back(client);
i = m_ClientsDeleting.erase( i );
Are these two function calls occurring in the same thread?
If they are not, then this will almost certainly be a source of memory corruption.
Re: Segmentation Fault ??
yes, i do not insert elements into vectors or containers of alien threads.
the Clients* instance is used for the MYSQL login process of the clients.
.erase( ) is called on the same thread. all i share with other threads is boolean variables.
so the only thread that tries to access it is the mysql thread with the mysql login function.
although the function is safe because
i get the std::string m_Name of the client and copy it so i can use it in my queries.
then i try to access the pointer at the end of the query so i can set the :
Clients::m_Identified flag to true.
ii use the CBoolExpr( ) function for that.meaning that the object is used at the start of the function before the queries (thus the blocking of code)
and at the end of the function after the queries.
Quote:
Originally Posted by
laserlight
I have not taken a really good look at your code, but just a warning: the CSocket destructor should be declared virtual. Declaring the destructor of its derived class as virtual is not enough.
thanks, didn't notice that before.
---EDIT
so the server is still running from yesterday, but i'm 99% sure you guys are right about memory corruption in my code.
although i don't precisely know why.
here's the destructor of the Clients class
Code:
Clients :: ~Clients( )
{
delete m_Socket;
m_Socket = NULL;
while(!m_CPackets.empty() )
{
delete m_CPackets.front();
m_Packets.pop();
}
}
Yes you are right. I totally forget a C in the m_Packets.pop( )
seems we got some major memory leaks
--EDIT
and this is how it should be
Code:
Clients :: ~Clients( )
{
delete m_Socket;
m_Socket = NULL;
while(!m_CPackets.empty() )
{
delete m_CPackets.front();
m_CPackets.pop();
}
while(!m_Packets.empty() )
{
m_Packets.pop();
}
}
constructor :
Code:
class Clients
{
public:
CTCPSocket *m_Socket;
CChat *m_Chat;
CPDC *m_PDC;
string m_Name;
uint32_t m_Id;
uint32_t m_LastSend;
uint16_t m_Version;
string m_ChatRoom;
queue<BYTEARRAY> m_Packets;
queue<CCPacket*> m_CPackets;
.... // more vars
Clients( CTCPSocket *socket, CPDC *pdc );
virtual ~Clients( );
};
Re: Segmentation Fault ??
Quote:
Originally Posted by
JacobNax
heres some clue about the life-cycle of the Clients* object
1) The code you posted doesn't show where you are setting pointers to NULL so that checking for NULL will work correctly. Deleting an object does not set an object to NULL.
2) If your code is holding onto iterators or pointing to entries in the vector whenever the vector is resized (in this case grown), then those iterators or pointers can become invalidated here:
Code:
m_Clients.push_back(client);
3) This loop could be rewritten using algorithms.
Code:
for(vector<Clients*> :: iterator i = m_Clients.begin( ); i != m_Clients.end( );)
{
if( (*i)->m_Socket && (*i)->m_Socket->GetConnected( ) && !(*i)->m_Socket->HasError( ) )
{
(*i)->m_Socket->SetFD(&fd, &send_fd, &nfds);
nfds++;
i++;
}
else
{
cout << "A client connection was lost." << endl;
CleanUpUser((*i));
i = m_Clients.erase( i );
}
}
If the goal is to erase all closed connections in the loop, and to call SetFD on the good connections, that probably could have been accomplished this way:
Code:
#include <algorithm>
//...
bool IsGoodConnection(Client* pClient)
{
return pClient->m_Socket &&
pClient->m_Socket->GetConnected( ) &&
!pClient->>m_Socket->HasError( );
}
struct FDSetter
{
int fd;
int send_fd;
int nfds;
FDSetter() : nfds(1) {}
void operator()(Client* pClient)
{
pClient->m_Socket->SetFD(&fd, &send_fd, &nfds);
++nfds;
}
};
void SetFD(Client *pClient)
{
// good connections on left of partition, bad/closed connections on right of partition
vector<Clients*>::iterator partition = std::stable_partition(m_Clients.begin(), m_Clients.end(), IsGoodConnection);
// get the number of good entries (left of partition)
nfds = std::distance(m_Clients.begin(), partition);
// for each good connection, call SetFD
std::for_each(m_Clients.begin(), partition, FDSetter());
// erase the bad connections by calling CleanUpUser and then erase them from the vector
std::for_each(partition, m_Clients.end(), CleanUpUser);
m_Clients.erase(partition, m_Clients.end();
If what you wanted to do was to get rid of the closed connections, erase them from the vector, and keep/setup the good connections, then partitioning them first so that they are grouped accordingly could have been done. Note the use of stable_partition so as to maintain the order of the connections in the vector.
Note that there are no loops. I did not know what to set fd and send_fd in the FDSetter class, since you didn't specify what they were or how they are used in the SetFD call. But the point is that writing loops as you've done can be error prone.
Usage of algorithms guarantees that the code will work, provided that you call the correct algorithm functions with the correct arguments. In other words, there is no need for me to check the code above for iterator bugs or some other issue that could easily happen when attempting to write your own loops. It is also self-documenting, as any competent C++ programmer knows what those algorithm functions do. When given hand-coded loops as you've been doing, it may take several looks throught it to a) knows whart it does, and b) be assured it works correctly.
The loop writing, erasing, making sure that iterators are seated properly, etc. -- leave that work to the algorithms.
Regards,
Paul McKenzie
Re: Segmentation Fault ??
thanks Paul
your version looks neat and well written
i haven't studied much the algorithms, just how the sort() and shuffling works.
