-1

on the last test of an exercise it says "caught fatal signal 11"....my first thought was that the number of elements is too high bc it says the maximum "n" is 9 digits, but if I add another 0 to the vector (like "1000001" instead of "100001") it gives me the "caught fatal signal 11" on every test (because the vector elements number is too high).... so i don t know what to do

#include <fstream>
#include <cmath>
using namespace std;
ifstream f("pozmax.in");
ofstream g("pozmax.out");
double v[100001];
int i, n, dif, difmax, k,maxi;
int main()
{

    f>> n;
    maxi=-99999999;
    for (i = 1; i <= n; i++)
        f>> v[i];
    for (i = 1; i < n; i++)
        if(v[i]>maxi)
            maxi=v[i];

    for (i = 1; i <= n; i++)
        if(v[i]==maxi)
            {k=i;
                break;}
    g<<k<<" ";
    for (i = 1; i <= n; i++)
        if(v[i]==maxi)
            k=i;

    g<< k;


    f.close();
    g.close();
    return 0;

}
Mister Adrian
  • 49
  • 7
  • 2
    Array indices start from `0`, not `1`. – HolyBlackCat Nov 12 '19 at 18:43
  • if i go from 1 to <=n or 0 to – Mister Adrian Nov 12 '19 at 18:44
  • 1
    It's not the same thing if you're using `v[i]`, though. – Fred Larson Nov 12 '19 at 18:45
  • You can use [Valgrind](https://www.ibm.com/developerworks/community/blogs/6e6f6d1b-95c3-46df-8a26-b7efd8ee4b57/entry/detect_memory_leaks_with_memcheck_tool_provided_by_valgrind_part_i8?lang=en) to diagnose segfault errors – Jazzwave06 Nov 12 '19 at 18:45
  • You mean it crashes regardless? Or you're saying this shouldn't change anything? – HolyBlackCat Nov 12 '19 at 18:45
  • 1
    I think you need to range check `n` to make sure it doesn't go outside the bounds of your array. – Fred Larson Nov 12 '19 at 18:47
  • No, it doesn t crash, but the fatal signal 11 only appears in one online complier like the one an contest is having; codeblocks has something that avoids this error – Mister Adrian Nov 12 '19 at 18:48
  • This is C++. Please use `std::vector` instead of a fixed-size C array. You won't have to figure out the size in advance, and you can't overflow it on inserts. You should also look at using iterators instead of index-based `for` loops, these avoid a lot of off-by-one errors. – tadman Nov 12 '19 at 18:48
  • 1
    *"doesn t crash"* 'fatal signal 11' Is basically a crash. – HolyBlackCat Nov 12 '19 at 18:49
  • Also make sure your files `f` and `g` are opening successfully. – Fred Larson Nov 12 '19 at 18:50
  • 1
    @HolyBlackCat It's precisely a crash as signal 11 is a segmentation violation (SIGSEGV). – tadman Nov 12 '19 at 18:50
  • on the codeblocks it runs ok, it gives me the right answer but when i put the code into an online compiler to know if i have 100 or 0 points at that problem it tells me "Caught fatal signal 11", that s what i mean – Mister Adrian Nov 12 '19 at 18:51
  • yea, they are oppening successfully – Mister Adrian Nov 12 '19 at 18:51
  • I have a feeling this code could be boiled down to a handful of lines that basically runs [`max_element`](https://en.cppreference.com/w/cpp/algorithm/max_element) on a Standard Library container. – tadman Nov 12 '19 at 18:52
  • i just think that the "double" type allocates more locations of memory, like for 3.14 it allocates 4 locations(for 3 . 1 4) and it can not work well with 9 digit numbers – Mister Adrian Nov 12 '19 at 18:53
  • 1
    @MisterAdrian Not at all. That uses a [well known floating point format, IEE754](https://en.wikipedia.org/wiki/IEEE_754) on most architectures. A double can handle numbers a lot bigger than nine digits. – tadman Nov 12 '19 at 18:54
  • probably the big double type numbers are not meant to be putten in a vector idk – Mister Adrian Nov 12 '19 at 18:55
  • Why is `maxi` an `int` instead of a `double`? – Fred Larson Nov 12 '19 at 18:55
  • `std::vector` is perfectly valid. – Fred Larson Nov 12 '19 at 18:56
  • @MisterAdrian Now you're starting to border on complete paranoia. An introduction to how C++ operates internally may help clear things up here. While templates and such can be complex, the basics of C++ are not that hard to understand and share a lot of commonality with C. There's only dark mysteries involved when you don't know the principles at work, but the good news is getting up to speed on those isn't that difficult. There's surely innumerable YouTube videos on the subject of the Intel Instruction Set Architecture. – tadman Nov 12 '19 at 18:56
  • oh,yeah, maxi should be double , but the error still persists – Mister Adrian Nov 12 '19 at 18:57
  • The only crash-inducing thing I see here is the wrong loop bounds. Are you saying changing all of them to `0`, `< n` didn't work? – HolyBlackCat Nov 12 '19 at 19:03
  • nope, it didn't – Mister Adrian Nov 12 '19 at 19:06
  • Definitely add checks in your code that both files are opened successfully and that `n` is within the range of your array (0-100000). – Fred Larson Nov 12 '19 at 19:08

1 Answers1

0

The reason is quite simple.
You're exceeding the max stack size.
By multiplying your double array size you're increasing the require size in bytes as well.
From 100001 * 8 => ~0.76MB up to ~7.63MB which exceeds most of all systems default stack size.
More details about the stack size could be read here: https://stackoverflow.com/a/1826072/10503293

A simple solution would be to allocate the array on the heap like: 

double* v = new double[1000001];
... code ...
delete[] v;
WolverinDEV
  • 146
  • 1
  • 5