[BUG]: Memory overflow with no error from BINS

[mads-bertelsen]

Describe the bug
When writing to a NeXus file using an instrument containing a Monitor_nD component that defines a large bin matrix, the required memory can become large enough to crash the process and no meaningful error message is displayed.

Document steps to reproduce the bug
Steps to reproduce the behavior:

1. Run attached instrument with --format=NeXus

Expected behavior
If the required memory is larger than whats available, it should crash with a nicer message. Would also be great to limit the amount of memory necessary. There is some logic that only includes spatial dimensions into the BINS matrix, yet it doesn't seem to apply to this situation.

Screenshots
Not applicable

OS and McStas/McXtrace version (please complete the following information):

• OS: OS X 14.8.7 (23J520)
• McCode variant McStas
• Version 3.7.1

Add your code / dataset
bins_crash.instr.zip

Additional context
The produced c file have these uncaught callocs, checking if these return NULL would most likely give an opportunity to show a nice error message that alerts the user to what is taking the memory.

	    detector.p0=(double *)calloc(numbins, sizeof(double));
	    detector.p1=(double *)calloc(numbins, sizeof(double));
	    detector.p2=(double *)calloc(numbins, sizeof(double));
	    if (Vars->Flag_Verbose) printf("1D case %ld \n",Vars->Coord_Bin[1]);
	    for (k=0; k<numbins; k++) {
	      if (Vars->Flag_Verbose) printf("Assigning pixel no [%ld] = %ld\n",k,pix);
	      detector.p1[k]=pix;
	      pix++;
	    }
	    mcdetector_out_1D_nexus(detector);
	    free(detector.p0);
	    free(detector.p1);
	    free(detector.p2);

	    detector.p0=(double *)calloc(Vars->Coord_BinProd[Vars->Coord_Number], sizeof(double));
	    detector.p1=(double *)calloc(Vars->Coord_BinProd[Vars->Coord_Number], sizeof(double));
	    detector.p2=(double *)calloc(Vars->Coord_BinProd[Vars->Coord_Number], sizeof(double));
	    if (Vars->Flag_Verbose) printf("2D case %ld x %ld \n",Vars->Coord_Bin[1],Vars->Coord_Bin[2]);
	    for (k=0; k<Vars->Coord_Bin[1]; k++) {
	      for (l=0; l<Vars->Coord_Bin[2]; l++) {
		if (Vars->Flag_Verbose) printf("Assigning pixel no [%ld,%ld] = %ld\n",l,k,pix);
		detector.p1[k*Vars->Coord_Bin[2]+l]=pix;
		pix++;
	      }
	    }
	    mcdetector_out_2D_nexus(detector);
	    free(detector.p0);
	    free(detector.p1);
	    free(detector.p2);

	    detector.p0=(double *)calloc(Vars->Coord_BinProd[Vars->Coord_Number], sizeof(double));
	    detector.p1=(double *)calloc(Vars->Coord_BinProd[Vars->Coord_Number], sizeof(double));
	    detector.p2=(double *)calloc(Vars->Coord_BinProd[Vars->Coord_Number], sizeof(double));
	    if (Vars->Flag_Verbose) printf("3D case %ld x %ld x %ld \n",Vars->Coord_Bin[1],Vars->Coord_Bin[2],Vars->Coord_Bin[3]);
	    for (k=0; k<Vars->Coord_Bin[1]; k++) {
	      for (l=0; l<Vars->Coord_Bin[2]; l++) {
		for (m=0; m<Vars->Coord_Bin[3]; m++) {
		  if (Vars->Flag_Verbose) printf("Assigning pixel no [%ld,%ld,%ld] = %ld\n",m,l,k,pix);
		  detector.p1[k*Vars->Coord_Bin[2]*Vars->Coord_Bin[3] + l*Vars->Coord_Bin[3] + m]=pix;
		  pix++;
		}
	      }
	    }
	    mcdetector_out_3D_nexus(detector);
	    free(detector.p0);
	    free(detector.p1);
	    free(detector.p2);

[mads-bertelsen]

This issue was discussed during a meeting with a few comments:

• Torben: Would be great to add unit tests that prevent such an issue in the future
• Thomas: Difficult to test all allocations across the code, but if we made wrappers of malloc / realloc / calloc extra functionality could be added such as checking for failing to allocate, warnings for attempts to allocate crazy amounts of memory or similar

[mads-bertelsen]

I tried catching the NULL pointers in the calloc located in monitor_nd-lib.c, but this doesn't actually trigger. An actual pointer is returned regardless of me asking for more memory than available on my machine, the crash happens as soon as the program attempts to touch the memory. Apparently the memory is promised but not actually allocated yet, didn't know of this mechanism.

It may be that we need to set some sensible size limit as suggested by Thomas.