Bugzilla – Full Text Bug Listing |
Summary: | Coojaloader gives unexpected output in case of using istringstream in C++ | ||
---|---|---|---|
Product: | dce | Reporter: | Hans van den Bogert <hansbogert> |
Component: | other | Assignee: | Hajime Tazaki <tazaki> |
Status: | CONFIRMED --- | ||
Severity: | major | CC: | ns-bugs |
Priority: | P5 | ||
Version: | unspecified | ||
Hardware: | PC | ||
OS: | Linux |
Description
Hans van den Bogert
2014-09-18 03:14:00 EDT
in the bug description there is an error:
> We'd expect _M_impl and _S_classic to point to the same memory address after line 221, however this is not the case.
Should be:
"We'd expect _M_impl and *_S_global* to point to the same memory address after line 221, however this is not the case."
Further investigation shows that during static initialization (so even before the main function of the virtualized executable is run) the C++ library makes a wrong default locale. The locale is filled with facets, which handle aspects of a locale. However during the init-phase of this default locale one facet -- codecvt_w -- seems to get a wrong 'id'. That id is used as an index for a facet-vector inside the default locale. By having a wrong id, the standard library does not check this, it overwrites our num_get facet, which is responsible for converting input (character)streams to numbers and so the wrong behaviour arises. I do not know how this wrong 'id' is given to the facet but I suspect wrong use of statics from the non-virtualized stdlibc++. The addition of thread-safety constructs in the stdlibc++ and GDB not showing addresses correctly (I suspect), for static variables when introspected makes this extremely difficult to debug. I hope this helps. (In reply to Hans van den Bogert from comment #2) > Further investigation shows that during static initialization (so even > before the main function of the virtualized executable is run) the C++ > library makes a wrong default locale. The locale is filled with facets, > which handle aspects of a locale. However during the init-phase of this > default locale one facet -- codecvt_w -- seems to get a wrong 'id'. That id > is used as an index for a facet-vector inside the default locale. By having > a wrong id, the standard library does not check this, it overwrites our > num_get facet, which is responsible for converting input (character)streams > to numbers and so the wrong behaviour arises. > > I do not know how this wrong 'id' is given to the facet but I suspect wrong > use of statics from the non-virtualized stdlibc++. The addition of > thread-safety constructs in the stdlibc++ and GDB not showing addresses > correctly (I suspect), for static variables when introspected makes this > extremely difficult to debug. > > I hope this helps. I believe locale-related symbols are not appropriately handled by DCE: these should be handled manually which are done by following codes. http://code.nsnam.org/ns-3-dce/file/579cac731917/model/libc-global-variables.cc http://code.nsnam.org/ns-3-dce/file/579cac731917/model/libc-setup.cc I couldn't allocate my time to investigate it, but hope this helps a bit for you. You mean to say that those 2 files are examples of how other globals are handled, or should those 2 files fix my issue? (In reply to Hans van den Bogert from comment #4) > You mean to say that those 2 files are examples of how other globals are > handled, or should those 2 files fix my issue? Yes, but with a quick look and code changes didn't give me a direction how it should handle (that's why I mentioned I need more time). |