Προβλήματα GDB+segmentation faults

[kfoynt]

Καλησπέρα!

 

Σήμερα έφαγα κυριολεκτικά όλη μου την μέρα στο debugging, έπειτα απο 15 ώρες πάνω απο το πισι, παρατήρησα ότι υπάρχει μία μεταβλητή στον κώδικα που ειναι "nan". Αυτή η μεταβλητή βρίσκεται μέσα σε μία ρουτίνα. Το θέμα ειναι, οτι κάθε φορα που περνάω γραμμή-γραμμή τον κώδικα με τον gdb, η μεταβλητή παίρνει κανονικά την τιμή της, αν όμως περάσω πάνω από όλη την ρουτίνα χωρις να μπω μέσα, τότε η μεταβλητή παίρνει τιμή "nan", το ίδιο συμβαίνει και άμα τρέξω το πρόγραμμα κανονικά εκτός gdb.

 

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

ίσως μπορώ να ανεβάσω κάποια μικρά κομματάκια, αλλαγμένα, αλλά το project ειναι αρκετά μεγάλο και δεν νομίζω να βοηθούσε, anw, αν κάποιος νομιζει οτι ειναι αναγκαιο ας το πει

 

 

Ο κώδικας ειναι ένας συνδυασμός Fortran + C, το πρόβλημα εμφανίζεται στο κώδικα που ειναι γραμμένος σε fortran.

 

Ευχαριστώ!

[V.I.Smirnov]

Eίναι τελείως αόριστο αυτό που λες. Αν δεν δούμε κώδικα δεν μπορούμε να απαντήσουμε συγκεκριμένα.

 

Προφανώς η μεταβλητή αποτιμάται λανθασμένα.

Ίσως ο υπολογισμός της εμπλέκει κάποιες μεταβλητές από τον C κώδικα που δεν μεταφέρονται σωστά.

 

Εξάλλου, η μεταβλητή που αναφέρεις ίσως να μην μπορεί να ανιχνευτεί από το GDB έξω από την ρουτίνα που χρησιμοποιείται οπότε το GDΒ δεν την βλέπει έξω από αυτήν,

της δίνει NaN φυσιολογικά και το σφάλμα να είναι αλλού...

 

Αν αποκλειστεί το παραπάνω, τo γεγονός ότι περνάς από την ρουτίνα χωρίς να μπεις μέσα και τότε δίνει σφάλμα δείχνει ότι η ρουτίνα μάλλον δεν εκτελείται ή δεν εκτελείται όπως περιμένεις.

Πρέπει καταρχήν να είσαι σίγουρος ότι το debugging και η εκτέλεση του προγράμματος γίνονται με τις ίδιες ρυθμίσεις του compiler ώστε να έχουν την ίδια συμπεριφορά.

Αν δεν μπορείς να το ελέγξεις αυτό (το GDB δεν είναι ότι καλύτερο), άσε το debugging με το GDB. Βάλε print ενδιαμέσως για να δεις τι γίνεται.

 

Παρεμπιπτόντως, η Fortran τιμές όπως signed infinity, NaN, denormalized numbers μπορεί να τις χειριστεί μια χαρά

όταν προκύπτουν φυσιολογικά σε πράξεις (ανάλογα και με τις ρυθμίσεις του compiler).

[dop]

Μια χαρά είναι ο gdb - δεν είναι ο πιο εύχρηστος, αλλά την δουλειά του την κάνει.

 

Άμα δεν είσαι μέσα στη ρουτίνα ( αλήθεια σε τι γλώσσα είναι; ), τότε αν είναι αυτόματη μεταβλητή, δεν υποχρεούται να έχει τιμή που να έχει νόημα. Αυτό φυσικά δεν ισχύει για μεταβλητές static.

 

Ο κώδικας γίνεται compile με -Ο0 -g ;

[V.I.Smirnov]

Δεν διάβασες τι γράφει ;

"...το πρόβλημα εμφανίζεται στο κώδικα που ειναι γραμμένος σε fortran..."

 

Όσο για τον GDB, για debugging σε μικτό προγραμματισμό, breakpoints υπό συνθήκες, ευκολία στον χειρισμό των

ιδιοτήτων για τον compiler κλπ που προφανώς απαιτούνται στο project του kfoynt, ο GDB ΔΕΝ είναι ότι καλύτερο...

[kfoynt]

Καταρχήν, ευχαριστώ!

 

Όχι δεν χρεισιμοποιω -g και -O2 ή οποιαδήποτε παράμετρο για optimization.

 

Μάλλον θα αρχίσω τα print statements παντού και ο θεος βοηθός...

