By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
454,925 Members | 1,129 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 454,925 IT Pros & Developers. It's quick & easy.

Memory allocation problem!

P: n/a
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

Jul 23 '05 #1
Share this Question
Share on Google+
12 Replies


P: n/a


jo***********@gmail.com wrote:
#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);

writing to a 256-byte buffer.

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");


sending 548 bytes into a 256 byte buffer

return EXIT_SUCCESS;
}

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

Any Ideas?

you are overflowing your buffer.

-shez-

Jul 23 '05 #2

P: n/a
jois.de.vi...@gmail.com wrote:
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):
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.


#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);


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

Jul 23 '05 #3

P: n/a
jo***********@gmail.com wrote:
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):
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.



#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


Jul 23 '05 #4

P: n/a
jo***********@gmail.com wrote:
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,
And why did you cross-post this to comp.lang.c?
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__);
I am not sure, but it seems that you know that this is not C++...
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];
So, the 'display2' is only 256 chars long...
char linestr[10];
vsprintf(display2, display, va);
And here you're trying to print a 548 characters into a 256-byte array.
What did you expect?
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:

[...]


V
Jul 23 '05 #5

P: n/a
My goodness, I can't believe I didn't notice that. Thank you!!

Jul 23 '05 #6

P: n/a
jo***********@gmail.com wrote:
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,
This makes no sense. No rational person posts to comp.lang.c if he has
a C++-related question.
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>
This stuff, which is not C, is reason enough for comp.lang.c people to
yell at you.
#define MainDisplay(s, ...) Show( __FILE__, \
__PRETTY_FUNCTION__,\


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.
Jul 23 '05 #7

P: n/a
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.

Jul 25 '05 #8

P: n/a
* jo***********@gmail.com -> Martin Ambuhl:
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.


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?
Jul 25 '05 #9

P: n/a
jo***********@gmail.com wrote:

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.


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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Jul 26 '05 #10

P: n/a
In message <11*********************@g43g2000cwa.googlegroups. com>,
jo***********@gmail.com writes
If you don't have anything useful to say in reference to my original
question (which you don't), don't bother replying.


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

--
Richard Herring
Jul 26 '05 #11

P: n/a
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.


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.

Jul 26 '05 #12

P: n/a
jo***********@gmail.com wrote:
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.


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.
Aug 20 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.