[PYTHON] *** glibc detected *** python: free(): invalid pointer: 0xb7d99910 ***

[maforast]

Salve a tutti ho un errore quando chiamo sys.exit() in un programma python che mi crea non pochi problemi

l'errore è il seguente

*** glibc detected *** python: free(): invalid pointer: 0xb7d99910 ***

Qualcuno sa a cosa è dovuto?

[marco.r]

potrebbe essere un bug in un qualche modulo scritto in C...
che librerie/moduli stai usando ?

[maforast]

Originariamente inviato da marco.r

potrebbe essere un bug in un qualche modulo scritto in C...
che librerie/moduli stai usando ?

Il modulo che mi crea quell'errore è il pyv4l cioè quando faccio

import v4l

da precisare che questo è il modulo ottenuto compilando pyv4l cioè v4l.c ho scoperto anche il punto all'interno del codice v4l.c precisamente riga 820

v4l_setupCapture(videoobject *self) {
    if (ioctl(self->fd, VIDIOCGMBUF, &self->mbuf) < 0) return -1;
    //fprintf(stderr,"  mbuf: size=%d frames=%d\n", self->mbuf.size,self->mbuf.frames);
    self->map = mmap(0, self->mbuf.size, PROT_READ|PROT_WRITE, MAP_SHARED, self->fd, 0);
    //self->map = mmap(0, self->mbuf.size, PROT_READ, MAP_PRIVATE, self->fd, 0);
    if ((self->map == NULL) | (self->map == MAP_FAILED)) {
	PyErr_SetString(VideoError, "Error Memory Mapping device.");
    	return -1;
    }

ho dovuto commentare questa parte perkè altrimenti il modulo dava errore quando veniva caricato

 //self->map = mmap(0, self->mbuf.size, PROT_READ, MAP_PRIVATE, self->fd, 0);

e ho decommentato quest'altra parta

 self->map = mmap(0, self->mbuf.size, PROT_READ|PROT_WRITE, MAP_SHARED, self->fd, 0);

in pratica ho dovuto mettere MAP_SHARED al posto di MAP_PRIVATE ed è questo che mi crea il problema glibc ma purtroppo se lascio MAP_PRIVATE ottengo un errore che non mi fa partire nemmeno il codice

il fatto è che su ubuntu dapper questo errore non me lo da ma su feasty sì

che pazienza che ci vuole ....

[ilsensine]

Originariamente inviato da maforast

Il modulo che mi crea quell'errore è il pyv4l cioè quando faccio

import v4l

da precisare che questo è il modulo ottenuto compilando pyv4l cioè v4l.c ho scoperto anche il punto all'interno del codice v4l.c precisamente riga 820

v4l_setupCapture(videoobject *self) {
    if (ioctl(self->fd, VIDIOCGMBUF, &self->mbuf) < 0) return -1;
    //fprintf(stderr,"  mbuf: size=%d frames=%d\n", self->mbuf.size,self->mbuf.frames);
    self->map = mmap(0, self->mbuf.size, PROT_READ|PROT_WRITE, MAP_SHARED, self->fd, 0);
    //self->map = mmap(0, self->mbuf.size, PROT_READ, MAP_PRIVATE, self->fd, 0);
    if ((self->map == NULL) | (self->map == MAP_FAILED)) {
	PyErr_SetString(VideoError, "Error Memory Mapping device.");
    	return -1;
    }

ho dovuto commentare questa parte perkè altrimenti il modulo dava errore quando veniva caricato

 //self->map = mmap(0, self->mbuf.size, PROT_READ, MAP_PRIVATE, self->fd, 0);

e ho decommentato quest'altra parta

 self->map = mmap(0, self->mbuf.size, PROT_READ|PROT_WRITE, MAP_SHARED, self->fd, 0);

in pratica ho dovuto mettere MAP_SHARED al posto di MAP_PRIVATE ed è questo che mi crea il problema glibc ma purtroppo se lascio MAP_PRIVATE ottengo un errore che non mi fa partire nemmeno il codice

il fatto è che su ubuntu dapper questo errore non me lo da ma su feasty sì

che pazienza che ci vuole ....

Credo che il bug sia altrove; facento 1+1 azzarderei che sta tentando una free() su memoria ottenuta con mmap. Mortale.

Riguardo la modifica MAP_PRIVATE -> MAP_SHARED, è un bug genuino che hai corretto. Ora scova la free e cambiala con la munmap.

Nota che l'elenco dei bug non finisce qui; eccone un'altro (innocuo):

if ((self->map == NULL) | (self->map == MAP_FAILED)) {

Credo che quel codice sia stato scritto un pò alla carlona. Non fidarti.

[ilsensine]

Nota infine che quel codice usa le vecchie API V4L1; alcuni device ormai supportano solo le V4L2.

[ilsensine]

Originariamente inviato da ilsensine

Ora scova la free e cambiala con la munmap.

Umm non sono sicuro che sia così; 0xb7d99910 non è un indirizzo ottenibile con mmap (non è allineato alla pagina). Probabilmente si tratta di un bug diverso, forse un doppio free o un puntatore selvaggio. Forse valgrind può dirti di più.

[maforast]

Originariamente inviato da ilsensine

Umm non sono sicuro che sia così; 0xb7d99910 non è un indirizzo ottenibile con mmap (non è allineato alla pagina). Probabilmente si tratta di un bug diverso, forse un doppio free o un puntatore selvaggio. Forse valgrind può dirti di più.

Grazie tra un pò vado a vedere le cose ke mi hai detto ma dove sono riportati i bugs che mi hai scritto sopra? E come faccio ad utilizzare il v4l2? Io in rete ho trovato solo questo modulo per python che si interfaccia con il v4l ed in effetti è un pò vecchiotto visto che non viene aggiornato dal 2005


cmq grazie 1000

[ilsensine]

Originariamente inviato da maforast

Grazie tra un pò vado a vedere le cose ke mi hai detto ma dove sono riportati i bugs che mi hai scritto sopra?

...?

E come faccio ad utilizzare il v4l2?

...riscrivi il modulo

[maforast]

Originariamente inviato da ilsensine

Umm non sono sicuro che sia così; 0xb7d99910 non è un indirizzo ottenibile con mmap (non è allineato alla pagina). Probabilmente si tratta di un bug diverso, forse un doppio free o un puntatore selvaggio. Forse valgrind può dirti di più.

Non ho capito bene un paio di cose:
1 come hai fatto a capire che quell'indirizzo di memoria non è ottenibile da mmap e 2 se devo ancora cambiare free con munmap...

rifare io il modulo v4l2 lol bellissima questa ma non c'è che tu sappia un altro modulo pyv4l + aggiornato?

[maforast]

Originariamente inviato da maforast

Non ho capito bene un paio di cose:
1 come hai fatto a capire che quell'indirizzo di memoria non è ottenibile da mmap e 2 se devo ancora cambiare free con munmap...

rifare io il modulo v4l2 lol bellissima questa ma non c'è che tu sappia un altro modulo pyv4l + aggiornato?

Ho provato a sostituire munmap con free ma quando compilo mi viene detto

v4l.c:1323: error: too few arguments to function ‘munmap’

quindi ho rimesso free

non ho capito bene inoltre a che big ti riferisci in questa riga

    if ((self->map == NULL) | (self->map == MAP_FAILED)) {

[ilsensine]

Originariamente inviato da maforast

Non ho capito bene un paio di cose:
1 come hai fatto a capire che quell'indirizzo di memoria non è ottenibile da mmap

Non è allineato alla pagina

e 2 se devo ancora cambiare free con munmap...

Non credo. Per me dovresti eseguire python sotto gdb e fargli interpretare il tuo script; in corrispondenza della free() incriminata verrà generato un abort che gdb intercetterà. Con "where" potrai risalire alla free() all'interno dei sorgenti, ammesso che python e le librerie siano compilate con i simboli di debug.

rifare io il modulo v4l2 lol bellissima questa ma non c'è che tu sappia un altro modulo pyv4l + aggiornato?

Non uso python, non ho idea. Comunque con V4L1 copri quasi tutti i dispositivi, anche perché molti V4L2 offrono uno strato di compatibilità con V4L1.

Ho provato a sostituire munmap con free ma quando compilo mi viene detto

v4l.c:1323: error: too few arguments to function ‘munmap’

Certo munmap vuole anche la dimensione della regione.
Prima che fai ulteriori danni, quale free() stai toccando? Qualche riga di codice?

non ho capito bene inoltre a che big ti riferisci in questa riga

1) occorre testare solo con MAP_FAILED
2) e comunque "|" -> "||"
In ogni caso è innoquo, non cambia la funzionalità.

[maforast]

Originariamente inviato da ilsensine

Non è allineato alla pagina

Non credo. Per me dovresti eseguire python sotto gdb e fargli interpretare il tuo script; in corrispondenza della free() incriminata verrà generato un abort che gdb intercetterà. Con "where" potrai risalire alla free() all'interno dei sorgenti, ammesso che python e le librerie siano compilate con i simboli di debug.

il debug mi dice che non riesce a trovare simboli di debug

Originariamente inviato da ilsensine

Certo munmap vuole anche la dimensione della regione.
Prima che fai ulteriori danni, quale free() stai toccando? Qualche riga di codice?

ho modificato la riga 982

free( self->conversion_buffer.data );

e la riga 1323

	free(self->conversion_buffer.data);

del v4l.c che sta nel pacchetto pyv4l

[ilsensine]

Originariamente inviato da maforast

ho modificato la riga 982

free( self->conversion_buffer.data );

e la riga 1323

	free(self->conversion_buffer.data);

Lasciale stare, credo siano corrette così come sono.

il debug mi dice che non riesce a trovare simboli di debug

ubuntu non fornisce le versioni dbg di phyton e librerie?
Nota che basterebbero i simboli di debug del modulo che contiene la free() incriminata, a sapere di quale si tratta. C'è un modo per saperlo, comunque.

[maforast]

Originariamente inviato da ilsensine

ubuntu non fornisce le versioni dbg di phyton e librerie?
Nota che basterebbero i simboli di debug del modulo che contiene la free() incriminata, a sapere di quale si tratta. C'è un modo per saperlo, comunque.

sì le fornisce... ma non ho proprio idea di quale modulo mi serve per il debug e su quale file lo devo andare a fare io ho provato facendo dbg python Main.py e mi ha dato l'errore che ti ho postato prima

[ilsensine]

Originariamente inviato da maforast

sì le fornisce... ma non ho proprio idea di quale modulo mi serve per il debug e su quale file lo devo andare a fare io ho provato facendo dbg python Main.py e mi ha dato l'errore che ti ho postato prima

Allora scoviamo il modulo incriminato.
Devi fare così; innanzitutto devi ottenere il backtrace della free tramite gdb:

gdb python
(gdb) set args Main.py
(gdb) run
...esecuzione del programma...
*** glibc detected *** /usr/bin/python: free(): invalid pointer: 0x<indirizzo> ***
Program received signal SIGABRT, Aborted.
0x<indirizzo> in raise () from /lib/libc.so.6
(gdb) where
...backtrace...

A questo punto devi esaminare il backtrace. Probabilmente otterrai qualcosa di questo genere:

(gdb) where
#0  0x.... in raise () from /lib/libc.so.6
#1  0x.... in abort () from /lib/libc.so.6
#2  0x.... in __libc_message () from /lib/libc.so.6
#3  0x.... in _int_free () from /lib/libc.so.6
#4  0x.... in free () from /lib/libc.so.6
#5  0x<INDIRIZZO> in ??? ()
#6 ecc.

Quello che ti interessa è la riga dopo la free(), prendi nota dell'indirizzo mostrato. Se c'è qualche simbolo di debug disponibile, i "???" potrebbero essere il nome della funzione, oppure addirittura il nome del file sorgente e la riga.
Senza chiudere gdb, apri un'altra console ed esegui
pidof python
Ti verrà restituito un numero, il pid del processo. Esamina quindi la sua mappa di memoria:
cat /proc/[pid restituito da pidof]/maps
e sarai in grado di associare l'indirizzo mostrato da gdb alla libreria corrispondente.

[maforast]

Originariamente inviato da ilsensine

Allora scoviamo il modulo incriminato.
Devi fare così; innanzitutto devi ottenere il backtrace della free tramite gdb:

gdb python
(gdb) set args Main.py
(gdb) run
...esecuzione del programma...
*** glibc detected *** /usr/bin/python: free(): invalid pointer: 0x<indirizzo> ***
Program received signal SIGABRT, Aborted.
0x<indirizzo> in raise () from /lib/libc.so.6
(gdb) where
...backtrace...

A questo punto devi esaminare il backtrace. Probabilmente otterrai qualcosa di questo genere:

(gdb) where
#0  0x.... in raise () from /lib/libc.so.6
#1  0x.... in abort () from /lib/libc.so.6
#2  0x.... in __libc_message () from /lib/libc.so.6
#3  0x.... in _int_free () from /lib/libc.so.6
#4  0x.... in free () from /lib/libc.so.6
#5  0x<INDIRIZZO> in ??? ()
#6 ecc.

Quello che ti interessa è la riga dopo la free(), prendi nota dell'indirizzo mostrato. Se c'è qualche simbolo di debug disponibile, i "???" potrebbero essere il nome della funzione, oppure addirittura il nome del file sorgente e la riga.
Senza chiudere gdb, apri un'altra console ed esegui
pidof python
Ti verrà restituito un numero, il pid del processo. Esamina quindi la sua mappa di memoria:
cat /proc/[pid restituito da pidof]/maps
e sarai in grado di associare l'indirizzo mostrato da gdb alla libreria corrispondente.

si è bloccato qui il dbg

(gdb) set args Main3.py
(gdb) run
Starting program: /usr/bin/python Main3.py
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread -1210136896 (LWP 11557)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
281.jpeg
93.2330827068
93.984962406
94.7368421053



 - TSBD2: 94.7368421053
*** glibc detected *** /usr/bin/python: free(): invalid pointer: 0xb7dd3910 ***

proprio come mi capita quando lo lancio normalmente cioè non riesce a ridare il controllo al terminale a patto che non faccia ctrl+c

[maforast]

Originariamente inviato da maforast

 - TSBD2: 94.7368421053
*** glibc detected *** /usr/bin/python: free(): invalid pointer: 0xb7dd3910 ***

quel TSBD2 è il risultato del mio programma dpodikè dovrebbe terminare con sys.exit()

[maforast]

Originariamente inviato da maforast

- TSBD2: 94.7368421053
*** glibc detected *** /usr/bin/python: free(): invalid pointer: 0xb7dd3910 ***

a questo punto ho fatto ctrl+c ed ho ottenuto

Program received signal SIGINT, Interrupt.
[Switching to Thread -1210136896 (LWP 11557)]
0xffffe410 in __kernel_vsyscall ()

poi ho fatto where ed ho ottenuto

(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7eca05e in ?? () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e598fe in ?? () from /lib/tls/i686/cmov/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

[maforast]

Originariamente inviato da maforast

a questo punto ho fatto ctrl+c ed ho ottenuto

Program received signal SIGINT, Interrupt.
[Switching to Thread -1210136896 (LWP 11557)]
0xffffe410 in __kernel_vsyscall ()

poi ho fatto where ed ho ottenuto

(gdb) where
#0  0xffffe410 in __kernel_vsyscall ()
#1  0xb7eca05e in ?? () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7e598fe in ?? () from /lib/tls/i686/cmov/libc.so.6
Backtrace stopped: previous frame identical to this frame (corrupt stack?)

Dando ctrl +c in quel punto non mi da + la l'indirizzo di memoria relativo a free ma credo a quello generato da ctrl+c infatti free non compare ... mmmmmm

[ilsensine]

Originariamente inviato da maforast

si è bloccato qui il dbg

(gdb) set args Main3.py
(gdb) run
<snip>
 - TSBD2: 94.7368421053
*** glibc detected *** /usr/bin/python: free(): invalid pointer: 0xb7dd3910 ***

proprio come mi capita quando lo lancio normalmente cioè non riesce a ridare il controllo al terminale a patto che non faccia ctrl+c

Qualcosa non va, le libc dovrebbero generare un abort.