Databases
StackOverflow2013
Postsdbo
POWhere is my program's stdout's setbase(16) being called?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhere is my program's stdout's setbase(16) being called?
    primarykey
    data
    text
    <p>I have a somewhat large project that I am working on and I've discovered that someone added some code something similar to this:</p> <pre><code>std::cout &lt;&lt; std::hex &lt;&lt; variable &lt;&lt; endl; </code></pre> <p>Aside from grepping through all the cout calls and manually looking at each one, is there a way to determine which offending cout line left the output stream's base as hex?</p> <p>It seems that there's many different ways of setting the base so setting a breakpoint on a single function call doesn't seem to work. e.g.:</p> <ul> <li><code>... &lt;&lt; std::hex &lt;&lt; ...</code></li> <li><code>... &lt;&lt; setbase(16) &lt;&lt; ...</code></li> <li><code>std::cout.setf ( std::ios::hex, std::ios::basefield );</code></li> <li>etc.</li> </ul> <p>Is there any quick way i can tell what variable internally libstdc++ is using to store the base variable so i can set a data breakpoint on it?</p> <h2>UPDATE:</h2> <p>After playing around with the code I was finally able to come up with the solution using in part both answers from perreal and Employed Russian. Here is what I did:</p> <p>First I added the following code inside my program so I could break and step into the function to get the address of the cout flags variable (_M_flags).</p> <pre><code>std::ios_base::fmtflags f; f = std::cout.flags(); </code></pre> <p>I set a breakpoint on the second line and stepped into the function and got the following libstdc++ code:</p> <pre><code>// [27.4.2.2] fmtflags state functions /** * @brief Access to format flags. * @return The format control flags for both input and output */ fmtflags flags() const { return _M_flags; } </code></pre> <p>Unfortunately gdb was unable to print out this variable but by going to the disassembly view I was able to pinpoint the address used by _M_flags:</p> <pre><code> x0x84ca2e8 &lt;std::ios_base::flags() const&gt; push %ebp x0x84ca2e9 &lt;std::ios_base::flags() const+1&gt; mov %esp,%ebp x0x84ca2eb &lt;std::ios_base::flags() const+3&gt; mov 0x8(%ebp),%eax &gt;x0x84ca2ee &lt;std::ios_base::flags() const+6&gt; mov 0xc(%eax),%eax x0x84ca2f1 &lt;std::ios_base::flags() const+9&gt; pop %ebp x0x84ca2f2 &lt;std::ios_base::flags() const+10&gt; ret </code></pre> <p><code>0xc(%eax)</code> contained the address of _M_flags.</p> <p>After I got the address, it was fairly trivial to set a conditional hardware watchpoint on it to see when the hex bit changes and track down the offending code.</p> <p>It turns out a .so object loaded at runtime via dlopen was the culprit.</p> <p>I ended up using Boost IO State Savers as referenced by this <a href="https://stackoverflow.com/questions/1513625/c-how-to-reset-the-output-stream-manipulator-flags">question</a> to resolve the issue.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCommunity
    1. USPaul
    plurals
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhere is my program's stdout's setbase(16) being called?
      1. This table or related slice is empty.
      1. VTUpMod
    1. This table or related slice is empty.
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload