Σωρός της διαφθοράς στο πλαίσιο Win32? πώς να εντοπίσετε;

ψήφοι
54

Δουλεύω σε ένα multi-threaded C ++ εφαρμογή που διαφθείρει το σωρό. Τα συνήθη εργαλεία για να εντοπίσετε αυτό το διαφθορά φαίνεται να είναι ανεφάρμοστο. Παλιά χτίζει (18 μηνών) του πηγαίου κώδικα παρουσιάζουν την ίδια συμπεριφορά με την πιο πρόσφατη έκδοση, έτσι αυτό έχει εδώ και πολύ καιρό και απλά δεν είχε παρατηρήσει? καθοδικοί, δέλτα πηγή δεν μπορούν να χρησιμοποιηθούν για την αναγνώριση, όταν εισήχθη το bug - υπάρχουν πολλές αλλαγές κώδικα στο αποθετήριο.

Η προτροπή για συντρίβεται behaviuor είναι να δημιουργήσει throughput σε αυτό το σύστημα - μεταφοράς υποδοχή δεδομένων, τα οποία munged σε μια εσωτερική αναπαράσταση. Έχω ένα σύνολο δεδομένων δοκιμής που θα προκαλέσει περιοδικά την εφαρμογή για εξαίρεση (διάφορα σημεία, διάφορες αιτίες - συμπεριλαμβανομένων σωρό αΐΐοο άλλως, έτσι: η διαφθορά σωρού).

Η συμπεριφορά φαίνεται να σχετίζονται με την δύναμη της CPU ή το εύρος ζώνης της μνήμης? η πιο καθενός η μηχανή έχει, τόσο πιο εύκολο είναι να συντριβή. Απενεργοποίηση μια υπερ-threading πυρήνα ή ένα διπλού πυρήνα πυρήνα μειώνει τον ρυθμό (αλλά δεν εξαλείφει) διαφθορά. Αυτό υποδηλώνει ένα θέμα σχετικό χρονοδιάγραμμα.

Τώρα εδώ είναι το πρόβλημα:
Όταν είναι τρέχει σε περιβάλλον ελαφρύ debug (ας πούμε Visual Studio 98 / AKA MSVC6) η αλλοίωση σωρού είναι αρκετά εύκολο να αναπαραχθούν - δέκα ή δεκαπέντε λεπτά περνούν πριν κάτι αποτύχει τρομερά και εξαιρέσεις, όπως ένα alloc;όταν τρέχει κάτω από ένα εκλεπτυσμένο περιβάλλον εντοπισμού σφαλμάτων (Rational καθαρίζονται, VS2008/MSVC9ή ακόμα και Microsoft Application ελέγχου) το σύστημα γίνεται δεσμευμένη μνήμη ταχύτητας και δεν συντριβή (μνήμη-δεσμεύεται: CPU δεν παίρνει παραπάνω 50%, το φως δίσκος δεν είναι ενεργοποιημένη, το πρόγραμμα πρόκειται όσο πιο γρήγορα μπορεί, κιβώτιο καταναλώνει 1.3Gτων 2G μνήμη RAM) . Έτσι, έχω μια επιλογή μεταξύ του να είναι σε θέση να αναπαράγει το πρόβλημα (αλλά όχι προσδιορίσει την αιτία) ή να είναι σε θέση να idenify την αιτία ή ένα πρόβλημα που δεν μπορούν να αναπαραχθούν.

τρέχουσες καλύτερες εκτιμήσεις μου για το πού να επόμενο είναι:

  1. Πάρτε μια εξωφρενικά Γκράντι παράθυρο (για να αντικαταστήσει το τρέχον πλαίσιο dev: 2Gb RAM σε ένα E6550 Core2 Duo)? Αυτό θα καταστήσει δυνατή την repro τη συντριβή προκαλώντας κακή συμπεριφορά κατά την εκτέλεση κάτω από ένα ισχυρό περιβάλλον debug? ή
  2. Ξαναγράψτε φορείς newκαι deleteνα χρησιμοποιούν VirtualAllocκαι VirtualProtectνα σηματοδοτήσει τη μνήμη μόνο για ανάγνωση από τη στιγμή που έχει γίνει με. Εκτελέστε κάτω MSVC6και να έχουν το λειτουργικό σύστημα πιάσει το κακό-τύπος που γράφει για να ελευθερωθεί μνήμη. Ναι, αυτό είναι ένα σημάδι της απελπισίας: ποιοι είναι οι επανεγγραφές κόλαση newκαι delete;! Αναρωτιέμαι αν αυτό πρόκειται να γίνει ως αργά το πλαίσιο Καθαρίστε et al.

