strange seg fault on stack

[gypsy3001]

I inherited some code and got a segmentation fault on the following
line:

unsigned short localImage[panelRows * panelCols];

It's really baffling and I can't think of what could cause this
problem. The following are debug code I inserted:

cerr << "unsigned short size: " << sizeof (unsigned short) << endl;
cerr << "panelRows: " << panelRows << endl;
cerr << "panelCols: " << panelCols << endl;
cerr << "product: " << panelRows * panelCols << endl;
unsigned short localImage[panelRows * panelCols]; // what's the
problem?
cerr << "sizeof: " << sizeof (localImage) << endl;

DEBUG OUTPUT:

unsigned short size: 2
panelRows: 1024
panelCols: 1024
product: 1048576
Segmentation fault

STACK LIMIT DEBUG CODE:

struct rlimit limit;
getrlimit (RLIMIT_STACK, &limit);
cerr << "Soft Limit: " << limit.rlim_cur << endl;
cerr << "Hard Limit: " << limit.rlim_max << endl;

STACK LIMIT OUTPUT:

Soft Limit: 4294967295
Hard Limit: 4294967295

Anyone see anything obvious that my mind just can't focus on???

Chieh
--
Camera Hacker - http://www.CameraHacker.com/

[Victor Bazarov]

gy*******@yahoo.com wrote:

I inherited some code and got a segmentation fault on the following
line:

unsigned short localImage[panelRows * panelCols];

It's really baffling and I can't think of what could cause this
problem. The following are debug code I inserted:

cerr << "unsigned short size: " << sizeof (unsigned short) << endl;
cerr << "panelRows: " << panelRows << endl;
cerr << "panelCols: " << panelCols << endl;
cerr << "product: " << panelRows * panelCols << endl;
unsigned short localImage[panelRows * panelCols]; // what's the
problem?
cerr << "sizeof: " << sizeof (localImage) << endl;

This is non-standard code. The Stadnard language does not have arrays
with run-time sizes. You need to allocate it dynamically to make it
Standard-compliant, something like

unsigned short *localImage = new unsigned short[...

DEBUG OUTPUT:

unsigned short size: 2
panelRows: 1024
panelCols: 1024
product: 1048576
Segmentation fault

STACK LIMIT DEBUG CODE:

struct rlimit limit;
getrlimit (RLIMIT_STACK, &limit);
cerr << "Soft Limit: " << limit.rlim_cur << endl;
cerr << "Hard Limit: " << limit.rlim_max << endl;

STACK LIMIT OUTPUT:

Soft Limit: 4294967295
Hard Limit: 4294967295

Anyone see anything obvious that my mind just can't focus on???

The only obvious thing is that you're not writing C++ as we know it.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[mlimber]

gy*******@yahoo.com wrote:

I inherited some code and got a segmentation fault on the following
line:

unsigned short localImage[panelRows * panelCols];

It's really baffling and I can't think of what could cause this
problem. The following are debug code I inserted:

cerr << "unsigned short size: " << sizeof (unsigned short) << endl;
cerr << "panelRows: " << panelRows << endl;
cerr << "panelCols: " << panelCols << endl;
cerr << "product: " << panelRows * panelCols << endl;
unsigned short localImage[panelRows * panelCols]; // what's the
problem?
cerr << "sizeof: " << sizeof (localImage) << endl;

DEBUG OUTPUT:

unsigned short size: 2
panelRows: 1024
panelCols: 1024
product: 1048576
Segmentation fault

STACK LIMIT DEBUG CODE:

struct rlimit limit;
getrlimit (RLIMIT_STACK, &limit);
cerr << "Soft Limit: " << limit.rlim_cur << endl;
cerr << "Hard Limit: " << limit.rlim_max << endl;

STACK LIMIT OUTPUT:

Soft Limit: 4294967295
Hard Limit: 4294967295

Anyone see anything obvious that my mind just can't focus on???

Despite what your OS-specific function getrlimit() is telling you, you
may not be able to allocate that much space on the stack. Try
allocating it dynamically (preferably with a container; cf.
http://www.parashift.com/c++-faq-lit...html#faq-34.1). Or,
try posting on a group related to your platform (cf. the list at
http://www.parashift.com/c++-faq-lit....html#faq-5.9).

Cheers! --M

[gypsy3001]

Despite what your OS-specific function getrlimit() is telling you, you

may not be able to allocate that much space on the stack. Try

Sorry, I forgot to mention that this software is compiled on Linux
using GNU G++ compiler 3.4.3 on Intel x86. If it's any help.

allocating it dynamically (preferably with a container; cf.
http://www.parashift.com/c++-faq-lit...html#faq-34.1). Or,
try posting on a group related to your platform (cf. the list at
http://www.parashift.com/c++-faq-lit....html#faq-5.9).

Thanks, I appreciate it. I understand the good programming philosophy
and have always followed it. However, like I said, I inherited the code
from someone that is no longer around. My task is to make
what-used-to-work work. Or make an assessment on what it would take to
make it work. I appreciate the suggestions. Willing to hear others.
Thanks.

Chieh
--
Camera Hacker - http://www.CameraHacker.com/

[gypsy3001]

Victor Bazarov wrote:

gy*******@yahoo.com wrote:

unsigned short localImage[panelRows * panelCols];

This is non-standard code. The Stadnard language does not have arrays
with run-time sizes. You need to allocate it dynamically to make it
Standard-compliant, something like

unsigned short *localImage = new unsigned short[...

Anyone see anything obvious that my mind just can't focus on???

The only obvious thing is that you're not writing C++ as we know it.

Thanks. Is that a true statement with the standard that GNU G++ 3.4.3
is based on?
We have thought about using the heap as one solution, though it is the
last solution at this time. At this point, we can not make the
determination that the dynamic static allocation is the root of the
cause, because it works find with a smaller number, such as 512000 and
even 1000000.

Is it a bug that GNU G++ allows dynamic static allocation to go through
compilation? Or is it simply not explicitly verified as part of the
standard? Perhaps another way to word the question, is this an
ambiguity in the C++ standard?

Chieh
--
Camera Hacker - http://www.CameraHacker.com/

[Thomas J. Gritzan]

gy*******@yahoo.com schrieb:

Victor Bazarov wrote:

>The only obvious thing is that you're not writing C++ as we know it.

Thanks. Is that a true statement with the standard that GNU G++ 3.4.3
is based on?
We have thought about using the heap as one solution, though it is the
last solution at this time. At this point, we can not make the
determination that the dynamic static allocation is the root of the
cause, because it works find with a smaller number, such as 512000 and
even 1000000.

What is 'dynamic static allocation'? Is it an oxymoron?

Well, arrays have to be compile-time constant sized in C++.
In C, since C99, there are variable length arrays (VLA), and gcc also
supports this as an extension to C++.

So you have to use std::vector, new[] and friends for this.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[gypsy3001]

Thomas J. Gritzan wrote:

What is 'dynamic static allocation'? Is it an oxymoron?

It's my re-word of Victor's "arrays with run-time sizes" phrase, or
what you call "variable length array" declaration.

Well, arrays have to be compile-time constant sized in C++.
In C, since C99, there are variable length arrays (VLA), and gcc also
supports this as an extension to C++.
So you have to use std::vector, new[] and friends for this.

It looks like I confused you all by introducing variable in array size
declaration.
Let me put the problem in new lights. We've found that using the
following constant numbers, we get different results:

unsigned short localImage [524288]; // does not crash
unsigned short localImage [1048576]; // seg faults

Yes. The number are actually numeric constants as what you see above.
Anyone experienced this interesting phenomenon before?

Chieh
--
Camera Hacker - http://www.CameraHacker.com/

[Thomas J. Gritzan]

gy*******@yahoo.com wrote:

It looks like I confused you all by introducing variable in array size
declaration.
Let me put the problem in new lights. We've found that using the
following constant numbers, we get different results:

unsigned short localImage [524288]; // does not crash
unsigned short localImage [1048576]; // seg faults

Yes. The number are actually numeric constants as what you see above.
Anyone experienced this interesting phenomenon before?

As mlimber wrote, you might not be able to allocate all the stack memory
that a platform specific function (getrlimit) might report to you.

Since 2 MB is definitly much space for automatic storage, you have two options:

1) Use heap.
2) Ask in a newsgroup about your platform. Perhaps there you'll get a
better answer, what the return value of getrlimit really says, and how to
increase stack size.

--
Thomas
http://www.netmeister.org/news/learn2quote.html

[Jim Langston]

<gy*******@yahoo.comwrote in message
news:11**********************@m73g2000cwd.googlegr oups.com...

>Despite what your OS-specific function getrlimit() is telling you, you
may not be able to allocate that much space on the stack. Try

Sorry, I forgot to mention that this software is compiled on Linux
using GNU G++ compiler 3.4.3 on Intel x86. If it's any help.

>allocating it dynamically (preferably with a container; cf.
http://www.parashift.com/c++-faq-lit...html#faq-34.1). Or,
try posting on a group related to your platform (cf. the list at
http://www.parashift.com/c++-faq-lit....html#faq-5.9).

Thanks, I appreciate it. I understand the good programming philosophy
and have always followed it. However, like I said, I inherited the code
from someone that is no longer around. My task is to make
what-used-to-work work. Or make an assessment on what it would take to
make it work. I appreciate the suggestions. Willing to hear others.
Thanks.

Chieh
--
Camera Hacker - http://www.CameraHacker.com/

Your stack just isn't that big. Your call is returning 4294967295 as stack
size, and that's just the largest unsigned 4 byte int. Think about it, do
you *really* think that your stack is 4gb? Heck, my machine would only go
up to 2gb max (I'm currently running 1gb).

Since the stack is not that big, you have two options. 1. Use a smaller
size. 2. Use free store.

Since you're modifying the code, it seems fairly obvious that you can't use
a smaller size, so you'll need to use new[] and delete[].