crash in 8.0.0-alpha1 when using >49 Zernike terms

[atsju]

This comes from #246. I just move it here as it's a different issue and 246 will get closed by #247

#246 (comment)

7.4 is fine for now. Wait until you are back. I found another bug but unrelated to the crash and possibly not a new bug.

If you have a wavefront loaded, then go to "tools" "edit zernike values", then check the first zernike term (critical for graph to work well) and then check any value after 49 and put in a value of 1 and then click "create wavefront", the lastest code will crash as expected.

Version 7.4 doesn't crash for me (but it should I think?) and it doesn't seem to do anything with the zernike's above 49. Here's the line of code that caught my attention:

DFTFringe/zernikeeditdlg.cpp

Line 68 in c6ec43f

zernikePolar zpolar(rho, theta, tableModel->rowCount());
The 3rd parameter is 81 by default. This definitely causes an error in v8.0.0 in zernikePolar (it prints a warning and then when you go to use the array, values > 49 will crash).

I'm not sure what this code did in 7.4 and older if you tried to do zerniike's > 49. I'd like you to look at that Julien.

I'm doing other stuff now but I might put in some logging to locate the bug. Will be a pain (waiting for github to build) but I might do it anyway.

So I've narrowed the crash down to a few lines of code:

file >> width;
file >> height;
cv::Mat data(height,width, numType,0.);
spdlog::get("logger")->trace("readWaveFront() width {} height {}", width, height);

for( size_t y = 0; y < height; y++ ) {
    for( size_t x = 0; x < width; x++ ) {
        file >> data.at<double>(height - y-1,x);
        //data.at<double>(height - y - 1, x) += dist(generator);
    }
}
spdlog::get("logger")->trace("readWaveFront() step 2");

It gets toe the first log command and logs this:
[2025-10-04 14:57:43.735] [trace] readWaveFront() width 640 height 640

And that's the last thing logged before crashing. It crashes when loading the first of 4 files to analyze for purposes of the test stand astig removal tool.

However, the strange thing, is that if I click "load wavefront" and load the exact same wavefront, it does not crash and runs right through just fine. In fact I loaded all 4 wavefronts to be sure.

Anyway, could the somehow be related to windows file handling which is typically either binary or text mode where in text mode it messes around with the line endings and in binary mode you see the actual bytes including carriage return and also linefeed?

I think I'll stop here and let Julien look at this in a week or so.

[atsju]

This is a capture from 7.3.4. The way you use to reproduce the bug has never worked. Now in 8.0.0-alpha1 it crashes but before the values where just ignored. Wft is flat and there are lots of NaN.

What is actually working is simulation->wavefront menu

To be honest I don't want to debug this as it's unclear to me what we expect and what is side effect. I would recommend clearly stating the expectations for simulation->wavefront and tools->edit zernikes
Edit zernikes will have an effect on number of zernike terms to use when computing a new wavefront. But you can actually only choose 36 or 49. Less is impossible. More is ignored. If you actually modify value above 49 it crashes in 8.0.0-alpha1 and is probably just 0ed in older versions.

simulation wavefront ont the other side can generate wavefronts from zernikes up to term[143] but the generated wavefront is still only using 49 (or 36 terms). and is an approximation of requested terms ?

So before we go any further (I can probably mask the crash but that's not the point) => what do we want those windows to achieve ? Are they still useful for end user ? For developers ? Should we fix number of term[49] for everything for simplicity ? Should we refactor simulation->wavefront and tools->edit zernikes as they are similar ?
That are only some questions, maybe/probably some are dumb but I don't have the tool knowledge to decide anything.

[gr5]

Zernike terms higher than 49 are probably only useful to people trying to understand zernike terms. They are helpful to me just to simulate them to see what they look like. To help me understand them. I don't think a normal user cares about zernike's above quadrafoil.

But Dale and I and a few other's might find these zernike's above 49 useful just for research (not for testing mirrors).

Zernike smoothing feature can go MUCH higher than 49 terms and it really/truly seems to work. It uses a different method to get the zernike terms. Maybe we can call that function? Or maybe it's too different? I think one way uses x,y coordinates and the other uses angle,radius coordinates? Or maybe not. There's the Michael Peck newer method and the older method I think?

[atsju]

There are 2 or 3 methods. There is an older issue I can try to find where dale explains it. I understand we need to keep this code and is useful to understand zernike terms.

However, I feel like the 2 different menus might overlap. Maybe we should clearly identify them by the method they use ?

Do you think you or Dale could describe the user "needs" and then we conceive/adapt the UI to fit exactly that ? Or maybe I'm just not knowledgeable about these features and they already to exactly what you need the way you need ?

For just a quick fix I would limit the "edit zernike values" to 49 terms and we are done. No more crash and it wasn't working in older version anyway.

For a better fix we need to define the "needs"

[gr5]

That seems fine (limit to 49) to me as I don't think it's normal to edit zernike values and I just tested version 7.0.0 and values above 49 do nothing anyway so let's just limit it to 49 terms.

But I'm more concerned with the crash when you do "test stand astig removal". It crashes in the code that reads in a wavefront file. But only in QT6.

[atsju]

I though that was fixed in #247.
I will have a look later in the week.

[gr5]

I narrowed it down to about 9 lines of code. All to do with ifstream. Something about it doesn't work in QT6. I'm guessing it's reading in binary mode instead of text mode? I was hoping you could step through the code (because I can't).

Also Dale says it's okay to delete the commented out line of code in those lines of code that are crashing.

[gr5]

Here is what I know:
#246 (comment)

[atsju]

OK I reproduced the crash with debugger twice on windows
here is the "call stack"

contourtool.cpp:82 QList<QWidget *> widgets = findChildren<QWidget *>(); => SEGFAULT inside findChildren
contourplot.cpp:437 m_tools->enablTools(true); => this is called twice. Second time, m_tools is NULL. This is the cause of the issue
surfacemanager.cpp:2511 plot->setSurface(wf);
standastigwizard.cpp:304 emit computeStandAstig( this, rotationList);

I haven't had time to dig more for the moment.