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



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

* 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


--
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?

On Feb 6, 1:17pm, ciccio <no_valid_em...@spam.com> wrote:
[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.

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

On Feb 6, 7:57 pm, Puppet_Sock <puppet_s...@hotmail.com> wrote:
> On Feb 6, 1:17 pm, ciccio <no_valid_em...@spam.com> wrote:
> [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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

Hi all,

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