# [star] segfault

## chris972

Bonjour,

Après de bonnes heures de recherches, je passe voir ici s'il y aurait un expert en debuggage qui pourrait me sauver la mise

Je brosse la situation :

Depuis de nombreuses années je me suis fait mon petit script de backup qui rempli mon besoin et qui me sauve le contenu de mes disques selon mes souhaits. Il est basé sur star, afin de sauvegarder aussi les acl dont je ne me prive pas.

Une machine qui n'avait pas été mise à jour depuis plusieurs mois l'a été le 26 Février de cette année.

Depuis cette mise à jour, mon script de backup sur cette machine plante tous les jours, mais je n'avais pas eu le temps de me pencher sur la question.

Aujourd'hui, je tente de trouver une réponse.

Voici réduite à sa plus simple expression, ce qui provoque le segfault :

```
# star -c C=/ . > /other/test.tar

star: 'tmp/conftest1044' unsupported file type 'socket'. Not dumped.

*** buffer overflow detected ***: star terminated

======= Backtrace: =========

/lib64/libc.so.6(__fortify_fail+0x37)[0x7f47017aeba3]

/lib64/libc.so.6(+0xe3d7c)[0x7f47017acd7c]

star[0x424f7a]

star[0x417d3a]

star[0x418977]

======= Memory map: ========

00400000-00451000 r-xp 00000000 09:02 1089379                            /usr/bin/star

00650000-00651000 r--p 00050000 09:02 1089379                            /usr/bin/star

00651000-00654000 rw-p 00051000 09:02 1089379                            /usr/bin/star

00654000-00678000 rw-p 00000000 00:00 0

01b12000-01b4e000 rw-p 00000000 00:00 0                                  [heap]

7f46ff5f8000-7f46ff60c000 r-xp 00000000 09:02 117368                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1

7f46ff60c000-7f46ff80c000 ---p 00014000 09:02 117368                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1

7f46ff80c000-7f46ff80d000 r--p 00014000 09:02 117368                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1

7f46ff80d000-7f46ff80e000 rw-p 00015000 09:02 117368                     /usr/lib64/gcc/x86_64-pc-linux-gnu/4.5.3/libgcc_s.so.1

7f46ff80e000-7f46ff824000 r-xp 00000000 09:02 785418                     /lib64/libz.so.1.2.5

7f46ff824000-7f46ffa23000 ---p 00016000 09:02 785418                     /lib64/libz.so.1.2.5

7f46ffa23000-7f46ffa24000 r--p 00015000 09:02 785418                     /lib64/libz.so.1.2.5

7f46ffa24000-7f46ffa25000 rw-p 00016000 09:02 785418                     /lib64/libz.so.1.2.5

7f46ffa25000-7f46ffa27000 r-xp 00000000 09:02 785558                     /lib64/libdl-2.13.so

7f46ffa27000-7f46ffc27000 ---p 00002000 09:02 785558                     /lib64/libdl-2.13.so

7f46ffc27000-7f46ffc28000 r--p 00002000 09:02 785558                     /lib64/libdl-2.13.so

7f46ffc28000-7f46ffc29000 rw-p 00003000 09:02 785558                     /lib64/libdl-2.13.so

7f46ffc29000-7f46ffda5000 r-xp 00000000 09:02 989474                     /usr/lib64/libcrypto.so.1.0.0

7f46ffda5000-7f46fffa5000 ---p 0017c000 09:02 989474                     /usr/lib64/libcrypto.so.1.0.0

7f46fffa5000-7f46fffbe000 r--p 0017c000 09:02 989474                     /usr/lib64/libcrypto.so.1.0.0

7f46fffbe000-7f46fffc8000 rw-p 00195000 09:02 989474                     /usr/lib64/libcrypto.so.1.0.0

7f46fffc8000-7f46fffcc000 rw-p 00000000 00:00 0

7f46fffcc000-7f470001f000 r-xp 00000000 09:02 990108                     /usr/lib64/libssl.so.1.0.0

7f470001f000-7f470021f000 ---p 00053000 09:02 990108                     /usr/lib64/libssl.so.1.0.0

7f470021f000-7f4700222000 r--p 00053000 09:02 990108                     /usr/lib64/libssl.so.1.0.0

7f4700222000-7f4700227000 rw-p 00056000 09:02 990108                     /usr/lib64/libssl.so.1.0.0

7f4700227000-7f4700239000 r-xp 00000000 09:02 785559                     /lib64/libresolv-2.13.so

7f4700239000-7f4700439000 ---p 00012000 09:02 785559                     /lib64/libresolv-2.13.so

7f4700439000-7f470043a000 r--p 00012000 09:02 785559                     /lib64/libresolv-2.13.so

7f470043a000-7f470043b000 rw-p 00013000 09:02 785559                     /lib64/libresolv-2.13.so

7f470043b000-7f470043d000 rw-p 00000000 00:00 0

7f470043d000-7f470044b000 r-xp 00000000 09:02 990177                     /usr/lib64/liblber-2.4.so.2.8.3

7f470044b000-7f470064a000 ---p 0000e000 09:02 990177                     /usr/lib64/liblber-2.4.so.2.8.3

7f470064a000-7f470064b000 r--p 0000d000 09:02 990177                     /usr/lib64/liblber-2.4.so.2.8.3

7f470064b000-7f470064c000 rw-p 0000e000 09:02 990177                     /usr/lib64/liblber-2.4.so.2.8.3

7f470064c000-7f4700690000 r-xp 00000000 09:02 990173                     /usr/lib64/libldap-2.4.so.2.8.3

7f4700690000-7f470088f000 ---p 00044000 09:02 990173                     /usr/lib64/libldap-2.4.so.2.8.3

7f470088f000-7f4700890000 r--p 00043000 09:02 990173                     /usr/lib64/libldap-2.4.so.2.8.3

7f4700890000-7f4700892000 rw-p 00044000 09:02 990173                     /usr/lib64/libldap-2.4.so.2.8.3

7f4700892000-7f47008a5000 r-xp 00000000 09:02 785807                     /lib64/libnss_ldap-2.13.so

7f47008a5000-7f4700aa5000 ---p 00013000 09:02 785807                     /lib64/libnss_ldap-2.13.so

7f4700aa5000-7f4700aa6000 r--p 00013000 09:02 785807                     /lib64/libnss_ldap-2.13.so

7f4700aa6000-7f4700aa7000 rw-p 00014000 09:02 785807                     /lib64/libnss_ldap-2.13.so

7f4700aa7000-7f4700ab2000 rw-p 00000000 00:00 0

7f4700ab2000-7f4700abd000 r-xp 00000000 09:02 785336                     /lib64/libnss_files-2.13.so

7f4700abd000-7f4700cbc000 ---p 0000b000 09:02 785336                     /lib64/libnss_files-2.13.so

7f4700cbc000-7f4700cbd000 r--p 0000a000 09:02 785336                     /lib64/libnss_files-2.13.so

7f4700cbd000-7f4700cbe000 rw-p 0000b000 09:02 785336                     /lib64/libnss_files-2.13.so

7f4700cbe000-7f47014c4000 rw-s 00000000 00:04 4250672                    /dev/zero

7f47014c4000-7f47014c8000 r-xp 00000000 09:02 785552                     /lib64/libattr.so.1.1.0

7f47014c8000-7f47016c7000 ---p 00004000 09:02 785552                     /lib64/libattr.so.1.1.0

7f47016c7000-7f47016c8000 r--p 00003000 09:02 785552                     /lib64/libattr.so.1.1.0

7f47016c8000-7f47016c9000 rw-p 00004000 09:02 785552                     /lib64/libattr.so.1.1.0

7f47016c9000-7f4701841000 r-xp 00000000 09:02 785564                     /lib64/libc-2.13.so

7f4701841000-7f4701a40000 ---p 00178000 09:02 785564                     /lib64/libc-2.13.so

7f4701a40000-7f4701a44000 r--p 00177000 09:02 785564                     /lib64/libc-2.13.so

7f4701a44000-7f4701a45000 rw-p 0017b000 09:02 785564                     /lib64/libc-2.13.so

7f4701a45000-7f4701a4a000 rw-p 00000000 00:00 0

7f4701a4a000-7f4701a51000 r-xp 00000000 09:02 785550                     /lib64/libacl.so.1.1.0

7f4701a51000-7f4701c51000 ---p 00007000 09:02 785550                     /lib64/libacl.so.1.1.0

7f4701c51000-7f4701c52000 r--p 00007000 09:02 785550                     /lib64/libacl.so.1.1.0

7f4701c52000-7f4701c53000 rw-p 00008000 09:02 785550                     /lib64/libacl.so.1.1.0

7f4701c53000-7f4701c72000 r-xp 00000000 09:02 785351                     /lib64/ld-2.13.soAbandon
```

Ce que j'ai déjà fait (je ne garantie pas que tout soit intelligent) :

- recompiler star,

- recompiler tout ce dont dépend star

- recompiler tout ce qui a été mis à jour le 26/02 et qui n'a pas été MAJ depuis

- downgrader star à la précédente version que j'avais sur cette machine et qui ne plantait pas.

- ouvrir un bug, mais mon anglais étant plus qu'approximatif, j'ai le sentiment qu'il n'est pas pris au sérieux, ou alors, je ne saisi pas ce que devraient m'apporter les réponses.

Pour info :

- la machine est à jour, et à priori, n'a pas d'autre défaut que celui-ci. Elle tourne avec un noyau openvz, arch amd64.

Ce qu'il me reste à tenter :

- RIEN. Je ne vois plus quoi faire, et ça, c'est le pire.

Personnellement, l'erreur ne me parle pas du tout. Alors si ça parle à l'un de vous, n'hésitez pas à donner votre sentiment.

Merci.

----------

## netfab

Salut,

Voilà ce que tu peux tenter par la suite : activer les paramètres voulus pour obtenir une backtrace via gdb.

Voir ici : http://www.gentoo.org/proj/en/qa/backtraces.xml

Quand je lis le changelog de star, je note que cette version date d'il y a environ 2 ans.

