Le programme C ++ se bloque toujours tout en effectuant une affectation std :: string

J'ai essayé de déboguer un crash dans mon application qui plante (c'est à dire, affirme un
* glibc détecté * free(): pointeur non valide: 0x000000000070f0c0 ***) alors que je suis en train de faire un simple attribuer à une chaîne. Notez que je compile sur un système linux avec gcc 4.2.4 avec un niveau d'optimisation-O2. Avec -O0 l'application ne plante plus.

E. g.

std::string abc;

abc = "testString";

mais si j'ai modifié le code comme suit elle ne se bloque plus

std::string abc("testString");

Encore une fois, je grattais la tête! Mais la tendance intéressante est que le crash a déménagé plus tard dans l'application, NOUVEAU à une autre chaîne. Je l'ai trouvé bizarre que la demande a été continuellement de s'écraser sur une chaîne de céder. Typique d'un crash backtrace se présenterait comme suit:

#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
(gdb) bt
#0  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#1  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#2  0x00000000004d8cb7 in people_streamingserver_sighandler (signum=6) at src/peoplestreamingserver.cpp:487
#3  <signal handler called>
#4  0x00007f2c2663bfb5 in raise () from /lib64/libc.so.6
#5  0x00007f2c2663dbc3 in abort () from /lib64/libc.so.6
#6  0x00007f2c26680ce0 in ?? () from /lib64/libc.so.6
#7  0x00007f2c270ca7a0 in std::string::assign (this=0x7f2c21bc8d20, __str=<value optimized out>)
    at /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:238
#8  0x00007f2c21bd874a in PEOPLESProtocol::GetStreamName (this=<value optimized out>,
    pRawPath=0x2342fd8 "rtmp://127.0.0.1/mp4:pop.mp4", lStreamName=@0x7f2c21bc8d20)
    at /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491
#9  0x00007f2c21bd9daa in PEOPLESProtocol::SignalProtocolCreated (pProtocol=0x233a4e0, customParameters=@0x7f2c21bc8de0)
    at peoplestreamer/src/peoplesprotocol.cpp:240

C'était vraiment le comportement bizarre et j'ai donc commencé à fouiller plus loin dans mon application pour voir si il y avait une sorte de corruption de la mémoire (heap ou la pile) erreur qui pourrait se produire qui pourrait être à l'origine de ce comportement étrange. J'ai même vérifié pour les ptr corruptions et est venu les mains vides. En plus de l'inspection visuelle du code j'ai aussi essayé les outils suivants:

  • Valgrind à l'aide de deux memcheck et exp-ptrcheck
  • clôture électrique
  • libsafe
  • J'ai compilé avec -fstack-protector-le tout dans gcc
  • J'ai essayé MALLOC_CHECK_ 2
  • J'ai couru mon code par le biais de la charpie de contrôles ainsi que des cppcheck (à vérifier pour les erreurs)
  • Et je traversai le code à l'aide de gdb

Alors, j'ai essayé beaucoup de choses et encore venu les mains vides. Donc je me demandais si il pourrait être quelque chose comme un linker question ou une bibliothèque de problème de quelque sorte qui pourrait être à l'origine de ce problème. Existe-il des problèmes connus avec les std::string qui font est susceptible de s'écraser en -O2 ou peut-être qu'il n'a rien à voir avec le niveau d'optimisation? Mais le seul modèle que je vois à ce jour dans mon problème est qu'il semble toujours se crash sur une chaîne et donc je me demandais si quelqu'un connaissait des problèmes qui peuvent être à l'origine de ce type de comportement.

Merci beaucoup!

source d'informationauteur bbazso

  1. 10

    C'est une estimation initiale à l'aide de tous les renseignements que je peut extraire de votre trace.

    Vous êtes le plus susceptible de mélanger et assortir version de gcc, éditeur de liens et libstdc++ qui entraîne un comportement inhabituel de la machine hôte:

    1. libc est le système de l': /lib64/libc.so.6
    2. libstdc++ est dans un "Tiers" directory - c'est des soupçons, comme il me dit qu'il peut être compilé ailleurs avec une cible différente - /home/bbazso/ThirdParty/sources/gcc-4.2.4/x86_64-pc-linux-gnu/libstdc++-v3/
    3. Encore un autre libstdc++ dans /opt: /opt/trx-HEAD/gcc/4.2.4/lib/gcc/x86_64-pc-linux-gnu/4.2.4/../../../../include/c++/4.2.4/bits/basic_string.h:491

    En outre, la CCG peut mélanger du système ld au lieu de lui-même qui peut causer d'autres bizarre cartes mémoire d'utilisation.

  2. 7

    Pouvez-vous répéter la collision avec une base de deux programme en ligne?

    #include <string>

int main()
{
    std::string abc;
    abc = "testString";
}

    Si qui tombe en panne, merci de poster votre exacte de la compilation /options de lien?

    Sinon, commencez à éplucher en bas de votre code. Supprimer des lignes d'une poignée à un moment jusqu'à ce que le bug disparaît. Une fois que vous avez quelques autres changement, vous pouvez ajouter à la cause de l'accident, et l'enlever pour le faire disparaître, ce qui devrait vous aider à localiser le problème.

  3. 0

    Comme vous l'avez dit c'est un comportement bizarre.

    Pour être honnête je pense que vous perdez du temps à la recherche dans un possible bug avec std::les chaînes de caractères. Les chaînes de caractères sont parfaitement en sécurité aussi longtemps que vous les utilisez.

    De toute façon, avec les informations que vous donnez :
    Tout d'abord, êtes-vous à l'aide de threads ? C'est peut-être un fil de problème.
    Deuxièmement, vous vérifiez votre programme à l'aide de valgrind. N'avez-vous pas des avertissements à tous ?

    Remarque : La plupart des critiques valgrind des mises en garde ne sont pas valides lire et invalides écrire.

    PS : Comme dit dans les commentaires, vous devriez probablement utiliser g++ pour compiler du code C++;)

  4. 0

    M'est arrivé à cause de l'utilisation de malloc pour une classe qui a std::les chaînes de caractères comme membres de données. Délicat.