Memory allocation problem!

Hi,

I have the following piece of code that is designed to help me add
debug traces to my program (I wanted to use purely C++ code, but the
only way I know how to do something like this is with macros, so please
don't yell at me):

#include <iostream>
#include <cstdarg>
#include <iomanip>

#define MainDisplay(s, ...) Show( __FILE__, \
__PRETTY_FUNCTION__,\
__LINE__, \
s, \
## __VA_ARGS__);
using namespace std;

void Show(const char* file, const char* fcn, int line, const char*
display, ...)
{
//build display string
va_list va;
va_start(va, display);
char display2[256];
char linestr[10];
vsprintf(display2, display, va);
va_end(va);
sprintf(linestr, "%d", line);

string s = (file + string(" [") + linestr + string("]:"));

//output to console
cout << s;
int ssize = s.size();
if (ssize <= 45) cout << setw(50-ssize) << "" << display2;
else cout << endl << setw(50) << "" << display2;
}

Now I want it to display a very long string message (this string has
548 characters in it):

int main(int argc, char *argv[])
{

MainDisplay("0000000101010101010101010101010101010 10101010101010101010101010101010101010101010101010 10101010101111111111111111111111111111111111111100 01000000101100010001000001100111101000110001010011 10011010011100110100110110111111111111111111111111 11111111111111011010100110011100101100000000101010 10101010101010101010101010101010101010101010101010 10101010101010101010101010101010101111111111111111 11111111111111111111110001000000101100010001000001 10011110100011000101001110011010011100110100110110 11111111111111111111111111111111111111011010100110 01110010110");

return EXIT_SUCCESS;
}

When I run this code I get a segmentation fault, and GDB spews the
following:

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaab06f6a0 in strlen () from /lib64/tls/libc.so.6
(gdb) backtrace
#0 0x00002aaaab06f6a0 in strlen () from /lib64/tls/libc.so.6
#1 0x0000000000401775 in std::char_traits<char>::length
(__s=0x3130313031303130 <Address 0x3130313031303130 out of bounds>) at
char_traits.h:143
#2 0x00000000004015ea in std::operator+<char, std::char_traits<char>,
std::allocator<char> > (__lhs=0x3130313031303130 <Address
0x3130313031303130 out of bounds>, __rhs=@0x7fffffffe9b0) at
basic_string.tcc:692
#3 0x0000000000401232 in Show (file=0x3130313031303130 <Address
0x3130313031303130 out of bounds>, fcn=0x3130313031303130 <Address
0x3130313031303130 out of bounds>, line=825241904,
display=0x3130313031303130 <Address 0x3130313031303130 out of bounds>)
at /home/prashant/Development/test2/src/test2.cpp:20
#4 0x3131303131313131 in ?? ()
#5 0x3131303031303130 in ?? ()
#6 0x3130303131313030 in ?? ()
#7 0x00002a0030313130 in ?? ()
#8 0x0000000000000000 in ?? ()
#9 0x0000000000503028 in ?? ()
#10 0x0000000000400e1b in _init ()
#11 0x00007fffffffed78 in ?? ()
#12 0x0000000100401801 in ?? ()
#13 0
Previous frame inner to this frame (corrupt stack?)
x00002aaaaabc0c60 in ?? () from /lib64/ld-linux-x86-64.so.2
#14 0x00002aaaaabc0c60 in ?? () from /lib64/ld-linux-x86-64.so.2
#15 0x00000000004017e0 in __libc_csu_fini ()
#16 0x00002aaaab00e1d8 in ?? () from /lib64/tls/libc.so.6
#17 0x00007fffffffed78 in ?? ()
#18 0x00000001ffffed88 in ?? ()
#19 0x0000000000401490 in Show () at
/home/prashant/Development/test2/src/test2.cpp:27
(gdb) frame 0
#0 0x00002aaaab06f6a0 in strlen () from /lib64/tls/libc.so.6

If I shorten the string, I find that I get no segmentation fault for
anything less than 313 characters. My assumption is that this is a
'new' or malloc memory limit. ulimit -a returns the following:

core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
file size (blocks, -f) unlimited
max locked memory (kbytes, -l) 32
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
stack size (kbytes, -s) unlimited
cpu time (seconds, -t) unlimited
max user processes (-u) 8191
virtual memory (kbytes, -v) unlimited

I'm running on Suse Linux 9.3 (but I've been able to reproduce this
problem on 9.0) and I'm using gcc 3.4.1.

Any Ideas?

Prashant

jois.de.vivre@gmail.com wrote:[color=blue]
> #define MainDisplay(s, ...) Show( __FILE__, \
> __PRETTY_FUNCTION__,\
> __LINE__, \
> s, \
> ## __VA_ARGS__);
> using namespace std;
>
> void Show(const char* file, const char* fcn, int line, const char*
> display, ...)
> {
> //build display string
> va_list va;
> va_start(va, display);
> char display2[256];
> char linestr[10];
> vsprintf(display2, display, va);[/color]

writing to a 256-byte buffer.

[color=blue]
> va_end(va);
> sprintf(linestr, "%d", line);
>
> string s = (file + string(" [") + linestr + string("]:"));
>
> //output to console
> cout << s;
> int ssize = s.size();
> if (ssize <= 45) cout << setw(50-ssize) << "" << display2;
> else cout << endl << setw(50) << "" << display2;
> }
>
>
> Now I want it to display a very long string message (this string has
> 548 characters in it):
>
> int main(int argc, char *argv[])
> {
>
> MainDisplay("0000000101010101010101010101010101010 10101010101010101010101010101010101010101010101010 10101010101111111111111111111111111111111111111100 01000000101100010001000001100111101000110001010011 10011010011100110100110110111111111111111111111111 11111111111111011010100110011100101100000000101010 10101010101010101010101010101010101010101010101010 10101010101010101010101010101010101111111111111111 11111111111111111111110001000000101100010001000001 10011110100011000101001110011010011100110100110110 11111111111111111111111111111111111111011010100110 01110010110");
>[/color]

sending 548 bytes into a 256 byte buffer

[color=blue]
> return EXIT_SUCCESS;
> }
>
>
>
> When I run this code I get a segmentation fault, and GDB spews the
> following:[/color]

[snip]
[color=blue]
>
> Any Ideas?
>[/color]

you are overflowing your buffer.

-shez-

jois.de.vi...@gmail.com wrote:[color=blue]
> Hi,
>
> I have the following piece of code that is designed to help me add
> debug traces to my program (I wanted to use purely C++ code, but the
> only way I know how to do something like this is with macros, so please
> don't yell at me):[/color]

For the future, you should either post in comp.lang.c++ for
C++ programs, or if for some reason you need C language input,
reduce your problem to a compilable C program and post there.
[color=blue]
>
>
> #include <iostream>
> #include <cstdarg>
> #include <iomanip>
>
> #define MainDisplay(s, ...) Show( __FILE__, \
> __PRETTY_FUNCTION__,\
> __LINE__, \
> s, \
> ## __VA_ARGS__);
> using namespace std;
>
> void Show(const char* file, const char* fcn, int line, const char*
> display, ...)
> {
> //build display string
> va_list va;
> va_start(va, display);
> char display2[256];
> char linestr[10];
> vsprintf(display2, display, va);[/color]

Why do you think that this will work if you are putting in
more that 256 bytes into display2? It will overrun memory.
You either need to make display2 bigger than any possible input
(how can you do that?) or use vsnprintf and truncate, probably a
better bet.

-David

jois.de.vivre@gmail.com wrote:[color=blue]
> Hi,
>
> I have the following piece of code that is designed to help me add
> debug traces to my program (I wanted to use purely C++ code, but the
> only way I know how to do something like this is with macros, so please
> don't yell at me):[/color]

Perhaps you didn't notice this is comp.lang.c, not comp.lang.c++.
Anyways, look at your vspintf: vsprintf(display2, display, va);

display2 is char[256]. display is 548 (as you said in the main, i did
not count them). See anything wrong with that? You're overrunning the
buffer!
try vsnprintf.

[color=blue]
>
>
> #include <iostream>
> #include <cstdarg>
> #include <iomanip>
>
> #define MainDisplay(s, ...) Show( __FILE__, \
> __PRETTY_FUNCTION__,\
> __LINE__, \
> s, \
> ## __VA_ARGS__);
> using namespace std;
>
> void Show(const char* file, const char* fcn, int line, const char*
> display, ...)
> {
> //build display string
> va_list va;
> va_start(va, display);
> char display2[256];
> char linestr[10];
> vsprintf(display2, display, va);
> va_end(va);
> sprintf(linestr, "%d", line);
>
> string s = (file + string(" [") + linestr + string("]:"));
>
> //output to console
> cout << s;
> int ssize = s.size();
> if (ssize <= 45) cout << setw(50-ssize) << "" << display2;
> else cout << endl << setw(50) << "" << display2;
> }
>
>
> Now I want it to display a very long string message (this string has
> 548 characters in it):
>
> int main(int argc, char *argv[])
> {
>
> MainDisplay("0000000101010101010101010101010101010 10101010101010101010101010101010101010101010101010 10101010101111111111111111111111111111111111111100 01000000101100010001000001100111101000110001010011 10011010011100110100110110111111111111111111111111 11111111111111011010100110011100101100000000101010 10101010101010101010101010101010101010101010101010 10101010101010101010101010101010101111111111111111 11111111111111111111110001000000101100010001000001 10011110100011000101001110011010011100110100110110 11111111111111111111111111111111111111011010100110 01110010110");
>
> return EXIT_SUCCESS;
> }
>
>
>
> When I run this code I get a segmentation fault, and GDB spews the
> following:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x00002aaaab06f6a0 in strlen () from /lib64/tls/libc.so.6
> (gdb) backtrace
> #0 0x00002aaaab06f6a0 in strlen () from /lib64/tls/libc.so.6
> #1 0x0000000000401775 in std::char_traits<char>::length
> (__s=0x3130313031303130 <Address 0x3130313031303130 out of bounds>) at
> char_traits.h:143
> #2 0x00000000004015ea in std::operator+<char, std::char_traits<char>,
> std::allocator<char> > (__lhs=0x3130313031303130 <Address
> 0x3130313031303130 out of bounds>, __rhs=@0x7fffffffe9b0) at
> basic_string.tcc:692
> #3 0x0000000000401232 in Show (file=0x3130313031303130 <Address
> 0x3130313031303130 out of bounds>, fcn=0x3130313031303130 <Address
> 0x3130313031303130 out of bounds>, line=825241904,
> display=0x3130313031303130 <Address 0x3130313031303130 out of bounds>)
> at /home/prashant/Development/test2/src/test2.cpp:20
> #4 0x3131303131313131 in ?? ()
> #5 0x3131303031303130 in ?? ()
> #6 0x3130303131313030 in ?? ()
> #7 0x00002a0030313130 in ?? ()
> #8 0x0000000000000000 in ?? ()
> #9 0x0000000000503028 in ?? ()
> #10 0x0000000000400e1b in _init ()
> #11 0x00007fffffffed78 in ?? ()
> #12 0x0000000100401801 in ?? ()
> #13 0
> Previous frame inner to this frame (corrupt stack?)
> x00002aaaaabc0c60 in ?? () from /lib64/ld-linux-x86-64.so.2
> #14 0x00002aaaaabc0c60 in ?? () from /lib64/ld-linux-x86-64.so.2
> #15 0x00000000004017e0 in __libc_csu_fini ()
> #16 0x00002aaaab00e1d8 in ?? () from /lib64/tls/libc.so.6
> #17 0x00007fffffffed78 in ?? ()
> #18 0x00000001ffffed88 in ?? ()
> #19 0x0000000000401490 in Show () at
> /home/prashant/Development/test2/src/test2.cpp:27
> (gdb) frame 0
> #0 0x00002aaaab06f6a0 in strlen () from /lib64/tls/libc.so.6
>
>
> If I shorten the string, I find that I get no segmentation fault for
> anything less than 313 characters. My assumption is that this is a
> 'new' or malloc memory limit. ulimit -a returns the following:
>
> core file size (blocks, -c) 0
> data seg size (kbytes, -d) unlimited
> file size (blocks, -f) unlimited
> max locked memory (kbytes, -l) 32
> max memory size (kbytes, -m) unlimited
> open files (-n) 1024
> pipe size (512 bytes, -p) 8
> stack size (kbytes, -s) unlimited
> cpu time (seconds, -t) unlimited
> max user processes (-u) 8191
> virtual memory (kbytes, -v) unlimited
>
>
> I'm running on Suse Linux 9.3 (but I've been able to reproduce this
> problem on 9.0) and I'm using gcc 3.4.1.
>
> Any Ideas?
>
> Prashant[/color]

jois.de.vivre@gmail.com wrote:[color=blue]
> I have the following piece of code that is designed to help me add
> debug traces to my program (I wanted to use purely C++ code,[/color]

And why did you cross-post this to comp.lang.c?
[color=blue]
> but the
> only way I know how to do something like this is with macros, so please
> don't yell at me):
>
>
> #include <iostream>
> #include <cstdarg>
> #include <iomanip>
>
> #define MainDisplay(s, ...) Show( __FILE__, \
> __PRETTY_FUNCTION__,\
> __LINE__, \
> s, \
> ## __VA_ARGS__);[/color]

I am not sure, but it seems that you know that this is not C++...
[color=blue]
> using namespace std;
>
> void Show(const char* file, const char* fcn, int line, const char*
> display, ...)
> {
> //build display string
> va_list va;
> va_start(va, display);
> char display2[256];[/color]

So, the 'display2' is only 256 chars long...
[color=blue]
> char linestr[10];
> vsprintf(display2, display, va);[/color]

And here you're trying to print a 548 characters into a 256-byte array.
What did you expect?
[color=blue]
> va_end(va);
> sprintf(linestr, "%d", line);
>
> string s = (file + string(" [") + linestr + string("]:"));
>
> //output to console
> cout << s;
> int ssize = s.size();
> if (ssize <= 45) cout << setw(50-ssize) << "" << display2;
> else cout << endl << setw(50) << "" << display2;
> }
>
>
> Now I want it to display a very long string message (this string has
> 548 characters in it):
>
> int main(int argc, char *argv[])
> {
>
> MainDisplay("0000000101010101010101010101010101010 10101010101010101010101010101010101010101010101010 10101010101111111111111111111111111111111111111100 01000000101100010001000001100111101000110001010011 10011010011100110100110110111111111111111111111111 11111111111111011010100110011100101100000000101010 10101010101010101010101010101010101010101010101010 10101010101010101010101010101010101111111111111111 11111111111111111111110001000000101100010001000001 10011110100011000101001110011010011100110100110110 11111111111111111111111111111111111111011010100110 01110010110");
>
> return EXIT_SUCCESS;
> }
>
>
>
> When I run this code I get a segmentation fault, and GDB spews the
> following:
>
> [...][/color]

V

My goodness, I can't believe I didn't notice that. Thank you!!

jois.de.vivre@gmail.com wrote:[color=blue]
> Hi,
>
> I have the following piece of code that is designed to help me add
> debug traces to my program (I wanted to use purely C++ code,[/color]

This makes no sense. No rational person posts to comp.lang.c if he has
a C++-related question.
[color=blue]
> but the
> only way I know how to do something like this is with macros, so please
> don't yell at me):
>
>
> #include <iostream>
> #include <cstdarg>
> #include <iomanip>[/color]

This stuff, which is not C, is reason enough for comp.lang.c people to
yell at you.
[color=blue]
> #define MainDisplay(s, ...) Show( __FILE__, \
> __PRETTY_FUNCTION__,\[/color]

And this, which is implementation-specific, should get the comp.lang.c++
people on you.

It seems that you are writing g++-specific code. You need to post such
questions to a gnu.* newsgroup.

If you don't have anything useful to say in reference to my original
question (which you don't), don't bother replying. I already said
that this is the only way I know how to do something like this and it's
enough for you to read it and move on if you can't figure out the
solution. Obviously the problem was simple enough that people in
comp.lang.c could help me solve it, so why do you bother wasting your
time writing such condescending responses.

* jois.de.vivre@gmail.com -> Martin Ambuhl:[color=blue]
> If you don't have anything useful to say in reference to my original
> question (which you don't), don't bother replying. I already said
> that this is the only way I know how to do something like this and it's
> enough for you to read it and move on if you can't figure out the
> solution. Obviously the problem was simple enough that people in
> comp.lang.c could help me solve it, so why do you bother wasting your
> time writing such condescending responses.[/color]

Idiot.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

jois.de.vivre@gmail.com wrote:[color=blue]
>
> If you don't have anything useful to say in reference to my original
> question (which you don't), don't bother replying. I already said
> that this is the only way I know how to do something like this and
> it's enough for you to read it and move on if you can't figure out
> the solution. Obviously the problem was simple enough that people
> in comp.lang.c could help me solve it, so why do you bother wasting
> your time writing such condescending responses.[/color]

They and you are both wrong, in that C++ answers should not be
given in c.l.c, because they will not be properly examined and they
will encourage further off-topic postings. You do not seem to have
managed to figure out how to use google groups, and I am tired of
instructing idiots how to so do. You will go far, but probably at
the end of a boot.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

In message <1122331669.132729.73670@g43g2000cwa.googlegroups. com>,
jois.de.vivre@gmail.com writes[color=blue]
>If you don't have anything useful to say in reference to my original
>question (which you don't), don't bother replying.[/color]

If you must post via Google, please learn how to make it quote some
context.

--
Richard Herring

[color=blue]
> They and you are both wrong, in that C++ answers should not be
> given in c.l.c, because they will not be properly examined and they
> will encourage further off-topic postings. You do not seem to have
> managed to figure out how to use google groups, and I am tired of
> instructing idiots how to so do. You will go far, but probably at
> the end of a boot.[/color]

It seems to me my question was properly examined, and was properly
answered. Nobody is asking you to instruct anybody on how to use
google groups, so if you're tired of instructing idiots, then stop
instructing. Simple. It takes all but two seconds to read a post and
realize that it's "off topic". In fact I explicitly stated in my
opening that I was using C++ but that I needed help with part of my C
code, which should have given you a clue. So stop crying.

jois.de.vivre@gmail.com wrote:[color=blue]
> If you don't have anything useful to say in reference to my original
> question (which you don't), don't bother replying. I already said
> that this is the only way I know how to do something like this and it's
> enough for you to read it and move on if you can't figure out the
> solution. Obviously the problem was simple enough that people in
> comp.lang.c could help me solve it, so why do you bother wasting your
> time writing such condescending responses.
>[/color]

I'm so glad books exist. I pretty much learnt about C through them and
didn't have to beg/fight & made to feel generally inferior, just to get
an answer.

I always google and 99.99% of the time find the answer, if i don't find
the answer, i assume i'm asking the wrong question.