Όσο για τον debugger, ένα βασικό πρόβλημα είναι ότι έχω μέσα και mexFunctions γιατι τραβάω fast fourier συναρτήσεις από το matlab. Έκανα βλακεία απο την αρχή και αντί να χρησιμοποιήσω matlab engine για να μπορώ να τρέχω το εκτελέσιμο εκτός matlab, χρησιμοποίησα mexFunction (είναι αντικατάστατο της main) και αναγκάζομαι και το τρέχω μέσω matlab.

 

Επίσης και ο gdb ανοίγει μέσω matlab, με ./matlab -Dgdb, το καλό είναι οτί αντί για -Dgdb μπορώ να το ανοίξω με κάποιον άλλο debugger -D"my debugger". Οπότε, αν γνωρίζετε κανενα καλύτερο πείτε μου να δοκιμάσω μήπως και κάνω καλύτερη δουλεια.

[m1cRo]

Καταρχήν, ευχαριστώ!

 

Όχι δεν χρεισιμοποιω -g και -O2 ή οποιαδήποτε παράμετρο για optimization.

 

Μάλλον θα αρχίσω τα print statements παντού και ο θεος βοηθός...

Όσο για τον debugger, ένα βασικό πρόβλημα είναι ότι έχω μέσα και mexFunctions γιατι τραβάω fast fourier συναρτήσεις από το matlab. Έκανα βλακεία απο την αρχή και αντί να χρησιμοποιήσω matlab engine για να μπορώ να τρέχω το εκτελέσιμο εκτός matlab, χρησιμοποίησα mexFunction (είναι αντικατάστατο της main) και αναγκάζομαι και το τρέχω μέσω matlab.

 

Επίσης και ο gdb ανοίγει μέσω matlab, με ./matlab -Dgdb, το καλό είναι οτί αντί για -Dgdb μπορώ να το ανοίξω με κάποιον άλλο debugger -D"my debugger". Οπότε, αν γνωρίζετε κανενα καλύτερο πείτε μου να δοκιμάσω μήπως και κάνω καλύτερη δουλεια.

 

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

[kfoynt]

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

 

H ρουτίνα είναι κώδικας 20 χρονών από κάποιον καθηγητή, δυστυχώς για μένα ειναι καρατσεκαρισμένος . Αλλά έχεις δίκιο, μάλλον κάτι χάνω σε μνήμη μεταξύ C και fortran και μου βγάζει εκτός όλο το πρόγραμμα. Για αυτό δεν πόσταρα κώδικα, γιατι ούτε εγώ ξέρω που ειναι το πρόβλημα, απλά βλέπω τα συμπτώματα .

 

Επίσης παρατήρησα, οτι τώρα που έβαλα τα print statements, για των ίδιων διαστάσεων πρόβλημα πετάει αλλου το πρόβλημα!!! κάπου κάτι βασικό χάνω για την διαχείριση μνήμης σε C ή Fortran ίσως.

 

Για πείτε κανενα πιο αποδοτικό debugger μπας και κάνουμε καλύτερη δουλεια...

 

Ευχαριστώ!

 

---------- Προσθήκη στις 14:11 ---------- Προηγούμενο μήνυμα στις 14:06 ----------

 

Τώρα ας πούμε, έτρεξα πάλι των ίδιων διαστάσεων πρόβλημα και μου πετάξε τα nan's στα print statements. Φαίνεται να είναι λίγο random,

 

ΑΑΑ όσο για τα nan's ναι η fortran τα χειρίζεται μια χαρα, αλλά μετά ορίζονται κάποια indexes που επηρεάζονται απο τα nan's και τότε παίρνω το segmentation fault.

[m1cRo]

H ρουτίνα είναι κώδικας 20 χρονών από κάποιον καθηγητή, δυστυχώς για μένα ειναι καρατσεκαρισμένος . Αλλά έχεις δίκιο, μάλλον κάτι χάνω σε μνήμη μεταξύ C και fortran και μου βγάζει εκτός όλο το πρόγραμμα. Για αυτό δεν πόσταρα κώδικα, γιατι ούτε εγώ ξέρω που ειναι το πρόβλημα, απλά βλέπω τα συμπτώματα .

 

Επίσης παρατήρησα, οτι τώρα που έβαλα τα print statements, για των ίδιων διαστάσεων πρόβλημα πετάει αλλου το πρόβλημα!!! κάπου κάτι βασικό χάνω για την διαχείριση μνήμης σε C ή Fortran ίσως.

 

Για πείτε κανενα πιο αποδοτικό debugger μπας και κάνουμε καλύτερη δουλεια...

 

Ευχαριστώ!

 

---------- Προσθήκη στις 14:11 ---------- Προηγούμενο μήνυμα στις 14:06 ----------

 

Τώρα ας πούμε, έτρεξα πάλι των ίδιων διαστάσεων πρόβλημα και μου πετάξε τα nan's στα print statements. Φαίνεται να είναι λίγο random,

 

ΑΑΑ όσο για τα nan's ναι η fortran τα χειρίζεται μια χαρα, αλλά μετά ορίζονται κάποια indexes που επηρεάζονται απο τα nan's και τότε παίρνω το segmentation fault.

 

Visual studio...

[kfoynt]

Ο αστερίσκος στην fortran όταν δηλώνεις μεταβλητές, πχ. RES(*) αντί να δηλώνεις κανονικά τις διαστάσεις RES(MAXM) λειτουργεί κανονικα?? γιατι παρατηρώ ότι ένα διάνυσμα μπαίνει μέσα σε μία ρουτίνα με πραγματικούς αριθμούς και μέσα στην ρουτίνα γίνεται nan!

[dop]

Καταρχάς χρησιμοποίησε gcc με έκδοση >= 4.3. Ο gdb θα σου κάνει τη δουλειά μια χαρά. Κάνε compile τον κώδικά σου με -Wall -O0 -g (δηλ. ανοιχτά όλα τα warnings, κανένα optimization και δημιουργία debug information).

 

Αν νομίζεις ότι το πρόβλημα γίνεται λόγω λανθασμένης διαχείρισης μνήμης, δοκίμασε και το vallgrind.

[V.I.Smirnov]

Ο αστερίσκος στην fortran όταν δηλώνεις μεταβλητές, πχ. RES(*) αντί να δηλώνεις κανονικά τις διαστάσεις RES(MAXM) λειτουργεί κανονικα??

γιατι παρατηρώ ότι ένα διάνυσμα μπαίνει μέσα σε μία ρουτίνα με πραγματικούς αριθμούς και μέσα στην ρουτίνα γίνεται nan!

 

Οι πίνακες που δηλώνονται με αστερίσκο, array(*), είναι τύπου assumed size και πρέπει να αποφεύγονται, ειδικά όταν είναι πολλών διαστάσεων.

Αυτό είναι πολύ κακό στυλ γραφής, κατάλοιπο από τη δεκαετία του '60.

 

Πέραν αυτού, οι πίνακες στην Fortran και την C/C++ έχουν διαφορετική χωροθέτηση στην μνήμη (column major έναντι row major).

Υπάρχουν κι' άλλες διαφορές αλλά αυτή είναι η πιο κρίσιμη.

Aν μεταφέρεις πολυδιάστατο πίνακα μεταξύ ρουτινών σε διαφορετικές γλώσσες πρέπει οπωσδήποτε να κάνεις μετατροπή.

Έχεις ελέγξει ότι οι ετερόγλωσσες ρουτίνες επικοινωνούν σωστά μεταξύ τους ;

 

Όσο για debugger, το visual studio που ανέφερε άλλος φίλος νωρίτερα είναι ίσως η καλύτερη περίπτωση όταν συνδυάζεται με compiler

της fortran που ενσωματώνεται σε αυτό (όπως π.χ. η intel fortran).

Έτσι ο χειρισμός αμφοτέρων των γλωσσών γίνεται δίχως καμιά μέριμνα - τεράστια ευκολία - χώρια τα υπόλοιπα καλά του IDE.

Το έχουμε ξανασυζητήσει αυτό - θυμάμαι τι προβλήματα είχες με τα breakpoints στον μικτό κώδικα που δεν τα χειριζόταν σωστά ο GDB.

Aν μπλέκεις και το matlab, χειροτερεύει η κατάσταση...στη θέση σου θα χρησιμοποιούσα FFT σε C++ ή fortran από το Numerical Recipes για

να αποφύγω το matlab και να μην έχω τόσα διαφορετικά περιβάλλοντα - αφού το έχεις ήδη κάνει όμως άστο έτσι...

 

-

[kfoynt]

Οι πίνακες που δηλώνονται με αστερίσκο, array(*), είναι τύπου assumed size και πρέπει να αποφεύγονται, ειδικά όταν είναι πολλών διαστάσεων.

Αυτό είναι πολύ κακό στυλ γραφής, κατάλοιπο από τη δεκαετία του '60.

 

Πέραν αυτού, οι πίνακες στην Fortran και την C/C++ έχουν διαφορετική χωροθέτηση στην μνήμη (column major έναντι row major).

Υπάρχουν κι' άλλες διαφορές αλλά αυτή είναι η πιο κρίσιμη.

Aν μεταφέρεις πολυδιάστατο πίνακα μεταξύ ρουτινών σε διαφορετικές γλώσσες πρέπει οπωσδήποτε να κάνεις μετατροπή.

