Η φύση του προβλήματος: Unbounded disk growth
Σύμφωνα με αναφορές στο GitHub, η desktop εφαρμογή του Codex παρουσιάζει ένα κρίσιμο σφάλμα στη διαχείριση των crash reports. Το εργαλείο Crashpad, το οποίο χρησιμοποιείται για τη συλλογή δεδομένων μετά από μια κατάρρευση, ξεκινά να παράγει ανεξέκλεπτα ζεύγη αρχείων .dmp και _sidecar.json στον κατάλογο ~/Library/Application Support/com.openai.codex/web/Crashpad/pending.
Η κλιμάκωση του προβλήματος είναι τρομακτική: χρήστες ανέφεραν αύξηση από μερικά megabytes σε πάνω από 50GB μέσα σε ελάχιστο χρόνο, με ρυθμούς παραγωγής αναφορών που αγγίζουν το ένα report ανά δευτερόλεπτο. Παρά το γεγονός ότι η εφαρμογή παραμένει λειτουργική για τον χρήστη, το background process καταναλώνει τους πόρους του συστήματος χωρίς περιορισμό (unbounded growth).
Τεχνική ανάλυση: Το crash loop του handler
Η βαθύτερη ανάλυση των logs αποκαλύπτει ότι το ίδιο το βοηθητικό process, το browser_crashpad_handler, αντιμετωπίζει fatal errors. Συγκεκριμένα, εμφανίζεται το μήνυμα: mach_port_request_notification: (os/kern) invalid capability (20).
Αυτό υποδηλώνει μια αποτυχία επικοινωνίας σε επίπεδο kernel (mach ports) στο macOS, η οποία προκαλεί την κατάρρευση του ίδιου του handler. Επειδή ο handler είναι υπεύθυνος για την καταγραφή των καταρρεύσεων, η δική του κατάρρευση πυροδοτεί τη δημιουργία ενός νέου dump, δημιουργώντας έτσι έναν ατέρμονα κύκλο (infinite loop) που γεμίζει τον δίσκο.
Workarounds και προσωρινές λύσεις
Επειδή η εφαρμογή δεν επιτρέπει εύκολη τροποποίηση των αρχείων της στο /Applications, οι χρήστες αναγκάζονται να χρησιμοποιήσουν ακραίες μεθόδους για να σταματήσουν την καταστροφή του αποθηκευτικού χώρου.
Μια αποτελεσματική μέθοδος είναι η μετατροπή της κατάθεσης (directory) του Crashpad σε read-only χρησιμοποιώντας τις εντολές chflags nouchg και chmod 555. Αυτό εμποδίζει τη διεργασία από το να γράψει νέα αρχεία, σταματώντας την αύξηση του όγκου δεδομένων, αν και ουσιαστικά απενεργοποιεί τη δυνατότητα αποστολής πραγματικών crash reports στην OpenAI.
Συμπέρασμα για developers
Το περιστατικό αποτελεί ένα κλασικό παράδειγμα του πώς ένα mechanism error (error handling mechanism) μπορεί να μετατραπεί σε ένα catastrophic failure για το σύστημα του χρήστη. Για τους μηχανικούς που αναπτύσσουν desktop εφαρμογές μέσω Electron ή Chromium, η σωστή διαχείριση του lifecycle των helper processes και η θέσπιση ορίων (bounds) στο μέγεθος των logs και των dumps είναι απαραίτητη για την υγεία του client-side environment.