segfault on memory intensive programs

[Pete]

--- Dave Korn <dave.korn@artimi.com> wrote:

> On 30 March 2006 14:34, Pete wrote:
> 
> > The executable is produced with:
> > 
> > $ make
> > g++ -W -Wall -O9 -funroll-loops -mtune=pentium4  
> -c
> > -o matrix_mult_r.o matrix_mult_r.cc
> 
>   Heh.
> 
> 
> matrix_mult_r.cc:5:19: Timer.h: No such file or
> directory
> matrix_mult_r.cc: In function `int main()':
> matrix_mult_r.cc:20: error: `Timer' undeclared
> (first use this function)
> matrix_mult_r.cc:20: error: (Each undeclared
> identifier is reported only once
> for each function it appears in.)
> matrix_mult_r.cc:20: error: expected `;' before
> "timer"
> matrix_mult_r.cc:21: error: `timer' undeclared
> (first use this function)

ok... ok... :)

Attaching the files to the email.  Hope attachments
are OK.

> However, it's straightforward enough.  The default
> thread stack is 1Mb (or
> is it 2, I can't remember off the top of my head). 
> Once your stack-based auto
> vars exceed the size of the stack, it go BOOOOOM!

But doesn't the implementation keep track of stack
allocations?  Why let the hardware report a SIGSEGV
rather than let libc report "Out of memory" and
killing the process?

>   Your problem can be fixed /either/ by making them
> of static storage duration
> (move them out of the function body OR add the
> 'static' qualifier depending on
> scoping considerations),

Trying to learn...   Is that because if I declare the
variables as static (or make them global), they're
placed in the "data segment" and the compiler
automatically allocates enough space for them?

> or by using the -Wl,--stack
> flag.  Correctly.  You
> told ld to provide an 8kB stack.  Try 80 meg
> instead, it works a lot beter!

Yes, that definitely did the trick.  Thanks!  I think
the FAQ should be expanded a bit on the subject (I'd
be willing to write and submit if there's noone
designated as FAQ maintainer).

One last issue.  I was replying to one of your earlier
emails about using GDB.  For some reason, no matter
what I do, GDB always segfaults when I run the program
under GDB.

For a nice small eigensystem (N=200, ITERATIONS=2000):

$ make
g++ -W -Wall -O9 -funroll-loops -mtune=pentium4 -g  
-c -o matrix_mult_r.o matrix_mult_r.cc
g++ -W -Wall -O9 -funroll-loops -mtune=pentium4 -g  
-c -o Timer.o Timer.cc
g++ -Wl,--heap,8192,--stack,83886080 -o
matrix_mult_r.exe *.o
$ gdb matrix_mult_r.exe

(gdb) break 1
Breakpoint 1 at 0x401220: file matrix_mult_r.cc, line
1.
(gdb) run

Breakpoint 1, main () at matrix_mult_r.cc:16
16      {
(gdb) n
0x004101f0 in _alloca ()
(gdb) n
Single stepping until exit from function _alloca,
which has no line number information.
0x004101f6 in probe ()
(gdb) n
Single stepping until exit from function probe,
which has no line number information.
0x0041020d in done ()
(gdb) n
Single stepping until exit from function done,
which has no line number information.
main () at matrix_mult_r.cc:16
16      {
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x610ae938 in pthread_key_create () from
/usr/bin/cygwin1.dll


I use GDB quite a bit, and would _really_ like to be
able to use in on Cygwin.  The problem isn't even with
my benchmarking code.  Even with a hello world
program:

#include <iostream>
using namespace std;

int main( void )
{
   cout << "hello world" << endl;

   return 0;
}

when compiled with:

$ g++ -g  foo.cc

produces a segfault under GDB:

$ gdb -quiet a.exe
(gdb) break 1
Breakpoint 1 at 0x401150: file foo.cc, line 1.
(gdb) run

Breakpoint 1, main () at foo.cc:6
6       {
(gdb) n
0x0040f400 in _alloca () at
/usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/iostream:77
77        static ios_base::Init __ioinit;
(gdb) n
main () at foo.cc:6
6       {
(gdb) n

Program received signal SIGSEGV, Segmentation fault.
0x610ae938 in pthread_key_create () from
/usr/bin/cygwin1.dll

Also, I noticed from my benchmark code that GDB
reports that it's in libc (or whatever!) functions
like alloca().  Is there a way to surpress mention of
any stepping into functions that don't have debugging
information?

Thanks again,
Pete

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Makefile
Type: application/octet-stream
Size: 418 bytes
Desc: 402397780-Makefile
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060330/237748ce/attachment.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: matrix_mult_r.cc
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060330/237748ce/attachment.cc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Timer.cc
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060330/237748ce/attachment-0001.cc>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: Timer.h
URL: <http://cygwin.com/pipermail/cygwin/attachments/20060330/237748ce/attachment.h>
-------------- next part --------------
--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/