Έχεις ελέγξει ότι οι ετερόγλωσσες ρουτίνες επικοινωνούν σωστά μεταξύ τους ;

 

Όσο για debugger, το visual studio που ανέφερε άλλος φίλος νωρίτερα είναι ίσως η καλύτερη περίπτωση όταν συνδυάζεται με compiler

της fortran που ενσωματώνεται σε αυτό (όπως π.χ. η intel fortran).

Έτσι ο χειρισμός αμφοτέρων των γλωσσών γίνεται δίχως καμιά μέριμνα - τεράστια ευκολία - χώρια τα υπόλοιπα καλά του IDE.

Το έχουμε ξανασυζητήσει αυτό - θυμάμαι τι προβλήματα είχες με τα breakpoints στον μικτό κώδικα που δεν τα χειριζόταν σωστά ο GDB.

Aν μπλέκεις και το matlab, χειροτερεύει η κατάσταση...στη θέση σου θα χρησιμοποιούσα FFT σε C++ ή fortran από το Numerical Recipes για

να αποφύγω το matlab και να μην έχω τόσα διαφορετικά περιβάλλοντα - αφού το έχεις ήδη κάνει όμως άστο έτσι...

 

-

 

Ναι προς το παρόν ότι ειχα κάνει πάνω σε αυτό τον κώδικα δεν ειχα παρατηρήσει προβλήματα με τους πίνακες, έτσι και αλλιώς όταν γράφω ένα πίνακα στην C, ορίζω με malloc και μετά τους χειρίζομαι ως column major. Αυτό που παρατήρησα είναι ότι αν δεν έχω ένα σταθερό τρόπο για να κάνω allocate μνήμη, πχ, με operator [] ή malloc τότε σε μεγάλες διαστάσεις προβλήματα μου αλλάζει τα φώτα σε segfaults.

 

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

αυτός ο Bregman, αχτύπητος ειναι

, και ειμαι τοοοοσο κοντα...

 

Να σου πω, επειδή όντως δεν κάνουμε δουλειά έτσι, παίζει κανένα skype? να κάνουμε κανενα share screen?? Μπορείς να πεις άνετα όχι φυσικα και εγώ ζορισμένος ειμαι και χρόνος "0".

[V.I.Smirnov]

Όχι, δυστυχώς, δεν έχω skype. Kαι δεν έχω και χρόνο. Συνενόηση εξ αποστάσεως για τέτοια πράγματα είναι δύκολη και δεν θα τα καταφέρουμε.

Μόνον από κοντά θα ήταν δυνατό και πάλι υπό προϋποθέσεις.

Δεν ξέρω matlab. Ξέρω C++ και fortran και δουλεύω (όταν το κάνω) σε visual studio, κάτω από το οποίο έχω

ενοποιημένα ότι χρησιμοποιώ (fortran, C++, openMP, MPI, openGL, directX, openAL, Qt).

Έτσι όλα δουλεύουν άψογα (σχεδόν) και είμαι καλά βολεμένος - ακόμα και ο μικτός προγραμματισμός είναι μια χαρά έτσι.

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

Αν είναι μπλεγμένα και δυο λειτουργικά, ( με vm ή δεν ξέρω τι άλλο ), η κατάσταση είναι ακόμα χειρότερη.

 

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

Π.χ. μερικές φορές σε fotran προγράμματα είχα προβλήματα με το stack όταν χρησιμοποιούσα μεγάλους πίνακες (της τάξης 1GΒ).

Και με τις αυτόματες μεταβλητές στην C μπορεί να συμβεί το ίδιο.

Ρύθμισα το stack σε 500 ΜΒ και ησύχασα.

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

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

Λυπάμαι που δεν μπορώ να βοηθήσω περισσότερο - εύχομαι να τα καταφέρεις....

[kfoynt]

Οκ, κανέα πρόβλημα. Έπρεπε απο την αρχή να το ειχα σε ξεχωριστο partition και να χρησιμοποιήσω απευθειας matlab engine. Αλλά, τότε δεν ειχα ιδεα + δεν ειμαστε και Ελλάδα να έχουμε όσο χρόνο θέλουμε...

[kfoynt]

Καταρχάς χρησιμοποίησε gcc με έκδοση >= 4.3. Ο gdb θα σου κάνει τη δουλειά μια χαρά. Κάνε compile τον κώδικά σου με -Wall -O0 -g (δηλ. ανοιχτά όλα τα warnings, κανένα optimization και δημιουργία debug information).

 

Αν νομίζεις ότι το πρόβλημα γίνεται λόγω λανθασμένης διαχείρισης μνήμης, δοκίμασε και το vallgrind.

 

 

thanks,θα το δοκιμάσω και αυτο...