-1

I have a code where i compile & load it in vxworks machine, i see the buffer overflow.

#include<strstream>
#include<iostream>
#include<sstream>

using namespace std;

ostrstream *strm = 0;

int newcout()
{
  if(strm == 0)
  {
    strm = new ostrstream();
  }

  while(1)
  {

   (*strm)<<".VXworks_print"<<endl;

  }
return 0;
}

The problem here is, the memory request keeps on doublingfor every loop in while.

[maxBlock = 8497968/ allocSize = 12700]

[maxBlock = 8485176/ allocSize = 25500]

[maxBlock = 8459584/ allocSize = 51100]

[maxBlock = 8408392/ allocSize = 102300]

[maxBlock = 8306000/ allocSize = 204700]

[maxBlock = 8101208/ allocSize = 409500]

[maxBlock = 7691616/ allocSize = 819100]

[maxBlock = 7086744/ allocSize = 1638300]

[maxBlock = 7086744/ allocSize = 3276700]

[maxBlock = 7086744/ allocSize = 6553500]

[maxBlock = 8497288/ allocSize = 13107100]

when the alllocation request is going beyond max available block, it is resulting in trap.

I think we are seeing this behavior because of re-using ostrstream object.

How to correct this behavior?

m0nhawk
  • 22,980
  • 9
  • 45
  • 73
prashanth cm
  • 49
  • 1
  • 1
  • 4
  • 1
    [ostrstream](http://en.cppreference.com/w/cpp/io/ostrstream) has been deprecated, and no new code should be written that uses it (you should be working with [std::ostringstream](http://en.cppreference.com/w/cpp/io/basic_ostringstream) instead) – utnapistim Sep 22 '15 at 09:25
  • 1
    Also, endl operator isn't just the "end of line" - it also makes a flush() call. I strongly recommend you to replace it with '\n' and call flush() outside the loop. – smyatkin_max Sep 22 '15 at 09:30

2 Answers2

1

As per the documentation your ostrstream will keep allocating memory for each call. This memory is never freed. To avoid this, declare the ostream as local object (in the stack) and call the freeze(false) once you are done (after each str()) this way the memory is freed when the destructor of the ostream is called.

from: http://en.cppreference.com/w/cpp/io/ostrstream/freeze

After a call to str(), dynamic streams become frozen automatically. A call to freeze(false) is required before exiting the scope in which this ostrstream object was created. otherwise the destructor will leak memory. Also, additional output to a frozen stream may be truncated once it reaches the end of the allocated buffer.

rkachach
  • 16,517
  • 6
  • 42
  • 66
  • even str() & freeze(false) is not solving the issue!! Tried keeping ostrstream object as local, but that didnt work as well. – prashanth cm Sep 24 '15 at 07:35
0

As someone else already said in the comments, ostrstream is decprecated.

Furthermore this is c++ not java, you shouldn't use new to allocate a resource.

Just declare the object on the stack.

ostrstream strm;

And you could consider forgetting the c++ streaming stuff, its syntax and look is rather clunky. Personally I prefer the good old printf, even when its not type-safe - it just is way more compact.

A.Franzen
  • 725
  • 4
  • 10
  • 6
    Your last suggestion is unarguably **bad**. Don’t do this. Don’t recommend this. If you don’t like the C++ streaming syntax, use a proper formatting library instead. Do not use `printf`. Not only is it not type safe, it’s also simply not extensible, rendering it useless in properly written C++ code. – Konrad Rudolph Sep 22 '15 at 09:36
  • NOTHING is unarguable. Programming is not a science but a craft. And in this case one has to chose between readability, maintainability and type-safety. A printf is not inherently worse than an unreadably, endless stream chain. And what exactly do you mean by extensible ? – A.Franzen Sep 22 '15 at 14:11
  • Every nontrivial C++ program contains non-builtin types that you need to pretty-print sooner or later. `printf` cannot handle this, full stop. C++ streams (and other formatting libraries) can. – Konrad Rudolph Sep 22 '15 at 14:16
  • Yes, but who would pass a custom type to a printf ? The solution for pretty printing is to have a toString() method in your custom type. – A.Franzen Sep 22 '15 at 14:19
  • “who would pass …” — nobody, because it doesn’t work. *That’s the issue*. Your “solution” is cruft. It is *not* a good solution. It’s not terrible but there’s simply not a single technical argument why it would be better or even on par with using the proper C++ mechanism. For one thing, it doesn’t compose: try outputting a vector of objects. With C++ streams (or equivalent), you can do `for_each(begin(vec), end(vec), ostream_iterator(…))`. The salient point here isn’t the existence of this function, though, but the general principle of composability, which is badly supported with `printf`. – Konrad Rudolph Sep 22 '15 at 14:21
  • Sigh. I never said you were wrong except for the "unarguably" part. I still hold that the C++ stream handling is WAY to complicated. Especially when you do extensive formatting. You rarely see it in commercial production code, because most people agree that it is to clunky. – A.Franzen Sep 22 '15 at 14:29
  • Konrad : neither does the proper C++ mechanism work. You still have to write a << operator for your custom class. It is not automatic. So I don't find your solution unarguably superior. – SJHowe Feb 15 '22 at 10:21