views:

179

answers:

3

We develop a network library that uses TCP and UDP sockets. This DLL is used by a testclient, which is started multiple times at the same PC for a load test.

In Windows Vista, it is no problem to start the testclient many times. In Windows XP, starting it up to 5 times is no problem, but if we start it 6 times or more, and then closing one client, ALL of them crash with apparently random stack traces.

Yes, although we do not use any interprocess code (only sockets between the clients), the termination of one of the client leads to the crash of all of them.

Our DLL is compiled with MSVC and uses Boost and Crypto++ libs (statically linked).

Any idea why the different processes could influence each other?

A: 

An idea: You have some bug.

Seriously, there is no way to know what's your problem without any information what so ever.
When a process crashes it usually has a very good reason to do so. find out what that is. Compile your dlls and executables in debug, attach a debugger and make sense of the stack trace you get. if you get a nonsense stack trace, find out why that is.

As with many problems, this one is likely to be solved by "Just debugging it"

shoosh
In particular, try running at least two clients under debugger. When the "random" crash occurs, look at the memory being accessed at the time by all threads, and at the code being executed. Is it related to the library?
Arkadiy
in fact, it was actually a bug of deleting an object twice, which strangely only occured with more clients. Thank you.
Tarnschaf
+1  A: 

We'll need a little bit more data in order to diagnose your problem. However considering that shutting down one client crashes all of the clients, you need to consider all the ways in which the clients can affect each other (inter process communication). Either implicitly or explicitly. So I would start by looking at

  • What does the server do when the 6th client is closed. Does it send out a special packet that the other 5 clients just can't handle?
  • Are you reading or writing anything to the file system?
  • Do you use shared memory?

In general though, I've found that having a seemingly random stack trace in C++ is usually caused by one of the following

  • Data Corruption
  • Race Condition in the threading logic.
JaredPar
A: 

Modification of the DLL or locking the DLL may cause programs that depend on it to crash. Typically, changes to the DLL will be locked by the file system but it could be possible that in your application, you are doing something out of the ordinary.

sep
thanks for the response, but the DLL is not modified during program execution
Tarnschaf