Και, όχι: Αποστολές με Καθαρίστε όργανα ενσωματωμένο δεν αποτελεί επιλογή.

Ένας συνάδελφος περπάτησε μόνο παρελθόν και ρώτησε «Υπερχείλιση στοίβας; Μήπως να πάρει στοίβα υπερχειλίσεις τώρα;!;»

Και τώρα, το ερώτημα: Πώς μπορώ να εντοπίσω τη δωροδοκία σωρό;


Ενημέρωση: εξισορρόπηση new[]και delete[]φαίνεται να έχει πάρει σε μεγάλο βαθμό στην επίλυση του προβλήματος. Αντί για 15 λεπτά, η εφαρμογή πηγαίνει τώρα περίπου δύο ώρες πριν από τη συντριβή. Δεν υπάρχουν ακόμα. Οποιεσδήποτε περαιτέρω προτάσεις; Η διαφθορά εξακολουθεί να σωρού.

Ενημέρωση: συσσώρευση απελευθέρωση κάτω από το Visual Studio 2008 φαίνεται δραματικά καλύτερα? τρέχουσα υποψία στηρίζεται στην STLεφαρμογή ότι τα πλοία με το VS98.


  1. Αναπαράγουν το πρόβλημα. Dr Watsonθα παράγει μία χωματερή που μπορεί να είναι χρήσιμη για περαιτέρω ανάλυση.

Θα πάρω ένα σημείωμα από αυτό, αλλά είμαι ανησυχούν ότι ο Δρ Watson θα ενεργοποιηθεί μόνο μετά το γεγονός, όχι όταν ο σωρός παίρνει πατούσαν επάνω.

Μια άλλη δοκιμή μπορεί να χρησιμοποιούν WinDebugως εργαλείο εντοπισμού σφαλμάτων το οποίο είναι αρκετά ισχυρό να είναι ταυτόχρονα και ελαφρύ.

Πήρε ότι πρόκειται αυτή τη στιγμή, και πάλι: όχι πολύ βοήθεια έως ότου κάτι πάει στραβά. Θέλω να πιάσει το βανδαλισμούς στην πράξη.

Ίσως αυτά τα εργαλεία θα σας επιτρέψει τουλάχιστον να περιορίσετε το πρόβλημα σε ορισμένες συνιστώσα.

Δεν έχω πολλές ελπίδες, αλλά δύσκολοι καιροί απαιτούν ...

Και να είστε σίγουροι ότι όλα τα στοιχεία του έργου έχουν σωστές ρυθμίσεις βιβλιοθήκη χρόνου εκτέλεσης ( C/C++ tabκατηγορίας Κωδικός Παραγωγής στην VS ρυθμίσεις 6.0 του έργου);

Όχι δεν είμαι, και θα περάσετε μια-δυο ώρες αύριο να περάσει από το χώρο εργασίας (58 έργα σε αυτό) και ο έλεγχος είναι όλοι κατάρτιση και τη σύνδεση με τις κατάλληλες σημαίες.


Ενημέρωση: Το πήρε 30 δευτερόλεπτα. Επιλογή όλων των έργων στο Settingsπαράθυρο διαλόγου, καταργήστε την επιλογή μέχρι να βρείτε το έργο (α) που δεν έχουν τις σωστές ρυθμίσεις (που όλοι είχαν τις σωστές ρυθμίσεις).

Δημοσιεύθηκε 04/08/2008 στις 08:30
πηγή χρήστη
Σε άλλες γλώσσες...                            


15 απαντήσεις

ψήφοι
0

Θα δοκιμάσει παλιά χτίζει, αλλά είναι ένας λόγος που δεν μπορούμε να συνεχίσουμε πιο πίσω στην ιστορία αποθετήριο και να δει πότε ακριβώς καθιερώθηκε το bug υπάρχει;

Σε αντίθετη περίπτωση, θα ήθελα να προτείνω την προσθήκη απλή καταγραφή κάποιου είδους για να εντοπίσουμε το πρόβλημα, αν και είμαι σε μια απώλεια για το τι συγκεκριμένα μπορεί να θέλετε να συνδεθείτε.

