Multiprecision variables segmentation fault

Hello! I have a program using multiprecision variables, specifically through the zkcm package (based on gmp and mpfr I think). It works fine up to a certain precision, but at 1024 bits per variable (I use matrices so it's per element I guess) and upwards I get a segmentation fault.

From mpfr's limit this amount of memory shouldn't cause any trouble. Moreover the fault happens at a strange point every time. Here's the relevant piece of code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
for(i=0;i<t;i++) {	
	zH.set("1", i, i);
	
	for(j=0;j<i;j++) zH.set("0", i, j); 
	
	for(j=0;j<i;j++) {
		for(k=0;k<i;k++) {
			zden="0";
		
			for(a=0;a<=i;a++) {		
			        for(b=0;b<=j;b++) zden+=zH.get(i, a)*zH.get(j, b)*zJ.get(a, b); 
			}
			
			znum="0";
			
			for(a=0;a<=j;a++) {	
				for(b=0;b<=j;b++) znum+=zH.get(j, a)*zH.get(j, b)*zJ.get(a, b);
			}
			
			zH.sub(zden*zH.get(j, k)/znum, i, k);
		}
	}
	
	for(j=i+1;j<t;j++) zH.set("0", i, j); 
}	


When the precision is 1024 and t=27 this works fine until i=26, j=24 and k=25, whereupon it crashes. Remember the same code works fine with lower memory for the variables.

Any ideas?
Any ideas?

Build with debug symbols and run it under a debugger. It will stop on the line that causes the segFault and you can check the values to see which is bad.
Last edited on
You know, I didn't even know about this stuff, looking into gdb now (is it a good one?).

Thanks!
In this thread is a brief example. It should be all you need to find the problem.

http://www.cplusplus.com/forum/unices/73830/
Thanks! I'm looking into all this now. So far I get this from gdb:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Program received signal SIGSEGV, Segmentation fault.
0x61129259 in memset () from C:\cygwin\bin\cygwin1.dll
(gdb) warning: cYgFFFFFFFF 6119FE20 0
warning: cYgstd 28ac29 d 3

(gdb) backtrace
#0  0x61129259 in memset () from C:\cygwin\bin\cygwin1.dll
#1  0x6ca87bb7 in cyggmp-3!__gmp_sprintf () from C:\cygwin\bin\cyggmp-3.dll
#2  0x6ca87455 in cyggmp-3!__gmp_doprnt_mpf2 ()
   from C:\cygwin\bin\cyggmp-3.dll
#3  0x6ca866e1 in cyggmp-3!__gmp_doprnt () from C:\cygwin\bin\cyggmp-3.dll
#4  0x6ca87b77 in cyggmp-3!__gmp_sprintf () from C:\cygwin\bin\cyggmp-3.dll
#5  0x004317ee in _fu0___ZSt4cerr () at zkcm_cppwrap.hpp:1471
#6  0x00431675 in operator<< (ostr=..., z=...) at zkcm_cppwrap.hpp:1437
#7  0x0040236c in _fu89___ZSt4cout () at GirSGS2.cpp:213 


and I'm trying to figure it out. Looking at it though makes me feel I'm a bit out of my depth.. problems in cygwin files?
just my 1 cent worth ....

you have a few of these:

for(a=0;a<=i;a++)

This might be a silly question - I am sure you know what you are doing. Do you want the loop to do i+1 loops? Might this cause an overstep of an array boundary somewhere? i and j seem to equal t, is t+1 going to cause a problem?

You probably have a valid reason for doing this, if so let me know and I will leave you to it.
That backtrace doesn't look very helpful. Did you include debugging symbols in your code (i.e. compile with the -g option, under many compilers, or equivalent option if you're using a crazyland compiler)?

Is this - GirSGS2.cpp:213 - your code? What's on line 213 of the file named GirSGS2.cpp?

problems in cygwin files?

Very unlikely. The segFault happens in memset, because memset is being given a bad value by __gmp_sprintf, which is being given a bad value by __gmp_doprnt_mpf2, which is being given a bad value by... etc etc, all the up to the top calling function, which is part of your code.
Last edited on
Thanks for that! I think that line is ok however, since you see although a goes all the way up to i, i is always < t.
Hopefully I am not being a pain but in this line:

for(i=0;i<t;i++)

At the end, isn't i == t, so that i<t becomes false to end the loop?

This would only be a problem if i==t, j==t, k==t would cause a problem elsewhere in your program.

It's just that every time I see for(a=0;a<=i;a++) instead of for(a=0;a<i;a++), I think it is a very common way to cause a memory error - and that is exactly what you have. I am bound to be wrong (it's not the first time & certainly not the last !!)

Just to be thoroughly annoying, do you have a reason for wanting to loop i+1 times?

since you see although a goes all the way up to i, i is always < t.


So I am saying i==t and even though a goes all the way up to i, the loop executes i+1 times (or tries to).

Any way that's it - I will shutup now - I fear I have already made a clown of myself.
You're too modest, I appreciate your input!

I still think however that no of the variables ever go over t-1 (maybe I'm the clown here). The a and b variables are indeed I think supposed to go all the way up to i, so that on the first round (i=0) they will have a single value 0, next round they will have 0 and 1, then 0 and 1 and 2 and so on.

for(i=0;i<t;i++)
At the end, isn't i == t, so that i<t becomes false to end the loop?

I'm a bit puzzled by this, the way I understand it in the last round we have i=t-1 and then everything within the brackets (including the a and b loops executing from 0 to i-1 inclusive) happens, whereupon the loop quits since the next value would be i=t; nothing is actually executed with this value.

Wrong?
Moschops: I missed your reply there as I was writing my own, thanks!

I am indeed compiling it with -g (at the very end of the makefile, I assume its position doesn't matter?). And yeah GirSGS2.cpp is my code. The funny thing is, line 213 is after where the crash occurs (i.e. after the loops in the snippet in my first post); as evidenced by putting cout << i << " " << j << " " << k << endl everywhere to see where it stops. Line 213 is line 2 of this:

1
2
3
4
for(i=1;i<t;i++) {
	for(j=0;j<i;j++) outmatrix << zH.get(i, j) << "   ";
	outmatrix << endl;
}


where outmatrix is an ofstream object.

Ok, your last paragraph helps me understand this (still reading up). Still puzzled though, especially since the error only happens at a certain memory size of the variables which should be well below the accepted treshold.

EDIT: spelling
Last edited on
Boing!

I removed line 213 and it now works, so I know where the error is. It's still strange to me that this line could defeat relativity and affect the code backwards in time to stop the program in an earlier loop, but I'll focus on debugging this line.

Thanks for all help!
whereupon the loop quits since the next value would be i=t; nothing is actually executed with this value.

Wrong?

Yes. Try it out:
1
2
3
4
5
6
7
8
#include <iostream>

int main()
{
      int i;
      for (i=0; i<5; i++);
      std::cout<<i;
      }
Last edited on
What you are saying is right. It is me who is discombobulated.!! :=D
viliml: you are right but that is after the loop is done, in the snippet I posted everything happens within the i-loop so i is always < t.

Ideasman: thanks for a new word!

In case anyone has the same problem and ends up in this thread: it turned out to be a stupid int overflow further down the code which somehow made the program stop a while before it actually occured.
Topic archived. No new replies allowed.