LinuxQuestions.org
Share your knowledge at the LQ Wiki.
Go Back   LinuxQuestions.org > Forums > Non-*NIX Forums > Programming
User Name
Password
Programming This forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.

Notices

Reply
 
Search this Thread
Old 09-24-2008, 05:10 PM   #1
Sparcler
LQ Newbie
 
Registered: Sep 2006
Location: Logan, UT
Distribution: Slackware
Posts: 9

Rep: Reputation: 0
Segmentation fault


Hello, I find myself faced with an interesting problem, and I don't know where to turn. I'm not sure whether it is a compiler problem or a kernel problem. I'm trying to write a program in c++ using g++. the code compiles just fine but when I try to run it it I get a segmentation fault. It is a simple program, it declares a 3 dimensional array of type int and then fills the array. As far as I can tell there isn't any problems with the code, but I have included it along with my makefile.
makefile
CC=g++
CFLAGS=-Wall
math: math.o
$(CC) $(CFLAGS) -o math math.o
math.o: math.cpp
$(CC) $(CFLAGS) -c math.cpp
clean:
rm ./*.o
rm ./math
math.cpp
#include<iostream>

using namespace std;

int main(int argc, char *argv[]){
int test=0;
const int xSize=1024, ySize=768, depth=3;
int graphic[ySize][xSize][depth];

for(int i=0;i<ySize;i++){
for(int j=0;j<xSize;j++){
graphic[i][j][0]=i;
graphic[i][j][1]=j;
graphic[i][j][2]=i+j;
}
}

return test;
}
I think the problem is with the array size, if I declare it as 800x600x3 there is no problem, but when I go to 1024x768x3 or larger it will seg fault every time. Here is the question dose the Linux kernel impose a limitation on application memory usage, or is there a compiler flag that I need to use to allow the larger memory allocation, or do I have a bug in my code?
 
Old 09-24-2008, 05:25 PM   #2
mjmwired
Member
 
Registered: Apr 2004
Distribution: CentOS6, CentOS5, F16, F15, Ubuntu, OpenSuse
Posts: 620

Rep: Reputation: 39
Curious, what does the debugger output say?
Compile with '-g' flag and use 'gdb':
# gdb math
 
Old 09-24-2008, 05:52 PM   #3
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Also, you seem to have "xSize" and "ySize" reversed - either in your loop, or in your declaration - the two don't match each other.

PS:
It's not a compiler problem, nor a kernel problem. I think this is an example of "PEBKAM"...

Last edited by paulsm4; 09-24-2008 at 05:56 PM.
 
Old 09-24-2008, 05:58 PM   #4
fantas
Member
 
Registered: Jun 2007
Location: Bavaria
Distribution: slackware, xubuntu
Posts: 143

Rep: Reputation: 22
My guess is that it's a limit of how much memory you can allocate on the stack, but I have no figues here. I would try to allocate the array on the heap instead.
 
Old 09-24-2008, 06:12 PM   #5
Sparcler
LQ Newbie
 
Registered: Sep 2006
Location: Logan, UT
Distribution: Slackware
Posts: 9

Original Poster
Rep: Reputation: 0
After more testing I think the problem is with the kernel. It appears that the kernel limits the amount of memory that a process can use. So my question now becomes what is the limit and is there a way around it?
 
Old 09-24-2008, 06:35 PM   #6
David1357
Senior Member
 
Registered: Aug 2007
Location: South Carolina, U.S.A.
Distribution: Ubuntu, Fedora Core, Red Hat, SUSE, Gentoo, DSL, coLinux, uClinux
Posts: 1,302
Blog Entries: 1

Rep: Reputation: 107Reputation: 107
Quote:
Originally Posted by Sparcler View Post
I think the problem is with the array size, if I declare it as 800x600x3 there is no problem, but when I go to 1024x768x3 or larger it will seg fault every time. Here is the question dose the Linux kernel impose a limitation on application memory usage, or is there a compiler flag that I need to use to allow the larger memory allocation, or do I have a bug in my code?
Code:
 800 x 600 x 3 x sizeof(int) =   576,000 bytes = 562 K
1024 x 768 x 3 x sizeof(int) = 9,437,184 bytes =   9 M
What does "ulimit -d" say?
 
Old 09-24-2008, 09:36 PM   #7
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Hi -

When you said "operating system" and "compiler", I thought you were implying some Linux bug or GCC bug might be the culprit. That's definitely not the case here ;-)

You're absolutely correct about the stack overflow issue. It dies on Windows (Visual C++) too. As David1357 pointed out, you need 9,437,184 bytes of stack, but Windows processes have a default stack limit of 1MB (Linux processes about 8MB).

In Windows, you can change the limit by compiling with /STACKSIZE 1048576 (for 10MB). This alters the .exe, instructing the OS to reserve 10MB stack for the process.

In Linux, you should be able to change this with "ulimit -s".

You can also circumvent the problem (on both Linux and Windows) by:
1) static allocation (use "static", or declare the array outside of a function)
2) heap allocation (use C "malloc()" or C++ "new")

Here are a couple of links:
http://cs.nyu.edu/exact/core/doc/stackOverflow.txt
http://bytes.com/forum/thread221976.html
 
Old 09-24-2008, 09:59 PM   #8
Sparcler
LQ Newbie
 
Registered: Sep 2006
Location: Logan, UT
Distribution: Slackware
Posts: 9

Original Poster
Rep: Reputation: 0
Thanks for the ideas, I decided to change things, The arrays get to big too fast.
 
Old 09-25-2008, 12:39 AM   #9
ErV
Senior Member
 
Registered: Mar 2007
Location: Russia
Distribution: Slackware 12.2
Posts: 1,202
Blog Entries: 3

Rep: Reputation: 62
Quote:
Originally Posted by fantas View Post
My guess is that it's a limit of how much memory you can allocate on the stack, but I have no figues here. I would try to allocate the array on the heap instead.
IT was said in OpenDynamic Engine documentation that Linux/Unix are one of few several OSes that can increase stack size dynamically. This is information might be incorrect, but ODe uses (or used) alloca (allocates memory on stack) a lot, and still works.


Quote:
Originally Posted by Sparcler View Post
It appears that the kernel limits the amount of memory that a process can use.
I don't think so. 1024x768x3 is small amount of memory (although it might depend on how you allocate it). You should debug your program with gdb instead of making any assumptions.
 
Old 09-25-2008, 08:12 AM   #10
johnsfine
Guru
 
Registered: Dec 2007
Distribution: Centos
Posts: 5,084

Rep: Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110Reputation: 1110
Quote:
Originally Posted by David1357 View Post
Code:
 800 x 600 x 3 x sizeof(int) =   576,000 bytes = 562 K
1024 x 768 x 3 x sizeof(int) = 9,437,184 bytes =   9 M
There's a significant little typo in the above.
Code:
 800 x 600 x 3 x sizeof(int) = 5,760,000 bytes = 5625 K
1024 x 768 x 3 x sizeof(int) = 9,437,184 bytes = 9216 K = 9 M
But for figuring out whether the array would fit on an 8MB stack, the typo didn't matter.
 
Old 09-25-2008, 09:33 AM   #11
fantas
Member
 
Registered: Jun 2007
Location: Bavaria
Distribution: slackware, xubuntu
Posts: 143

Rep: Reputation: 22
Quote:
Originally Posted by ErV View Post
IT was said in OpenDynamic Engine documentation that Linux/Unix are one of few several OSes that can increase stack size dynamically. This is information might be incorrect, but ODe uses (or used) alloca (allocates memory on stack) a lot, and still works.
This could also just mean that they wanted to point out that you can also call setrlimit from a running process, which AFAIK is not possible under Windows for example. And not that it's somehow automatically done by the system when reaching the current limit for the particular process (as how I understood your interpretation).
 
Old 09-25-2008, 11:07 AM   #12
David1357
Senior Member
 
Registered: Aug 2007
Location: South Carolina, U.S.A.
Distribution: Ubuntu, Fedora Core, Red Hat, SUSE, Gentoo, DSL, coLinux, uClinux
Posts: 1,302
Blog Entries: 1

Rep: Reputation: 107Reputation: 107
Quote:
Originally Posted by johnsfine View Post
There's a significant little typo in the above.
Argh. This HP 50g (which cost way too much) does not give the proper key feedback. I must have entered "80 600 3 4" or "800 60 3 4". May God bless the person who stole my 48SX.
 
Old 09-25-2008, 11:29 AM   #13
ErV
Senior Member
 
Registered: Mar 2007
Location: Russia
Distribution: Slackware 12.2
Posts: 1,202
Blog Entries: 3

Rep: Reputation: 62
Quote:
Originally Posted by fantas View Post
This could also just mean that they wanted to point out that you can also call setrlimit from a running process, which AFAIK is not possible under Windows for example. And not that it's somehow automatically done by the system when reaching the current limit for the particular process (as how I understood your interpretation).
Explanation.
Complex ODE simulation requires huge stack segment. Up to 70 megabytes, or more. Or it was that way in in ODE 0.35 or something. This is because within many functions they allocate huge arrays, tables (matrices, etc) with "alloca". On windows such application quickly dies with "stack overflow", unless stack size was specified during compilation. On linux it works (or they say so). This was explained in ODE documentation or FAQ somewhere (they said that Linux/Unix OS enlarges stack when necessary), but I was working with all that several years ago, so I don't remember where exactly was that, and situation may have changed. I cannot say anything setrlimit, because I'm unfamiliar with it - I always try to use cross-platform API instead of OS-specific function calls. See ode-related documentation for more details, if you are interested.
 
Old 09-25-2008, 12:25 PM   #14
paulsm4
Guru
 
Registered: Mar 2004
Distribution: SusE 8.2
Posts: 5,863
Blog Entries: 1

Rep: Reputation: Disabled
Erv -
read this:
 
Old 09-26-2008, 03:47 AM   #15
fantas
Member
 
Registered: Jun 2007
Location: Bavaria
Distribution: slackware, xubuntu
Posts: 143

Rep: Reputation: 22
Quote:
Originally Posted by ErV View Post
Explanation.
Complex ODE simulation requires huge stack segment. Up to 70 megabytes, or more. Or it was that way in in ODE 0.35 or something. This is because within many functions they allocate huge arrays, tables (matrices, etc) with "alloca". On windows such application quickly dies with "stack overflow", unless stack size was specified during compilation. On linux it works (or they say so). This was explained in ODE documentation or FAQ somewhere (they said that Linux/Unix OS enlarges stack when necessary), but I was working with all that several years ago, so I don't remember where exactly was that, and situation may have changed. I cannot say anything setrlimit, because I'm unfamiliar with it - I always try to use cross-platform API instead of OS-specific function calls. See ode-related documentation for more details, if you are interested.
Thanks ErV. I've been reading through the FAQ and it is there indeed, but does seem to be simple misinformation. Not in a meant-in-a-bad-way, but rather in a we-have-no-other-explanation kind of way. The real reason behind it is probably simply that the default stack sizes are different between WIN32 and Unix (1MB versus 8MB), and this can make a world of a difference when allocating huge data sets.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
segmentation fault meghakolombkar Programming 0 05-04-2006 12:20 AM
What is a segmentation fault? 144419855310001 Fedora 1 04-28-2006 07:39 AM
segmentation fault! sharath patil Debian 5 04-22-2006 04:57 AM
Segmentation fault cmplet-noobie Programming 3 04-03-2006 02:52 AM
yast segmentation fault, system freezing - nvidia driver at fault? BaltikaTroika Suse/Novell 2 12-02-2005 09:34 AM


All times are GMT -5. The time now is 05:18 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration