Στις 2 Οκτωβρίου 2011 7:31 μ.μ., ο χρήστης John Tsiombikas <nuclear [ at ] member [ dot ] fsf [ dot ] org> έγραψε: > On Sun, Oct 02, 2011 at 04:48:24PM +0300, Nick Kossifidis wrote: >> Hello all ;-) >> >> Πρόσφατα πήγα να κάνω compile σε ένα ubuntu oneiric και διαπίστωσα τα εξής.. >> >> α) Ο gcc παίρνει τα CFLAGS μόνο στο τέλος της εντολής και όχι στην >> αρχή (κουλό !), ποιο συγκεκριμένα αν τα βάλω στην αρχή της εντολής >> πχ. >> gcc $CFLAGS -c foo.c -o bar.o >> δεν κάνει ποτέ link (το bar.o είναι linked μόνο με τη libc και όλα τα >> symols προς άλλες βιβλιοθήκες είναι unresolved), ενώ το >> gcc -c foo.c -o bar.o $CFLAGS >> δουλεύει κανονικά ! > > Den mas eipes ti periexei to CFLAGS omos ... > Ότι περιέχει συνήθως (http://en.wikipedia.org/wiki/CFLAGS), στη δικιά μου περίπτωση είναι απλά το output του package config για τις βιβλιοθήκες που χρησιμοποιώ (ούτε optimizations ούτε τίποτα περίεργο), ποιο συγκεκριμένα... `pkg-config --cflags --libs openssl libcurl` Στον gcc 4.4.6 και 4.5.2 σε 32bit και 64bit (gentoo) η εντολή gcc $CFLAGS -c foo.c -o bar.o παίζει κανονικότατα και κάνει link όπως πρέπει και με την openssl και με την curl + γενικώς μέχρι τώρα έτσι έβαζα τα CFLAGS στον gcc και τα παίρνει μια χαρά. Στον gcc 4.6.0 που δοκίμασα στο ubuntu δεν κάνει link με τίποτα παρά μόνο με τη libc (ότι έρχεται από την openssl και τη curl είναι unresolved στο objdump), εκεί δουλεύει μόνο η εντολή gcc -c foo.c -o bar.o $CFLAGS όπου κάνει το link κανονικά. Τελικά το άφησα έτσι για να δουλεύει παντού, απλά μου κάνει εντύπωση και ρωτάω αν το έχει δει κανείς. >> β) Για κάποιο λόγο τρώω ένα άκυρο segfault που το βλέπω μόνο εκεί (και >> δεν έχει κανένα νόημα, είναι ένα τυπικό assignment από αποτέλεσμα >> συνάρτησης, του στυλ mitsos = takis()), ούτε warnings του compiler >> ούτε τίποτα + το δοκίμασα σε gentoo 32 και 64bit και δουλεύει >> κανονικότατα (gcc 4.4.x και 4.5.2). > > Den mas edoses backtrace omos apo ton gdb ... Το θέμα μου δεν είναι να μου κάνετε debug, το κάνω και μόνος μου (θα έπρεπε να σας δώσω και όλο τον κώδικα για να είμαστε σωστοί), απλά ρωτάω αν έχετε δει αλλόκοτα segfaults συγκεκριμένα με τον gcc 4.6.0 που με τους προηγούμενους δεν τα βλέπατε. Παρ' όλα αυτά σου εξηγώ το backtrace, ότι βαράει σε ένα σημείο του κώδικα με το που η takis() κάνει return και assign στη μεταβλητή mitsos (τυχαία ονόματα), είναι κάτι πολύ τετριμμένο και δουλεύει κανονικότατα αλλού και σε άλλα σημεία του κώδικα, μόνο σε 4.6.0 έχω το πρόβλημα σε ένα συγκεκριμένο σημείο που όμως δεν έχει καμία διαφορά πρακτικά απ' τα υπόλοιπα. Ποιο συγκεκριμένα κάνει return ένα pointer σε struct το οποίο έχει γίνει κανονικά initialized από την takis() -τσεκαρισμένο- και έρχεται απ' την openssl. Θα σας έστελνα και τα contents της μνήμης αλλά και πάλι χωρίς τον κώδικα δεν έχει και πολύ νόημα, αν πχ. στο backtrace δεις ένα takis + 0x13/0x13, χωρίς τον κώδικα τι θα καταλάβεις ? >> γ) Έφαγα και ένα άλλο segfault λιγότερο άκυρο αλλά που πάλι δε βγάζει >> νόημα, μέσα στη glibc όταν κάνω regexp checks από συγκεκριμένο code >> path (η ίδια συνάρτηση δουλεύει κανονικά απ' όπου και να τη καλέσω και >> με ότι όρισμα και να της βάλω -κάνει checks internaly- αλλά όταν τη >> καλώ από συγκεκριμένο path χτυπάει στη malloc_consolidate (το διόρθωσα >> φτιάχνοντας ένα λάθος malloc που έκανα παραπάνω -αλλά νομιμότατο >> malloc, ήταν λάθος code-wise-). Θα γράψω ένα proof-of-concept >> προγραμματάκι να σας δείξω τι εννοώ. > > malloc pool corruption ? dose to minimal code example pou kanei > reproduce to provlima sou allios den bgainei akri. > Ναι κάποιο corruption είναι στο malloc pool απλά δε καταλαβαίνω από που προκύπτει. Θα σας στείλω μάλλον το proof-of-concept αύριο αφού υπάρχει ενδιαφέρον. Να σου δώσω μια εικόνα έκανα σε μια συνάρτηση, ας τη πούμε func, kati1 = malloc(sizeof(int)), memset(kati1, 0, sizeof(int)) και μετά καλώ μια συνάρτηση που κάνει regexp check πχ. check(string) και εκεί μου βαράει segfault internally η regcomp αλλά όχι με τη πρώτη. Σε ένα σύστημα μου βαράει με τη δεύτερη φορά που καλώ τη func και σε άλλο η κατάσταση είναι ποιο περίεργη (τη 4-6η φορά υπό όρους) -προφανώς τα 2 συστήματα διαφέρουν αρκετά, το ένα έχει 2 cores ενώ το άλλο όχι, διαφορετική αρχιτεκτονική κλπ οπότε είναι λογικό σε ένα malloc pool corruption να μην έχουν την ίδια συμπεριφορά. Αν τώρα αλλάξω το sizeof(int) και το κάνω sizeof(struct kati) -που είναι προφανώς το σωστό code-wise- το πρόγραμμα δε βαράει segfault και παίζει κανονικά. Υπόψη το kati1 δε το χρησιμοποιώ στη συνάρτηση, απλά το κάνω malloc/memset (αλλά Ο.Κ. στο malloc pool αυτό δεν έχει σημασία γιατί είναι το αμέσως προηγούμενο malloc, γι' αυτό και λέω "λιγότερο κουλό"). Απλά δε καταλαβαίνω τι το κόφτει αν είναι sizeof(int) και όχι sizeof(struct kati1) αφού ούτως η άλλως η malloc επιστρέφει έναν void pointer, να χτύπαγε όταν πήγαινα να γεμίσω το kati1 να το καταλάβαινα αλλά βαράει στο επόμενο malloc ουσιαστικά, χωρίς να χρησιμοποιώ το kati1 πουθενά -ήταν work in progress-. >> Έχετε δει κάτι αντίστοιχο στο Ubuntu ? > > Den kseroume kan ti vlepeis pos na kseroume an exoume dei antistoixo. > Ena einai sigouro, den ftaiei to ubuntu. Den mas edoses kamia apolytos > pliroforia pou na dixnei poio einai to provlima, ston aera den mporeis > na kaneis debugging. > Δηλαδή sorry άντε πες το τελευταίο δεν δίνω αρκετές πληροφορίες και λέω ότι θα στείλω κώδικα για check για να δω και αν υπάρχει ενδιαφέρον, το άλλο που λέω ότι με τον gcc 4.6.0 βλέπω ένα κουλό seffault που δεν το έβλεπα με τους προηγούμενους + έχω αυτό το θέμα με τα CFLAGS και ρωτάω αν έχετε δει κάτι αντίστοιχο στο ubuntu oneiric (που είναι το μόνο που έχει βάλει 4.6.0 απ' όσο ξέρω -λόγω του ότι είναι beta) που είναι η ασάφεια ? Δεν είπα πουθενά ότι φταίει το ubuntu ή ότι φταίει κάτι γενικώς (αν είδες στο subject λέω gcc 4.6 και το ubuntu το έχω σε παρένθεση, απλά έτυχε να δοκιμάσω τον 4.6 εκεί), ούτε ζήτησα να κάνει κανείς debuging, το μόνο που ρώτησα είναι αν έχει δει κανείς σας κάτι αντίστοιχο (και πχ. αυτό με τα CFLAGS είναι πολύ απλό να το testάρεις). -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick