Que signifie cette trace de pile liée à std :: ostream?

Question

J'essaye de construire une bibliothèque C++ pour une plate-forme intégrée/mobile. La plate-forme a un ensemble décent de libs, y compris stdC++. La librairie que j'essaie de construire utilise ofstream et chaque fois qu'elle essaye d'utiliser une classe qui dépend d'ofstream, j'obtiens une exception 'bad_cast'.

0 0xb082d9b1 in SignalKill() 
    from /home/preet/bbndk-2.0.1/target/qnx6/x86/lib/libc.so.3 

1 0xb081aa7e in raise() 
    from /home/preet/bbndk-2.0.1/target/qnx6/x86/lib/libc.so.3 

2 0xb0818cb8 in abort() 
    from /home/preet/bbndk-2.0.1/target/qnx6/x86/lib/libc.so.3 

3 0xb87c48bf in __gnu_cxx::__verbose_terminate_handler() 
    at ../../../../../libstdc++-v3/libsupc++/vterminate.cc:93 

4 0xb87c23d6 in __cxxabiv1::__terminate (
    handler=0xb87c47c0 <__gnu_cxx::__verbose_terminate_handler()>) 
    at ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38 

5 0xb87c2421 in std::terminate() 
    at ../../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48 

6 0xb87c2563 in __cxxabiv1::__cxa_throw (obj=0x859e710, tinfo=0xb87f4c24, 
    dest=0xb87c0670 <std::bad_cast::~bad_cast()>) 
    at ../../../../../libstdc++-v3/libsupc++/eh_throw.cc:83 

7 0xb875e88c in std::__throw_bad_cast() 
    at ../../../../../libstdc++-v3/src/functexcept.cc:52 

8 0xb8798c0d in __check_facet<std::ctype<char> > (__f=<optimized out>) 
    at /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntox86/i486-pc-nto-qnx6.5.0/pic/libstdc++-v3/include/bits/basic_ios.h:49 

9 widen (__c=<optimized out>, this=<optimized out>) 
    at /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntox86/i486-pc-nto-qnx6.5.0/pic/libstdc++-v3/include/bits/basic_ios.h:440 

10 std::endl<char, std::char_traits<char> > (__os=...) 
    at /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntox86/i486-pc-nto-qnx6.5.0/pic/libstdc++-v3/include/ostream:539 

11 0xb8793c2d in std::ostream::operator<< (this=0x84db220, 
    __pf=0x804f64c <_ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_@plt>) 
    at /home/builder/hudson/650-gcc-4.4/svn/linux-x86-o-ntox86/i486-pc-nto-qnx6.5.0/pic/libstdc++-v3/include/ostream:113 

12 0x0805240d in QDecViewport::QDecViewport (this=0x86da6c0, parent=0x0) 
    at ../qml_osg_viewport/qdecviewport.cpp:12 

13 0x08051cca in QDeclarativePrivate::QDeclarativeElement<QDecViewport>::QDeclarativeElement (this=0x86da6c0) 
    at /usr/local/Trolltech/QtLighthouse-4.8.2-i386/include/QtDeclarative/qdeclarativeprivate.h:83 

14 0x08051d3c in QDeclarativePrivate::createInto<QDecViewport> (
    memory=0x86da6c0) 
    at /usr/local/Trolltech/QtLighthouse-4.8.2-i386/include/QtDeclarative/qdeclarativeprivate.h:91 

15 0xb8ad5ec5 in ??() 

16 0x086da6c0 in ??() 

17 0x00000000 in ??() 

Les cadres 7-11 sont pertinents et ceux dont j'ai besoin aident à comprendre. La ligne de trame de code 12 fait référence est juste:

OSG_INFO << "Hello OSG" << std::endl; 

Où OSG_INFO est un redirecteur de flux utilisé pour l'exploitation forestière. Je suis capable d'utiliser std :: cout de la même manière sans aucun problème. cadre Unmangling 11 me donne:

__pf=0x804f64c <std::basic_ostream<char, std::char_traits<char> >& std::endl<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&)@plt>) 

Ce qui est encore assez cryptique ... et je comprendrais les choses de devenir fou si peut-être je suis en train de passer quelque chose de vraiment étrange à l'opérateur de sortie ofstream, mais son texte juste. Est-ce que quelqu'un a des suggestions?

Answer 1

std::endl a le comportement suivant, citant 11 §27.7.3.8/1 C++:

Appels os.put(os.widen('\n')), puis os.flush().

Cadre 9 dit que l » appel endl à widen ne parvient pas, à savoir que OSG_INFO.widen('\n') échoue. widen, à son tour, a le comportement suivant (§27.5.5.3/12):

Retours:use_facet< ctype<char_type> >(getloc()).widen(c)

use_facet se jetteront bad_cast si la facette n'est pas présent dans les paramètres régionaux Imprégnée (§22.3.2/3), mais votre trace de pile n'indique pas que c'est le cas. (Là encore, je ne l'ai pas creusé par la libstdc de internals pour vérifier qu'il fait des choses par le livre ...)

Je suppose que __check_facet est appelée avant use_facet (ou use_facet a été inline et a disparu de la trace de la pile) , avec le même effet net; cela implique que OSG_INFO a été imprégné de certains paramètres régionaux qui n'ont pas la std::ctype<char> facette présente – mauvais moments! En outre, il est possible qu'il ait été imprégné de certains paramètres régionaux avec un présent de facette qui ne gère simplement pas widen('\n') avec élégance. Mais il n'y a aucun moyen de savoir à coup sûr, et rien d'autre que nous pouvons vous dire, sans savoir ce que OSG_INFO est et/ou comment il est mis en œuvre.