Αν μπορείτε να μάθετε τι ακριβώς μπορεί να προκαλέσει αυτό το πρόβλημα, μέσω της google και τεκμηρίωση των εξαιρέσεων που παίρνετε, ίσως αυτό θα δώσει περισσότερη γνώση για το τι πρέπει να αναζητήσουμε στον κώδικα.

Απαντήθηκε 04/08/2008 στις 08:48
πηγή χρήστη

ψήφοι
26

Η πρώτη μου επιλογή θα ήταν ένα ειδικό εργαλείο σωρό όπως pageheap.exe .

Ξαναγράφοντας νέα και διαγραφή θα μπορούσε να είναι χρήσιμη, αλλά αυτό δεν πιάσει το allocs που διαπράχθηκαν από τον κωδικό χαμηλότερου επιπέδου. Εάν αυτό είναι ό, τι θέλετε, καλύτερα να Detour τα low-level alloc APIs χρησιμοποιώντας το Microsoft Παρακάμψεις.

Επίσης ελέγχους υγιούς λειτουργίας όπως: επαλήθευση βιβλιοθήκες χρόνου εκτέλεσης σας αγώνα (απελευθέρωση έναντι debug, multi-threaded εναντίον του μονού νήματος, DLL εναντίον στατική lib), αναζητήστε κακή διαγραφές (π.χ., διαγράψτε, όπου delete [] θα έπρεπε να είναι μεταχειρισμένα), βεβαιωθείτε ότι δεν είστε μίξη και το ταίριασμα allocs σας.

Επίσης, προσπαθήστε επιλεκτικά να απενεργοποιήσετε τα θέματα και να δούμε πότε / αν το πρόβλημα πηγαίνει μακριά.

Τι σημαίνει η στοίβα κλήσεων κλπ μοιάζουν κατά το χρόνο της πρώτης εξαίρεση;

Απαντήθηκε 04/08/2008 στις 08:51
πηγή χρήστη

ψήφοι
0

Η πρώτη μου ενέργεια θα έχει ως εξής:

  1. Φτιάξτε τα δυαδικά αρχεία στο «Release» έκδοση, αλλά η δημιουργία debug πληροφορίες του αρχείου (θα βρείτε αυτή τη δυνατότητα στις ρυθμίσεις του σχεδίου).
  2. Χρησιμοποιήστε Dr Watson ως defualt πρόγραμμα εντοπισμού σφαλμάτων (Drwtsn32 -Ι) σε ένα μηχάνημα στο οποίο θέλετε να αναπαράγετε το πρόβλημα.
  3. Repdroduce το πρόβλημα. Dr Watson θα παράγει μια χωματερή που μπορεί να είναι χρήσιμη για περαιτέρω ανάλυση.

Μια άλλη δοκιμή μπορεί να είναι με τη χρήση WinDebug ως εργαλείο εντοπισμού σφαλμάτων το οποίο είναι αρκετά ισχυρό να είναι ταυτόχρονα και ελαφρύ.

Ίσως αυτά τα εργαλεία θα σας επιτρέψει τουλάχιστον να περιορίσετε το πρόβλημα σε ορισμένες συνιστώσα.

Και να είστε σίγουροι ότι όλα τα στοιχεία του έργου έχουν σωστές ρυθμίσεις βιβλιοθήκη χρόνου εκτέλεσης (καρτέλα C / C ++, κατηγορίας Κωδικός Παραγωγής στην VS ρυθμίσεις 6.0 του έργου);

Απαντήθηκε 04/08/2008 στις 09:26
πηγή χρήστη

ψήφοι
11

Έχω ίδια προβλήματα στη δουλειά μου (που επίσης χρησιμοποιούν VC6μερικές φορές). Και δεν υπάρχει εύκολη λύση για αυτό. Έχω μόνο μερικές συμβουλές:

  • Δοκιμάστε με αυτόματο crash χωματερές σε μηχανή παραγωγής (βλ Dumper διαδικασία της ). Η εμπειρία μου λέει ο Δρ Watson είναι δεν είναι τέλεια για το ντάμπινγκ.
  • Κατάργηση όλων των αλιευμάτων (...) από τον κώδικά σας. Συχνά κρύβουν σοβαρές εξαιρέσεις μνήμης.
  • Ελέγξτε για προχωρημένους των Windows Debugging - υπάρχουν πολλές μεγάλες συμβουλές για προβλήματα όπως η δική σας. Θα ήθελα να συστήσω αυτό με όλη μου την καρδιά.
  • Εάν χρησιμοποιείτε το STLδοκιμάσετε STLPortκαι να ελέγχεται χτίζει. Μη έγκυρη iterator είναι κόλαση.

