Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

wxmaxima crashes when exporting a sheet containing (3D) animations. #1616

Closed
openparalution opened this issue Jan 11, 2022 · 16 comments
Closed

wxmaxima crashes when exporting a sheet containing (3D) animations. #1616

openparalution opened this issue Jan 11, 2022 · 16 comments
Assignees
@gunterkoenigsmann

Comments

@openparalution
Copy link

openparalution commented Jan 11, 2022 •
edited
Loading

Sheets with embedded animations cannot be exported or printed: as soon as you try to do this it simply crashes the wxmaxima GUI. A workaround is to hide all animations before printing or exporting, but that is of course not a real solution.
OS: Linux Debian 11 with wxwidgets 3.0.5.1+dfsg-2

Would be nice if this could be fixed, so our students can hand in a PDF version of their work without seeing crashes ;-)

Best Casey
@gunterkoenigsmann
Copy link
Member

I cannot guarantee that I will have time to fix that tomorrow. But I promise to fix it as fast as I can.

@gunterkoenigsmann gunterkoenigsmann self-assigned this Jan 11, 2022
@openparalution
Copy link
Author

openparalution commented Jan 11, 2022 via email •
edited
Loading

@gunterkoenigsmann
Copy link
Member

Am still trying to reproduce the problem on different systems, but to no avail => Either I am doing something wrong, or I am missing the crucial piece of knowledge that I would need for crashing the program - or the bug has been resolved in the meantime, but only after the release your students are using. Another possibility is that all of my systems happen to fill the crucial byte in memory with the right contents before it is used by pure accident - which actually happens quite often, as wxMaxima uses lists extensively and pointers to plausible list elements might still lie in memory locations that were used only a while ago.

@openparalution
Copy link
Author

openparalution commented Jan 25, 2022 via email •
edited
Loading

@gunterkoenigsmann
Copy link
Member

Ok... ...after 21.05.1 I re-wrote part of the image and slideshow handling. Perhaps I accidentally fixed that bug...

@openparalution
Copy link
Author

openparalution commented Jan 28, 2022 via email •
edited
Loading

@gunterkoenigsmann
Copy link
Member

If you are able to crash the program and are able to produce backtraces I would be very happy as it is possi le to find crashes by looking at the code. But doing so requires much time and luck, in the best case.

@openparalution
Copy link
Author

openparalution commented Jan 28, 2022 via email •
edited
Loading

@openparalution
Copy link
Author

openparalution commented Jan 28, 2022 via email •
edited
Loading

@gunterkoenigsmann
Copy link
Member

One additional request: Could you type the command

backtrace

Into the gdb after the crash?
The line itself looks harmless: The system has reserved memory for all the variables an image object consists of and now we assign some of these bytes in memory a value. But sometimes completely harmless code crashes if something messed up the system on the way to the harmless code. Normally the backtrace tells a quite detailed story of what happened on the way to the crash.

@openparalution
Copy link
Author

openparalution commented Jan 29, 2022 via email •
edited
Loading

@openparalution
Copy link
Author

openparalution commented Jan 29, 2022 via email •
edited
Loading

@openparalution
Copy link
Author

openparalution commented Jan 29, 2022 via email

@gunterkoenigsmann
Copy link
Member

What I still don't get is: The image is at the memory address 0x03. Everything else is at an address like 0x555555710e18. Where do we get that obviously wrong image address from?

gunterkoenigsmann added a commit that referenced this issue Jan 30, 2022
@gunterkoenigsmann
Got rid of SlideShowCell:m_size
f7e0cca 
We stored the number of frames in an animation in two
locations => got rid of one.

One step to get rid of #1616
gunterkoenigsmann added a commit that referenced this issue Jan 30, 2022
@gunterkoenigsmann
A stronger SlideShow::IsOk()
61b68e2 
Another go at #1616
@openparalution
Copy link
Author

openparalution commented Jan 30, 2022 via email

@gunterkoenigsmann
Copy link
Member

Thanks a lot!

And thanks for this bug report. Since I didn't find the bug I re-wrote all the parts of image handling that I didn't understand - which has the side effect that I believe I have been finally able to add consist handling of image sizes to the program.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@gunterkoenigsmann gunterkoenigsmann

Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@gunterkoenigsmann @openparalution