Strange seg fault

C

ciccio

Hi,

Recently some people I know stumbled upon a strange problem with the
following piece of code. This is reduced as far as possible.

The idea of the code is simple. There are four structs of which one
contains the other three structs. If we allocate a large double array
of that struct and try to initialize it to zero, or try to use one of
them in a function. The program gives a seg fault. If we make the array
slightly smaller, there is no problem. The problem only appears on
x86_64 architectures.

Below I past a copy of the failing code. If DATAMAX is set to 4820 the
program works, if it is set to 4830 it seg faults.

What could the reason be of this? We have calculated the amount of
memory and we have for sure no problem with that. A backtrace also does
not give any deeper insight.

Thanks for the help



#define DATAMAX 4830
#define ISOMAX 7

typedef struct
{
short iso;
char observable[15];
short ds_dt;
short ds_du;
double emin;
double emax;
double cos;
double ampli;
double error;
short tch;
} Photo;

typedef struct
{
short iso;
char observable[15];
short ds_dt;
double qsquared;
double s;
short cos_ang;
double t;
double cos;
double ampli;
double error;
short tch;
short beam_ener_input;
double e_beam_ener;
double eps;
short cs_convention;
} Electro;


typedef struct
{
short iso;
char observable[10];
double pk;
double cos;
double ampli;
double ratio;
double error;
} Kaoncap;

typedef struct
{
short iso;
short photo_prod;
short electro_prod;
short kaoncapture;
Photo photo;
Electro elec;
Kaoncap kaoncap;
} Data;

int test(Data blub) {
return 0;
}

int main(int argc, char* argv)
{
// WORKS ALWAYS
Data datapoints[ISOMAX][DATAMAX];

// FAILS WITH DATAMAX = 4830 or larger
// Data datapoints[ISOMAX][DATAMAX] = {{{0}}};

// FAILS WITH DATAMAX = 4830 or lager
// Data datapoints[ISOMAX][DATAMAX];
// test(datapoints[0][0]);

return 0;
}
 
A

Alf P. Steinbach

* ciccio:
Hi,

Recently some people I know stumbled upon a strange problem with the
following piece of code. This is reduced as far as possible.

The idea of the code is simple. There are four structs of which one
contains the other three structs. If we allocate a large double array
of that struct and try to initialize it to zero, or try to use one of
them in a function. The program gives a seg fault. If we make the array
slightly smaller, there is no problem. The problem only appears on
x86_64 architectures.

Below I past a copy of the failing code. If DATAMAX is set to 4820 the
program works, if it is set to 4830 it seg faults.

What could the reason be of this? We have calculated the amount of
memory and we have for sure no problem with that.

Are you sure?

Check

sizeof( Data[ISOMAX][DATAMAX] );

No need to calculate when you can check directly.

You're talking automatic local memory here, a.k.a. "stack". It may be
implemented in ways that give you very little elbow room. E.g. onboard
cache, registers.

Try dynamic allocation, which is easily achieved by using std::vector or
e.g. some library matrix class.


A backtrace also does not give any deeper insight.

#define DATAMAX 4830
#define ISOMAX 7

In C++ it's a good idea to simply use typed constants, in order to avoid
macros,

size_t const maxData = 4830;


typedef struct
{
short iso;
char observable[15];
short ds_dt;
short ds_du;
double emin;
double emax;
double cos;
double ampli;
double error;
short tch;
} Photo;

In C++ this is better expressed as

struct Photo
{
// ...
};


[snip]
int main(int argc, char* argv)
{
// WORKS ALWAYS
Data datapoints[ISOMAX][DATAMAX];

Maybe it's optimized away.

// FAILS WITH DATAMAX = 4830 or larger
// Data datapoints[ISOMAX][DATAMAX] = {{{0}}};

// FAILS WITH DATAMAX = 4830 or lager
// Data datapoints[ISOMAX][DATAMAX];
// test(datapoints[0][0]);

return 0;
}


Cheers, & hth.,

- Alf
 
P

Puppet_Sock

int main(int argc, char* argv)
{
  // WORKS ALWAYS
  Data datapoints[ISOMAX][DATAMAX];

  // FAILS WITH DATAMAX = 4830 or larger
  // Data datapoints[ISOMAX][DATAMAX] = {{{0}}};

  // FAILS WITH DATAMAX = 4830 or lager
  // Data datapoints[ISOMAX][DATAMAX];
  // test(datapoints[0][0]);

<JohnCleeseVoice>How much stack?</voice>

How big is your stack? What does your app do, or what
options does your development platform set, when that
happens?

If I did the math right, with DATAMAX of 4830 you've
got something in the range of 8MB. Default stack size
is usually not that large on most compilers.

Try allocating it through new rather than as an auto var.
Socks
 
J

James Kanze

[snip]
int main(int argc, char* argv)
{
// WORKS ALWAYS
Data datapoints[ISOMAX][DATAMAX];
// FAILS WITH DATAMAX = 4830 or larger
// Data datapoints[ISOMAX][DATAMAX] = {{{0}}};
// FAILS WITH DATAMAX = 4830 or lager
// Data datapoints[ISOMAX][DATAMAX];
// test(datapoints[0][0]);
<JohnCleeseVoice>How much stack?</voice>
How big is your stack? What does your app do, or what
options does your development platform set, when that
happens?
If I did the math right, with DATAMAX of 4830 you've
got something in the range of 8MB. Default stack size
is usually not that large on most compilers.

The maximum stack size can often be set by a command at runtime.
On my system, it's 8MB by default, but I can always do "ulimit
-s unlimited", and use all of the available memory.

Not that that's necessarily a good idea. The reason why the
stack size is limited is so that an endless recursion will crash
in a reasonable time, rather than running for days eating up
machine resources. In this case, he should simple use an
std::vector, and be done with it.
Try allocating it through new rather than as an auto var.

Yes, but not manually, please.
 
C

ciccio

Hi all,

Thanks for the info, this was indeed the case. I forgot about the stack.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Why does this cause a seg fault? 1
seg fault 11
strange seg fault on stack 8
possible seg fault 11
seg fault 76
Eliminating this seg fault 5
Seg Fault Help 14
Simple gtk+ app, seg fault 1

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,065
Latest member
OrderGreenAcreCBD

Latest Threads

Top