Καλή τύχη. Προβλήματα όπως η δική σας να μας πάρει μήνες για να λύσει. Να είστε έτοιμοι για αυτό ...

Απαντήθηκε 06/08/2008 στις 13:41
πηγή χρήστη

ψήφοι
1

Έτσι, από το περιορισμένες πληροφορίες που έχετε, αυτό μπορεί να είναι ένας συνδυασμός από ένα ή περισσότερα πράγματα:

  • Κακή χρήση του σωρού, δηλαδή, διπλά ελευθερώνει, διαβάστε μετά από δωρεάν, γράφουν μετά από δωρεάν, θέτοντας τη σημαία HEAP_NO_SERIALIZE με εκχώρησης και ελεύθερων από πολλαπλά threads στο ίδιο σωρό
  • Μη διαθέσιμη μνήμη
  • Bad κώδικα (δηλαδή, υπερχειλίσεις μνήμης, ρυθμιστικό υποχείλιση, κλπ)
  • θέματα «Timing»

Αν είναι καθόλου οι δύο πρώτες, αλλά όχι το τελευταίο, θα πρέπει να έχουν αλιευθεί από τώρα είτε pageheap.exe.

Ποια πιθανότατα σημαίνει ότι αυτό οφείλεται στο πώς ο κώδικας έχει πρόσβαση κοινόχρηστη μνήμη. Δυστυχώς, η παρακολούθηση που προβλέπονται πρόκειται να είναι αρκετά επώδυνη. Μη συγχρονισμένη πρόσβαση σε κοινόχρηστη μνήμη εκδηλώνεται συχνά παράξενα θέματα «χρονοδιάγραμμα». Τα πράγματα όπως το να μην χρησιμοποιούν τη σημασιολογία αποκτούν / θέση σε συγχρονισμό πρόσβαση σε κοινόχρηστη μνήμη με μια σημαία, που δεν χρησιμοποιούν κλειδαριές κατάλληλα, κ.λπ.

Τουλάχιστον, αυτό θα βοηθήσει να είναι σε θέση να παρακολουθούν κατανομές κατά κάποιο τρόπο, όπως προτάθηκε νωρίτερα. Τουλάχιστον τότε μπορείτε να δείτε τι πραγματικά συνέβη μέχρι την αλλοίωση σωρού και να προσπαθήσει να διαγνώσει από αυτό.

Επίσης, αν μπορείτε εύκολα να ανακατευθύνει κονδύλια σε πολλούς σωρούς, μπορεί να θέλετε να δοκιμάσετε αυτό για να δούμε αν αυτό είτε διορθώνει το πρόβλημα ή τα αποτελέσματα σε περισσότερες αναπαραχθούν συμπεριφορά λάθη.

Όταν οι δοκιμές με το VS2008, δεν θα τρέξει με HeapVerifier με εξοικονόμηση μνήμης οριστεί σε Ναι; Αυτό θα μπορούσε να μειώσει την επίδραση στην απόδοση του κατανεμητή του σωρού. (Πλέον, θα πρέπει να τρέξει με αυτό Debug-> Ξεκινήστε με αίτηση ελέγχου, αλλά ίσως ήδη γνωρίζετε ότι.)

Μπορείτε επίσης να δοκιμάσετε τον εντοπισμό σφαλμάτων με Windbg και διάφορες χρήσεις της εντολής σωρό!.

MSN

Απαντήθηκε 22/08/2008 στις 17:51
πηγή χρήστη

ψήφοι
7

Είχαμε αρκετά καλή τύχη, γράφοντας τη δική μας malloc και δωρεάν λειτουργίες. Στην παραγωγή, απλά καλέστε το πρότυπο malloc και δωρεάν, αλλά σε debug, μπορούν να κάνουν ό, τι θέλουν. Έχουμε επίσης μια απλή βασική κλάση που δεν κάνει τίποτα, αλλά υπερισχύει το νέο και να διαγράψετε τους φορείς εκμετάλλευσης να χρησιμοποιήσετε αυτές τις λειτουργίες, τότε οποιαδήποτε κατηγορία που γράφετε μπορεί απλά να κληρονομήσουν από αυτή την κατηγορία. Εάν έχετε έναν τόνο του κώδικα, μπορεί να είναι μια μεγάλη δουλειά για να αντικαταστήσει κλήσεις σε malloc και δωρεάν για το νέο malloc και δωρεάν (μην ξεχνάτε realloc!), Αλλά μακροπρόθεσμα είναι πολύ χρήσιμη.

