Heap buffer overflow and segmentation fault in collapse_array #1431
Comments
|
Adding some additional information here... This error appears to arise when including a 2D DFT field monitor slice through the 3D domain of the forward simulation (unrelated to the design regions / gradients) for inspecting the fields. If I remove that DFT field monitor, then I get a "heap buffer overflow" at the same location as in #1432. Converting the simulation to 2D and keeping the 2D DFT field monitor results in a "heap buffer overflow" at the same location as in #1432: |
|
Unfortunately, the unit test for Based on this, it's not surprising that several bugs have gone unnoticed since this feature was first introduced in #552 and #655. |
|
Actually, there is a Python unit test for We should expand the test suite for |
|
Note that the "uncollapsed" arrays already include the interpolation weights, which is why |
|
The following simple test for import meep as mp
import numpy as np
sim = mp.Simulation(cell_size=mp.Vector3(5,5),
resolution=10)
sim.init_sim()
dy = np.linspace(0,0.1,11)
for d in dy:
(x,y,z,w) = sim.get_array_metadata(center=mp.Vector3(0,d), size=mp.Vector3(0.5,0), collapse=False)
if (w.ndim == 2):
print('{:.3f}, {:.3f}, {:.3f}'.format(d,np.sum(w[:,0]),np.sum(w[:,1])))
elif (w.ndim == 1):
print('{:.3f}, {:.3f}'.format(d,np.sum(w)))The output is: This output is incorrect because as the grid slice is swept through a distance of one pixel, the sum of the weights in each uncollapsed element (columns 2 and 3) should change but in fact they are constants. Note that for the slice at However, something unexpected happens when this same script is run a second time: the results are different. For several different values of Additionally, the same effect is observed for a 2d slice of a 3d cell: import meep as mp
import numpy as np
sim = mp.Simulation(cell_size=mp.Vector3(5,5,5),
resolution=10)
sim.init_sim()
dz = np.linspace(0,0.1,11)
for d in dz:
(x,y,z,w) = sim.get_array_metadata(center=mp.Vector3(0,0,d), size=mp.Vector3(0.5,0.5,0), collapse=False)
if (w.ndim == 3):
print('{:.3f}, {:.3f}, {:.3f}'.format(d,np.sum(w[:,:,0]),np.sum(w[:,:,1])))
elif (w.ndim == 2):
print('{:.3f}, {:.3f}'.format(d,np.sum(w)))The results for the 3d case also change unpredictably for different runs: run 1 run 2 Why the results are changing from one run to the next may be a clue to tracking down the bug. |
|
I think I have tracked down the cause of this bug. This requires some explanation to go through The bug itself seems to be related to this line in Lines 485 to 487 in f5fc4cd The problem lies with The first thing that happens in Lines 727 to 728 in f5fc4cd What is important here is that the default value for the argument Lines 1701 to 1702 in f5fc4cd The Lines 436 to 438 in f5fc4cd Note that Lines 331 to 341 in f5fc4cd The key point is that Next, after computing the Line 734 in f5fc4cd This is where the problem lies because Lines 487 to 492 in f5fc4cd Here the rank returned by Line 553 in f5fc4cd This creates a discrepancy because the |
|
I can confirm that this is fixed in v1.17.0. I am now only getting the output described in #1432 when running ASAN. |
I am getting a heap buffer overflow error when running address sanitizer on a 3D version of one of the adjoint optimization examples. It seems to be pointing to line 698 of array_slice.cpp:
meep/src/array_slice.cpp
Line 698 in 41548a3
Below is the address sanitizer output, where it looks like something resembling an off-by-one issue. I've been getting segmentation faults when trying to run an optimization under MPI, with stack traces resembling the one shown below.
The text was updated successfully, but these errors were encountered: