Nesting functions which take same pointer as arguments

Please open the file code.c in a suitable text editor (like notepad++, to help keep track of the line numbers)

Line 738: Let us consider the variable R (5th argument in the function MP_modKalMontInv() ). R is passed by reference so the function MP_modKalMontInv() should get an address to R

Line 565: Inside the function MP_modKalMontInv(), R is further passed into the function MP_monmul_SandK_ver() which is also declared to take address of R (function definition at Line 293)

Line 310: The address of R is further passed into show_mp_int_fullinfo() but the program now crashes at Line 14 (line 14 is not executed). Why should that happen and what can I do to correct it?

This program uses the LibTomMath library. R is of type mp_int, which is a structure declared in the LibTomMath library as

Code:

---

typedef struct {
  int used, alloc, sign;
  mp digit *dp;
} mp int;

---

At the menu screen enter 9
Then enter the following values sequentially when asked
1
3333333333
1
3333333333
then press any keys except q at the getch()'s and when the program flow reaches the line described above the program crashes
I have recreated a similar scenario in the file code.c, however that one doesn't crash.

Could anyone please give me some idea about this?
Thank you very much.

PS: I am using Codeblocks 8.02 with gcc version 3.4.5 (mingw-vista special)

Another hint:
by adding

Code:

---

if(!a) {printf("Null Pointer"); exit(0);}

---

at the beginning of the function show_mp_int_fullinfo() it looks like the program is crashing due to null pointer assignment when calling the function
My question is why is this happening, when it does not happen in the other program code.c ?

My suggestion is that now is a really good time to start learning about debuggers.

You can use it to catch the moment a program crashes, and then look around the program state to see what went wrong. If a param is NULL, then you can step out a stack frame and see why the caller passed in NULL to begin with.

You can set breakpoints near to where you suspect a problem, then single step the code until the problem reveals itself.

You can even change variables on the fly to be "correct", just to see how the code would behave before you re-edit the code and test again.

Dumping 500+ line programs for someone else to fix is not a long term strategy. What happens when you get to say 5K lines and you still don't know about debuggers.