Στο βιβλίο του Steve του Maguire Γράφοντας Στερεά Κώδικα (συνιστάται ιδιαίτερα), υπάρχουν παραδείγματα εντοπισμού σφαλμάτων πράγματα που μπορείτε να κάνετε σε αυτές τις ρουτίνες, όπως:

  • Παρακολουθήστε τις χορηγήσεις να βρείτε τις διαρροές
  • Διαθέστε περισσότερη μνήμη από ό, τι είναι απαραίτητο και να θέσει δείκτες στην αρχή και στο τέλος της μνήμης - κατά τη διάρκεια της ελεύθερης ρουτίνα, μπορείτε να εξασφαλίσετε αυτοί οι δείκτες είναι ακόμα εκεί
  • memset τη μνήμη με ένα δείκτη για την κατανομή (για να βρείτε τη χρήση της δεν έχει προετοιμαστεί μνήμης) και σχετικά με την ελεύθερη (για να βρείτε τη χρήση της free'd μνήμης)

Μια άλλη καλή ιδέα είναι να μην χρησιμοποιείτε τα πράγματα όπως strcpy, strcatή sprintf- να χρησιμοποιείτε πάντα strncpy, strncatκαι snprintf. Έχουμε γράψει τη δική μας εκδόσεις από αυτά, καθώς, για να βεβαιωθείτε ότι δεν διαγραφεί το τέλος ενός ρυθμιστικού, και αυτά έχουν αλιευθεί πολλά προβλήματα.

Απαντήθηκε 22/08/2008 στις 18:11
πηγή χρήστη

ψήφοι
3

Η φαινομενική τυχαιότητα της διαφθοράς μνήμης ακούγεται πολύ σαν ένα θέμα συγχρονισμού νήμα - ένα bug αναπαράγεται ανάλογα με την ταχύτητα της μηχανής. Αν τα αντικείμενα (chuncks της μνήμης) επιμερίζεται μεταξύ των νημάτων και το συγχρονισμό (κρίσιμο τμήμα, mutex, σηματοφόρος, και άλλα) πρωτόγονων δεν είναι σε ανά κατηγορία (ανά αντικείμενο, ανά κατηγορία) βάση, τότε είναι δυνατόν να έρθει σε μια κατάσταση όπου κατηγορία (κομμάτι της μνήμης) διαγράφεται / ελευθερώνεται κατά τη χρήση, ή να χρησιμοποιηθεί μετά από διαγραφή / απελευθερωθεί.

Ως ένα τεστ γι 'αυτό, θα μπορούσατε να προσθέσετε πρωτόγονων συγχρονισμός σε κάθε τάξη και μέθοδο. Αυτό θα κάνει πιο αργό τον κωδικό σας, γιατί πολλά αντικείμενα θα πρέπει να περιμένουμε για τον άλλον, αλλά αν αυτό εξαλείφει την αλλοίωση σωρού, το πρόβλημα σωρού της διαφθοράς σας θα γίνει ένα κώδικα βελτιστοποίησης ένα.

Απαντήθηκε 25/08/2008 στις 20:55
πηγή χρήστη

ψήφοι
0

πρόταση Graeme της συνήθειας malloc / δωρεάν είναι μια καλή ιδέα. Δείτε αν μπορείτε να χαρακτηρίσουν κάποιο σχέδιο για τη διαφθορά για να σας δώσει μια λαβή για τη μόχλευση.

Για παράδειγμα, αν είναι πάντα σε ένα μπλοκ του ίδιου μεγέθους (ας πούμε 64 bytes) στη συνέχεια, αλλάξτε malloc / δωρεάν ζεύγος σας για να διαθέσει πάντα 64 κομμάτια byte στη δική τους σελίδα. Όταν απελευθερώσει ένα κομμάτι 64 byte στη συνέχεια, ορίστε τα κομμάτια προστασία της μνήμης σε αυτή τη σελίδα για να αποτρέψει διαβάζει και wites (χρησιμοποιώντας VirtualQuery). Στη συνέχεια, ο καθένας προσπαθεί να αποκτήσετε πρόσβαση σε αυτήν τη μνήμη, θα δημιουργήσει μια εξαίρεση και όχι διαφθείρει το σωρό.

Αυτό δεν υποθέσουμε ότι ο αριθμός των εκκρεμών κομμάτια 64 byte είναι μόνο μέτρια ή έχετε πολλή μνήμη για να κάψει το κουτί!

Απαντήθηκε 02/09/2008 στις 05:23
πηγή χρήστη

ψήφοι
3

Είναι αυτό σε συνθήκες χαμηλού μνήμη; Αν ναι θα μπορούσε να είναι ότι οι νέες επιστρέφει NULLαντί να ρίχνουν std :: bad_alloc. Παλαιότερα VC++compilers δεν εφάρμοσε σωστά αυτό. Υπάρχει ένα άρθρο για Legacy αποτυχίες εκχώρησης μνήμης συντριβή STLεφαρμογές χτισμένο με VC6.

Απαντήθηκε 02/09/2008 στις 07:03
πηγή χρήστη

ψήφοι
8

Εκτελέστε την αρχική αίτηση με ADplus -crash -pn appnename.exe Όταν το θέμα της μνήμης σκάει-up θα πάρετε μια ωραία μεγάλη χωματερή.

Μπορείτε να αναλύσετε την χωματερή για να καταλάβουμε ποια θέση μνήμης ήταν κατεστραμμένο. Αν είστε τυχεροί η αντικατάστασης της μνήμης είναι μια μοναδική ταινία που μπορείτε να καταλάβετε από πού προήλθε. Αν δεν είστε τυχεροί, θα πρέπει να σκάψουν σε win32σωρό και να καταλάβω ποια ήταν τα orignal χαρακτηριστικά μνήμης. (σωρός-χ θα μπορούσε να βοηθήσει)

Αφού ξέρετε τι μπέρδεμα-up, μπορείτε να περιορίσετε appverifier χρήση με ειδικές ρυθμίσεις σωρό. δηλαδή μπορείτε να καθορίσετε τι DLLσας παρακολουθεί, ή τι μέγεθος κατανομής για την παρακολούθηση.

Ας ελπίσουμε ότι αυτό θα επιτάχυνση της παρακολούθησης αρκετά για να πιάσει τον ένοχο.

Σύμφωνα με την εμπειρία μου, εγώ ποτέ δεν χρειάζεται πλήρη λειτουργία σωρό ελεγκτή, αλλά πέρασα πολύ χρόνο αναλύοντας τη χωματερή (ες) συντριβή και πηγές περιήγηση.

PS: Μπορείτε να χρησιμοποιήσετε DebugDiag να αναλύσει τις χωματερές. Μπορεί να επισημάνω την DLLιδιοκτησία το κατεστραμμένο σωρό, και να σας δώσει άλλες λεπτομέρειες χρήσιμο.

Απαντήθηκε 16/09/2008 στις 08:33
πηγή χρήστη

ψήφοι
1

Αν επιλέξετε να ξαναγράψει νέα / διαγραφή, έχω κάνει αυτό και έχουν απλή πηγαίο κώδικα σε:

http://gandolf.homelinux.org/~smhanov/blog/?id=10

Αυτό πιάνει διαρροές μνήμης και εισάγει επίσης στοιχεία φρουρά πριν και μετά το μπλοκ μνήμης για να συλλάβει τη διαφθορά σωρού. Μπορείτε απλά να ενσωματωθούν με την βάζοντας #include «Debug.h» στην κορυφή της κάθε αρχείο CPP, και τον καθορισμό DEBUG και DEBUG_MEM.

Απαντήθηκε 17/09/2008 στις 14:40
πηγή χρήστη

ψήφοι
4

Θα πρέπει να επιτεθεί αυτό το πρόβλημα τόσο με το χρόνο εκτέλεσης και στατική ανάλυση.

Για στατική ανάλυση εξετάζει την κατάρτιση με PREfast ( cl.exe /analyze). Ανιχνεύει παράταιρα deleteκαι delete[], υπερβάσεις ρυθμιστικό διάλυμα και μια σειρά από άλλα προβλήματα. Να είστε έτοιμοι, όμως, να εντρυφήσω μέσα από πολλές kilobytes της προειδοποίησης L6, ειδικά αν το έργο σας έχει ακόμη L4δεν είναι σταθερό.

PREfast είναι διαθέσιμη με το Visual Studio σύστημα της ομάδας και, προφανώς , ως μέρος των Windows SDK.

Απαντήθηκε 12/10/2008 στις 22:55
πηγή χρήστη

ψήφοι
0

Το λίγο χρόνο που είχα για να λύσει ένα παρόμοιο πρόβλημα. Αν το πρόβλημα εξακολουθεί να υφίσταται σας προτείνω να το κάνετε αυτό: Παρακολουθήστε όλες τις κλήσεις σε νέες / διαγράψετε και malloc / calloc / realloc / δωρεάν. Κάνω μόνο DLL εξαγωγή μια λειτουργία για το μητρώο όλων των κλήσεων. Η λειτουργία αυτή λαμβάνει η παράμετρος για τον προσδιορισμό του πηγαίου κώδικα σας, το δείκτη να διατεθεί περιοχή και το είδος της εξοικονόμησης αυτές τις πληροφορίες σε έναν πίνακα κλήσεων. Όλα κατανέμονται / απελευθέρωσε ζεύγος αποβάλλεται. Στο τέλος ή μετά θα πρέπει να κάνετε μια κλήση σε μια άλλη λειτουργία για να δημιουργήσετε αναφορά για το αριστερό δεδομένων. Με αυτό μπορείτε να αναγνωρίσετε λάθος κλήσεις (νέα / δωρεάν ή malloc / διαγραφή) ή λείπει. Αν έχετε οποιαδήποτε περίπτωση ρυθμιστικού αντικατασταθούν στον κώδικά σας οι πληροφορίες αποθηκεύονται μπορεί να είναι λάθος, αλλά κάθε τεστ μπορεί να ανιχνεύσει / ανακαλύψει / περιλαμβάνουν μία λύση της αποτυχίας εντοπίζονται. Πολλοί τρέχει να βοηθήσει στον εντοπισμό των σφαλμάτων. Καλή τύχη.

Απαντήθηκε 19/12/2008 στις 12:52
πηγή χρήστη

ψήφοι
0

Πιστεύετε ότι αυτή είναι μια κατάσταση κούρσας; Τα πολλαπλά threads που μοιράζονται ένα σωρό; Μπορείτε να δώσετε σε κάθε νήμα ιδιωτικό σωρό με HeapCreate, τότε μπορεί να τρέξει γρήγορα με HEAP_NO_SERIALIZE. Σε αντίθετη περίπτωση, ένας σωρός πρέπει να είναι το νήμα ασφαλής, αν χρησιμοποιείτε το multi-threaded έκδοση των βιβλιοθηκών συστήματος.

Απαντήθηκε 30/07/2009 στις 14:48
πηγή χρήστη

ψήφοι
0

Ένα ζευγάρι από τις προτάσεις. Θα αναφέρω τις άφθονες προειδοποιήσεις σε W4 - θα ήθελα να προτείνω τη λήψη του χρόνου για να διορθώσετε τον κωδικό σας για να συγκεντρώσει καθαρά σε επίπεδο συναγερμού 4 - αυτό θα βοηθήσει σε μεγάλο βαθμό στην πρόληψη λεπτές δύσκολο να βρεθούν σφάλματα.

Δεύτερη - για τον / την ανάλυση διακόπτη - δεν παράγει πραγματικά άφθονη προειδοποιήσεις. Για να χρησιμοποιήσετε αυτόν το διακόπτη στο δικό μου έργο, αυτό που έκανα ήταν να δημιουργήσετε ένα νέο αρχείο κεφαλίδας που χρησιμοποιείται #pragma προειδοποίηση για να απενεργοποιήσετε όλες τις συμπληρωματικές προειδοποιήσεις που δημιουργούνται από / αναλύσουμε. Στη συνέχεια πιο κάτω στο αρχείο, γυρίζω μόνο εκείνες τις προειδοποιήσεις νοιάζει. Στη συνέχεια, χρησιμοποιήστε το διακόπτη / FI compiler για να αναγκάσει το αρχείο κεφαλίδα που πρέπει να περιλαμβάνονται πρώτο σε όλες τις μονάδες συλλογή σας. Αυτό θα σας επιτρέψει να χρησιμοποιήσετε το / την ανάλυση διακόπτη, ενώ ελέγχουν την έξοδο

Απαντήθηκε 03/10/2009 στις 17:48
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more