-5

I have this code

typedef long long int ll;
#define MOD 1000000007
ll t,n,total,answer[2][1025];
int arr[100001];
cin>>n;
for(int i=0;i<n;i++)
cin>>arr[i];
memset(answer,0,sizeof(answer));
memset(arr,0,sizeof(arr[0]*n));
for(int i=1; i<n; i++)
{
    for(int j=0; j<=1024; j++)
    {
        int index1=(i-1)%2;
        int index2=j^arr[i];
        ll pre1=answer[index1][j]%MOD;
        ll pre2=answer[index1][index2]%MOD;
        answer[(i%2)][j]=(pre1+pre2)%MOD;
    }
}

I am not able to find out why this code is giving RE(SIGSEGV). Can anybody help ?

  • 2
    where do you assign a value to `n` ? What is the value of `MOD` ? And what is `ll` ? Besides that: what is the right to exist of that program (except of crashing ...) ? – Marged Dec 08 '15 at 22:05
  • 1
    OK, you edited it, invalidating comments/answers:( Next - what did you find out when you ran it under your debugger? Which line generated the error and what were the relevant var values? – Martin James Dec 08 '15 at 22:09
  • Sorry, but you are changing stuff faster than I can read it. – Martin James Dec 08 '15 at 22:10
  • anyway memset is not about c++, you have to use [std:fill](http://www.cplusplus.com/reference/algorithm/fill/) – fedorshishi Dec 08 '15 at 22:11
  • Possible duplicate of [Definitive List of Common Reasons for Segmentation Faults](http://stackoverflow.com/questions/33047452/definitive-list-of-common-reasons-for-segmentation-faults) – Barmar Dec 08 '15 at 22:11
  • 1
    I'm voting to close this question as off-topic because continual editing changes the source code faster than than can be read. – Martin James Dec 08 '15 at 22:11
  • this is the final code – vishwas kumar Dec 08 '15 at 22:12
  • 1
    @MartinJames That's not a reason to close the question. Posters are **supposed** to clarify the question if there are problems with the way it's written. – Barmar Dec 08 '15 at 22:14
  • Which line is the segmentation violation happening on? Have you tried stepping through the program with a debugger, to see the values of the variables when this happens? – Barmar Dec 08 '15 at 22:15
  • What are you entering as `n`? – Barmar Dec 08 '15 at 22:16
  • @Barmar n is an integer value which can have maximum 100000 value – vishwas kumar Dec 08 '15 at 22:21
  • When `j` is exactly equal to 1024, assuming input `<1024` you get `index2` up to 2047. I'm sure that is not what you want. Did you really want `j` up to 1024? – JSF Dec 08 '15 at 22:25
  • @JSF yes, j must be less than 1025 – vishwas kumar Dec 08 '15 at 22:26
  • @Barmar 'Posters are supposed to clarify the question', what, continually, after/during contributors answering it? – Martin James Dec 08 '15 at 22:26
  • @vishwaskumar Did you miss my point? The problem is `index2` up to 2047. Do you not see why you caused that or do you not see what that causes a seg fault? – JSF Dec 08 '15 at 22:28
  • @MartinJames Yes. If an answer is based on an incorrect explanation of the problem, the poster is supposed to fix it. If that invalidates the answers, so be it. What do you expect him to do, delete the question and post it again? – Barmar Dec 08 '15 at 22:28
  • @JSF How does `index2` go up to 2047? Since `arr[i]` is `0`, `j^arr[i]` is just `j`. – Barmar Dec 08 '15 at 22:29
  • 1
    Notice the misplaced `)` in `sizeof(arr[0]*n)` If you really intended to overwrite all your input with zero, you failed. But what was the input for if you intended to overwrite all of it with zero? – JSF Dec 08 '15 at 22:30
  • @JSF post that as an answer and vote to close the question as a typo. – Barmar Dec 08 '15 at 22:35
  • @Barmar, I wasn't convinced the **intent** was to throw away all the input without using it. So I don't believe that is a whole answer. I'm convinced the out of range value of `index2` is the direct cause of the seg fault, but it is unclear which other error**s** lead to that. – JSF Dec 08 '15 at 22:38
  • @JSF yes the error was due to 1025. It needs to be 2047. Thanku – vishwas kumar Dec 08 '15 at 22:40
  • @JSF There may be other problems with his program (I can't guess what it's supposed to do), but that's almost certainly the reason for the SIGSEGV. He's only zeroing the first few bytes of `arr[]`, so he's XORing with random data after that. – Barmar Dec 08 '15 at 22:41
  • @vishwaskumar but what did you intend that bizarre way of clearing the beginning of `arr` to do? – JSF Dec 08 '15 at 22:42
  • @Barmar, in case you missed that, we have now been told the major error was that `answer` was intended to be big enough to allow `index2` to be 2047. That was one of my many unstated guesses for what comes after understanding `index2` was too big for `answer`. (Less serious bugs still likely present). – JSF Dec 08 '15 at 22:45
  • I still don't see how `index2` can ever get to `2047`. If he zeroes `arr[]` correctly, `index` is always the same as `j` (because `anything XOR 0` is `anything`), which is limited to `1024`. – Barmar Dec 08 '15 at 22:48
  • @Barmar I don't have a good guess what was intended by the code that looks like a bad attempt to overwrite all the input with zeroes. You are correct that you could get rid of the seg fault by changing that to really overwrite all the input. But since **that** isn't what was intended, it is not a correction, it would be covering up a bug with a bigger bug. Before Vishwas commented, one of the many possibilities I was considering was that zeroing all the input was intended. But now we have been told otherwise. – JSF Dec 08 '15 at 22:55

1 Answers1

0

You need to check n for validity because otherwise the user is able to crash your program instantly. As soon as n (and thereby i) gets out of bounds you will address memory that does not belong to your program.

  • Unless he's entering something higher than `100000` it wouldn't cause an error. – Barmar Dec 08 '15 at 22:23
  • @vishwaskumar: you don't enforce that anywhere –  Dec 08 '15 at 22:25
  • @Barmar this is what I meant by _validity_ and _able to_. Vishwas allows the user to enter invalid values and till now he did not tell us which value he gives to `n` when running the program –  Dec 08 '15 at 22:26
  • @anybody That's why I asked him what he's entering in a comment, before posting an answer that assumed he was giving invalid input. – Barmar Dec 08 '15 at 22:30
  • @Barmar It is not an assumption that incorrect values for `n` will lead to problems. Besides that: new users can not comment, I am sure you know that. –  Dec 08 '15 at 22:33
  • I asked the question 4 minutes before you posted the answer, so it doesn't matter if you can't comment. You should have waited for the answer. – Barmar Dec 08 '15 at 22:34