problema di glibc?

[kingv]

Ho un programma sviluppato in C (non da me) che passando da Red Hat 3 (dove funzionava correttamente) a Red Hat 4 esce appena viene lanciato con il seguente messaggio:

*** glibc detected *** free(): invalid next size (fast): 0x0a065038 ***
Aborted


non ho attualmente i sorgenti da debuggare, però ho provato a lanciare il programma tramite valgrind e mi segnala numerose "invalid read" o "invalid write" prima di crashare con il messaggio risportato sopra.
Secondo voi è un problema di glibc (ho trovato issue simili su bugzilla), oppure un problema applicativo? Nel secondo caso perchè con RH3 il problema non si presentava?

[ilsensine]

Difficile dirsi. L'indirizzo 0x0a065038 non è in genere nella regione "heap". Puzza di buffer overflow.

Comunque se esegui il programma sotto gdb, puoi verere il call trace (tramite il comando "where", quando il programma lancia l'abort), ed avere indicazioni su chi ha tentato la deallocazione invalida. Potrebbe anche essere una libreria usata dal programma; forse c'è una incompatibilità tra una libreria di RH3 e RH4.
Un programma precompilato sotto linux dovrebbe portarsi dietro sempre i compilati di eventuali librerie particolari utilizzate al momento della compilazione.

[kingv]

speravo che capitassi in questo thread.
allora l'uso dei tool GNU non è il mio forte ma lanciando il programma con gdb ottengo:


gdb /usr/bin/XXX
(gdb) set args ecc.ecc.
(gdb) run
Starting program: /usr/bin/XXX ecc.ecc
(no debugging symbols found)
(no debugging symbols found)
*** glibc detected *** free(): invalid next size (fast): 0x09a59038 ***
(gdb) where
#0 0x009cd7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x00a127a5 in raise () from /lib/tls/libc.so.6
#2 0x00a14209 in abort () from /lib/tls/libc.so.6
#3 0x00a4671a in __libc_message () from /lib/tls/libc.so.6
#4 0x00a4cfbf in _int_free () from /lib/tls/libc.so.6
#5 0x00a4d33a in free () from /lib/tls/libc.so.6
#6 0x08049e6f in ?? ()
#7 0x09a59038 in ?? ()
#8 0x08063ea5 in _IO_stdin_used ()
#9 0x00000011 in ?? ()
#10 0x00000006 in ?? ()
#11 0xbfe2cd24 in ?? ()
#12 0x09a59038 in ?? ()
#13 0x00000000 in ?? ()


purtroppo il programma è strippato.
l'output di valgrid segnala tutti errori simili a questo:

==31143== Invalid write of size 1
==31143== at 0x400659F: memset (mac_replace_strmem.c:464)
==31143== by 0x8049D1F: (within /usr/bin/XXX)
==31143== by 0x804AE03: (within /usr/bin/XXX)
==31143== by 0x9FFDE2: (below main) (in /lib/tls/libc-2.3.4.so)
==31143== Address 0x4014125 is 1 bytes after a block of size 4 alloc'd
==31143== at 0x4004405: malloc (vg_replace_malloc.c:149)
==31143== by 0x8049CF9: (within /usr/bin/XXX)
==31143== by 0x804AE03: (within /usr/bin/XXX)
==31143== by 0x9FFDE2: (below main) (in /lib/tls/libc-2.3.4.so)

grazie per l'aiuto :)

[kingv]

ah sto cercando i sorgenti per ricompilarlo, ma naturalmente sono finiti nel tritarifiuti aziendale, Source (Un)Safe ....

[ilsensine]

Puoi vedere quali librerie usa il programma (tramite ldd) e creare una directory dove copiare quelle "sospette" dalla RH3. Puoi quindi forzare l'utilizzo di quelle librerie tramite LD_LIBRARY_PATH, LD_PRELOAD ecc.

Fremo restando che è meglio se saltano fuori i sorgenti.

[kingv]

ho provato ma non riesco a farlo:

ldd /usr/bin/XXX
libc.so.6 => /lib/tls/libc.so.6 (0x009eb000)
/lib/ld-linux.so.2 (0x009cd000)

[root@db7 ~]# LD_LIBRARY_PATH=/root/mylib/:/root/mylib/tls/ /usr/bin/XXX
/usr/bin/XXX: relocation error: /root/mylib/tls/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference

[ilsensine]

ho provato ma non riesco a farlo:

ldd /usr/bin/XXX
libc.so.6 => /lib/tls/libc.so.6 (0x009eb000)
/lib/ld-linux.so.2 (0x009cd000)

Eh questa è buffa, usa solo le libc (ld-linux non è una vera libreria ma è il loader). Escludendo una (improbabile anche se possibile) incompatibilità tra le due libc, sarei propenso a un più probabile bug del programma che solo per caso non si presentava con le libc di RH3.
Solo i sorgenti possono aiutarti a questo punto.

[kingv]

Eh questa è buffa, usa solo le libc (ld-linux non è una vera libreria ma è il loader). Escludendo una (improbabile anche se possibile) incompatibilità tra le due libc, sarei propenso a un più probabile bug del programma che solo per caso non si presentava con le libc di RH3.
Solo i sorgenti possono aiutarti a questo punto.


ti ringrazio per il supporto, appena riescono a ritrovarmi i sorgenti li guardo e provo a ricompilarlo.