.NET Framework

Απ: Memory leaks σε managed κώδικα ???

Παναγιώτης Καναβός — Mon, 09 Oct 2006 22:13:53 GMT

Ακόμα και όταν χρησιμοποιείς using, θα υπάρχουν πάντα "καλικάτζαροι" που θα σου κάνουν τη ζωή δύσκολη. Το using είναι καλό όταν δεν σε ενδιαφέρει να επιζήσει η μεταβλητή έξω από το using block. Δεν σε βολεύει όμως όταν θέλεις να καθαρίσεις fields ή static μεταβλητές. Και οπωσδήποτε δεν βοηθάει όταν η μεταβλητή δεν υποστηρίζει το IDisposable. Όπως για παράδειγμα ... οι COM wrappers!

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

Όπως και να το δει κανείς, ένας καλός profiler σε γλυτώνει από πολλούς μπελάδες.

Υ.Γ. Για όποιον θέλει ένα βασικό profiler υπάρχει και ο CLR Profiler 2.0 από τη Microsoft στο http://www.microsoft.com/downloads/thankyou.aspx?familyId=A362781C-3870-43BE-8926-862B40AA0CD0&displayLang=en. Μπορεί να μην έχει όλες τις δυνατότητες και ευκολίες του ANTS, είναι όμως τσάμπα και κάνει τη δουλειά.

Απ: Memory leaks σε managed κώδικα ???

Antonios Chatzipavlis — Mon, 09 Oct 2006 20:01:18 GMT

για αυτό τό λόγο υπάρχει η using στην C# και τώρα υπάρχει και στην νέα vb

ακόμα πέρα από τον ANTS Profiler υπάρχει και ο process Explorer που προσωπικά το έχω βρει αρκέτά εξυπηρετικό ειδικά όταν του βάλεις τις κολώνες για .ΝΕΤ

θα το βρείτε στο http://www.sysinternals.com/Utilities/ProcessExplorer.html

Απ: Memory leaks σε managed κώδικα ???

Dimitris Papadimitriou — Fri, 06 Oct 2006 23:03:19 GMT

KelMan wrote:
Ας πούμε το circular reference στο COM ναι, είναι memory leak γιατί ό,τι και να κάνεις δεν μπορείς να το αποφύγεις.

Τι μου θύμισες τώρα! Σε μια VB6 εφαρμογή για να το αποφύγω αναγκαζόμουν να περνάω τον pointer του αντικειμένου και να το ξαναδημιουργώ! (Ναι, για όσους δεν το ξέρουν, η VB6 μπορεί να κάνει μια απλή διαχείριση pointers) Βέβαια ο κώδικας ήταν προσεκτικός γιατί αν στο μεταξύ το αντικείμενο είχε καταστραφεί και ο κώδικας πήγαινε να χρησιμοποιήσει τον pointer του... το πρόγραμμα εξαφανιζόταν από τα μάτια του χρήστη!

Σίγουρα με τον garbage collector τα πράγματα είναι πιο απλά. Αυτό όμως δεν σημαίνει ότι με το COM reference counting δεν μπορούσες να κάνεις circular references ή ότι ο garbage collector είναι "καφετζού" και ελευθερώνει την μνήμη μαγικά! Άλλωστε και στο σπίτι μας, αν δεν βγάλουμε έξω τα σκουπίδια... τότε απλά δεν θα τα πάρει το συνεργείο καθαριότητας!

Απ: Memory leaks σε managed κώδικα ???

elam — Fri, 06 Oct 2006 21:46:22 GMT

Έχω την εντύπωση ότι ένας τίτλος "tracing memory leaks in .NET applications..." αν μη τι άλλο κατηγορεί τον GC. Με αυτόν τον τρόπο ίσως προσπαθεί να τραβήξει και την προσοχή.

Πέρα από τις ... κατηγορίες όμως, το άρθρο είναι χρήσιμο, -και σ'ευχαριστούμε anjelinio- αφού μαθαίνουμε καλύτερα από τα λάθη.

Όταν, τυχαίνει αυτά τα λάθη να τα κάνουν άλλοι, τότε, ακόμα καλύτερα!

Απ: Memory leaks σε managed κώδικα ???

KelMan — Fri, 06 Oct 2006 21:05:55 GMT

H ένστασή μου (όχι προς τον Anjelinio, προς θεού) είναι ως προς τον όρο "memory leak". Ας πούμε το circular reference στο COM ναι, είναι memory leak γιατί ό,τι και να κάνεις δεν μπορείς να το αποφύγεις. Αλλά αυτό που περιγράφεται στο blog είναι μια αναμενόμενη συμπεριφορά.

Κατά τ'άλλα είναι χρησιμότατο το post ακριβώς για να υπενθυμίζει ότι πάντοτε χρειάζεται προσοχή - και αν θέλετε, καλή γνώση του συστήματος.

Απ: Memory leaks σε managed κώδικα ???

Παναγιώτης Καναβός — Fri, 06 Oct 2006 20:57:56 GMT

Να πω την αλήθεια, δεν βλέπω πουθενά να κατηγορεί ο αρθρογράφος το framework.

Η ζωή χωρίς profiler μπορεί να αποδειχθεί μαρτύριο. Καλά με το managed κώδικα, μπορούμε να είμαστε λίγο τσαπατσούληδες και να αφήνουμε και κανένα reference που και που, ελπίζοντας ότι ο GC θα συμμαζέψει την κατάσταση. Για σκεφτείτε και το interop με COM components. Όπου πρέπει να καθαρίζουμε με το χέρι κάθε reference. Και οι wrappers δεν υποστηρίζουν IDisposable.......

Απ: Memory leaks σε managed κώδικα ???

KelMan — Fri, 06 Oct 2006 20:55:53 GMT

Ναι, σίγουρα. Το ηθικό δίδαγμα είναι ότι πάντοτε χρειάζεται προσοχή και συναίσθηση του τι κάνουμε...

Απ: Memory leaks σε managed κώδικα ???

anjelinio — Fri, 06 Oct 2006 20:48:21 GMT

Either way παιδιά, ακόμη και το απλώς να διαβάσεις την ιστορία είναι αρκετό κατα τη γνώμη μου, εξ' ού και το post εδώ. Αν φταίει ή δε φταίει το framework είναι άσχετο κατα τη γνώμη μου. Το θέμα είναι απλώς οτι αν το δείς κάπου, θα το σκεφτείς μετά στον κώδικα σου :)

Απ: Memory leaks σε managed κώδικα ???

elam — Fri, 06 Oct 2006 20:44:34 GMT

Ο KelMan έχει δίκιο. Ο GC δεν είναι καφετζού για να μαντέψει ότι τα controls που περνάνε στο static ArrayList δεν πρόκειται να ξαναχρησιμοποιηθούν!
Πρόβλημα θα υπήρχε αν γίνονταν τα controls dispose.

Όσον αφορά το Collect, αυτό θυμίζει την παροιμία με το χυλό και το γιαούρτι.

Τελικά, αν δεν σχολιαζόταν το γεγονός με τους event handlers, θα έλεγα ότι πρόκειται για ... διαφήμιση του ANTS Profiler!

Απ: Memory leaks σε managed κώδικα ???

KelMan — Fri, 06 Oct 2006 20:10:53 GMT

Χμμμ... Memory leak? Φταίει ο managed κώδικας αν ο τύπος όρισε static ArrayList και δεν φρόντισε να το αδειάζει; Το managed περιβάλλον κάνει αυτό που πρόκειται να κάνει, θα κάνει deallocate όταν δεν υπάρχει reference στο ArrayList, δηλαδή όταν κλείσει την εφαρμογή. Θα το έλεγα memory leak αν δεν ελευθερόνονταν η μνήμη αφού έκλεινε η εφαρμογή...

OK, το δεύτερο με τους event handlers είναι ένα θέμα και το έχουμε πει ότι χρειάζεται προσοχή... Αλλά και πάλι, GC.Collect?!?!

Memory leaks σε managed κώδικα ???

anjelinio — Fri, 06 Oct 2006 19:37:13 GMT

"Κάποτε ήταν πολύ εύκολο να εισάγουμε memory leaks στο πρόγραμμά μας, γράφοντας σε C / C++. Οι περισσότεροι πιστεύουμε οτι στον managed πλέον κόσμο, το memory leak είναι απλώς ... non-issue". Λάθος !

Στο συγκεκριμένο blog post, ο κύριος Mike Bloise εξιστορεί τη memory leaked εμπειρία του, καθώς και τη χρήση του ANTS Profiler για να βρεί τη λύση στο πρόβλημά του. Πολύ ενδιαφέρον διάβασμα, ίσως ταρακουνήσει πολλούς απο 'μας να ξανασκεφτούν κάποια πράγματα για τον κώδικά μας :)