Valgrind macht alle Themen Mein Programm des Schlaf

Question

OS/Umwelt Info:

plee@sos-build:~$ lsb_release -a 
No LSB modules are available. 
Distributor ID: Ubuntu 
Description: Ubuntu 11.10 
Release:  11.10 
Codename:  oneiric 
plee@sos-build:~$ uname -a 
Linux sos-build 3.0.0-12-generiC#20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux 

ich auf einem serverseitigen Projekt arbeite.

Ich habe mehrere Probleme mit diesen Projekten:

1. boost::weak_ptr<T>.lock() Crashes with a SIGSEGV Segmentation Fault
2. pthread_mutex_lock __pthread_mutex_lock_full: Assertion failed with robust and 0x4000000

ich vorgeschlagen wurde Valgrind verwenden zu finden, wo das Problem (vor allem für die erste Ausgabe) ist. Also benutze ich Valgrind.

valgrind --leak-check=full --gen-suppressions=all --suppressions=valgrind_suppressions.supp MyServerSideProgram arg1 arg2 arg3 arg4

Mein Programm hat 13 Threads gleichzeitig ausgeführt werden. Am Anfang arbeiten sie gut. Nach einer gewissen Zeit gehen alle Threads in den Ruhezustand.

Der Befehl, den ich verwendet, um alle Threads' Status zu überprüfen: top -H -p [MyServerSideProgram's PID]

Und das Ergebnis ist:

w: S -- Process Status 
    The status of the task which can be one of: 
    'D' = uninterruptible sleep 
    'R' = running 
    'S' = sleeping 
    'T' = traced or stopped 
    'Z' = zombie 

So eine Idee:

top - 11:54:34 up 46 days, 22:30, 4 users, load average: 0.02, 0.02, 0.05 
Tasks: 13 total, 0 running, 13 sleeping, 0 stopped, 0 zombie 
Cpu(s): 0.5%us, 0.1%sy, 0.0%ni, 99.2%id, 0.1%wa, 0.0%hi, 0.0%si, 0.0%st 
Mem: 9224140k total, 8135872k used, 1088268k free, 294988k buffers 
Swap: 9431164k total, 424416k used, 9006748k free, 4973316k cached 

    PID USER  PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND                                    
8744 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:06.81 memcheck-amd64-                                  
8747 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:42.27 memcheck-amd64-                                  
8748 plee  20 0 1379m 1.2g 6276 S 0 13.7 30:58.15 memcheck-amd64-                                  
8749 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:53.62 memcheck-amd64-                                  
8750 plee  20 0 1379m 1.2g 6276 S 0 13.7 30:58.68 memcheck-amd64-                                  
8751 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:31.65 memcheck-amd64-                                  
8752 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:24.63 memcheck-amd64-                                  
8753 plee  20 0 1379m 1.2g 6276 S 0 13.7 32:05.33 memcheck-amd64-                                  
8754 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:52.24 memcheck-amd64-                                  
8755 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:11.69 memcheck-amd64-                                  
8756 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:17.10 memcheck-amd64-                                  
8757 plee  20 0 1379m 1.2g 6276 S 0 13.7 31:54.65 memcheck-amd64-                                  
8758 plee  20 0 1379m 1.2g 6276 S 0 13.7 32:10.67 memcheck-amd64- 

ich die man top überprüft? Vielen Dank.

Peter

Answer 1

Als David Schwartz sagte,

es nicht klar ist, warum dies ein Problem

ist er richtig ist. Ich habe einen einfachen Test gemacht: Ich habe einen anderen separaten Client erstellt, und habe eine Verbindung zum Server hergestellt, Befehle an den Server gesendet und Antworten vom Server erhalten. Der Server ist also in einem guten Zustand.

Das bedeutet, der Belastungstest hat einige Probleme. Es hört einfach auf, Client-Befehle an den Server zu senden.

Einer meiner Mitarbeiter schrieb diesen Teil in Java (während mein Server in C++/Boost geschrieben ist). Ich muss seinen Code ansehen. Es wird eine Menge Zeit brauchen.

Ich werde hier zurückkommen, sobald ich etwas aus dem Belastungstest-Code gefunden habe.