Or, lorsqu'on s'interesse aux archives récentes de la mailing-list du projet, on trouve ce thread : [Star-users] Buffer overflow in name_to_tcb  

A creuser...

----------

## chris972

Oui oui, je ne cesse de lire et relire ce thread et plusieurs autres.

Il semblerait que cela vienne en fait du compilateur gcc 4.5.3 auquel je suis effectivement passé lors de cette mise à jour.

Est-ce une option de compilation de star ? du compilateur lui-même ? ou autre chose ?

Je continue mes investigations.

Merci.

----------

## chris972

Bon, je ne comprends certainement pas tout des tenants et aboutissants, mais j'ai appliqué le patch dont il est question https://bugzilla.redhat.com/show_bug.cgi?id=556664 et ça semble passer.

Par contre, ce que je suis sûr de ne pas comprendre, c'est que ce pach soit appliqué chez redhat depuis début 2010, que ça ne soit pas le cas chez gentoo, que personne n'en parle, mais surtout, que lorsque je remonte le bug, le seul interlocuteur qui me réponde semble (je dis semble parce que j'avoue ne pas comprendre grand chose à ses réponses) ne pas prendre la chose au sérieux.

Bon ben du coup je suis bon pour me gérer star en overlay moi, chouette, un de plus.

----------

## netfab

 *chris972 wrote:*   

> 
> 
> Par contre, ce que je suis sûr de ne pas comprendre, c'est que ce pach soit appliqué chez redhat depuis début 2010, que ça ne soit pas le cas chez gentoo, que personne n'en parle, mais surtout, que lorsque je remonte le bug, le seul interlocuteur qui me réponde semble (je dis semble parce que j'avoue ne pas comprendre grand chose à ses réponses) ne pas prendre la chose au sérieux.
> 
> 

 

Le commentaire #3 de ton bug semble indiquer que ce n'est pas le seul buffer overflow potentiel du logiciel, et en lisant un peu plus la mailing-list de star, on s'aperçoit que le développeur du projet n'a pas l'air de vouloir y faire grand chose puisqu'il estime que l'utilisateur compile avec des CFLAGS trop strictes ou que c'est de la faute de gcc car ce sont des faux positifs. A mon avis c'est pour cette raison que les choses trainent : ce n'est pas le rôle du dev gentoo de corriger les problèmes du soft à la place du dev upstream.

----------

## chris972

C'est sur que ce n'est pas son role, mais ce n'est pas non plus son role de laisser dans l'arbre un soft dont il sait qu'il plante, sans rien faire, alors qu'un patch est connu depuis 2 ans.

----------

## guilc

 *chris972 wrote:*   

> C'est sur que ce n'est pas son role, mais ce n'est pas non plus son role de laisser dans l'arbre un soft dont il sait qu'il plante, sans rien faire, alors qu'un patch est connu depuis 2 ans.

 

Estime toi heureux qu'il soit encore dans portage  :Wink: 

Un programme qui a un patch corrigeant des bugs connu depuis 2 ans, et toujours pas intégré par l'upstream, c'est un projet soit mort, soit qui souffre d'importants problèmes de qualité (soit que l'upstream soit une grosse tête de lard qui se croit plus fort que gcc). Ceci étant autant de motifs pour le virer de portage  :Razz: 

Une solution classique pour sauvegarder les ACL :

tu fais d'une part ton tar avec tar gnu, et un petit coup de "getfacl -R > mes-acls.acl", tu sauvegardes mes-acls.acl puis "setfacl --restore=mes-acls.acl" lors de la restoration

----------

