-
Notifications
You must be signed in to change notification settings - Fork 28
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.
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
cropgui crashes #114
Comments
Some of the output:
[snip] some output later on:
|
I'm using cropgui 0.7, as AUR-Arch-Package, built this way: https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=cropgui |
That's rather unusual! pango is used for text rendering in gtk, but we don't interact with any of it at a low level. If it's possible to use gtk text display APIs and get a crash, it seems like that is a problem below the level of abstraction where cropgui is operating. Are there any unusual details about the files you're operating on aside from the size and image format? I did find some reports of a crash in pango_glyph_item_iter_next_cluster but they are about displaying odd Unicode text [e.g., https://gitlab.gnome.org/raggesilver/blackbox/-/issues/243] but as far as I see cropgui never displays unicode text other than possibly the filename via the window title... |
Nothing special about the files. I can view them with different viewers, no problems. But in cropgui it is possible to just click CROP again and again, before the message "1 image files updated" is printed on the terminal. That was the reason why I guess that there might be a race condition, maybe some mem is used for the next image, before the last image was updated/written to the output file and before the memory is expected to be reused. |
Actual image cropping is intentionally performed in the background. I tried to reproduce this on Debian Stable but was not able to. I tested at v0.7-3-g8e736f9 with 25 copies of this AI-generated nonsense image in png format: http://media.unpythonic.net/emergent-files/sandbox/croptest.png I repeatedly clicked the "crop" button as fast as I could. Nothing bad seemed to happen. Here's the resulting terminal output:
Thanks for any additional information you can provide to help me reproduce the problem. |
Funny AI-nonsense image :-) The problem might come from race conditions, when the computer is comparingly slow. |
I was wondering about the use of "nice", and this seems to be a (cough) nice place to ask... Why is "nice" used at all? I would expect the usage of this program to be interactive, and thus there is a human sitting there waiting for the results. This is unlike the situation where I want to compute pi to 1E6 digits, and I will be back tomorrow looking for the answer, but I am doing this on a shared computer and don't want to be anti-social. Although I can imagine people using cropgui on a shared computer, again it seems most likely to be on a personal computer. Thus my curiosity about its use here. Can you enlighted me? Thanks. |
The subprocess commands are run in a CropTask accepts jobs into its This allows the actual action of invoking jpegtran, convert, etc., not block the main UI. In the case of multiple CPUs, it also allows multiple actions to take place in parallel. Because these are not interactive tasks, they are prefixed with "nice" so that the UI task gets higher priority. (The main thread still blocks for image decoding, though) Note: This code either predated For the purposes of determining whether this bug is a race condition, perhaps a version of CropTask should be added that doesn't use threads but does everything in the foreground/blocking. That assumes you can reproduce it in the first case, which unfortunately I was not able to do. |
Cropping PNG-files with a size of between 2MB and 2.6MB I get a crash after cropping some of the files.
I recorded the output on the terminal with asciinema.
But attaching is not allowed here ("We don’t support that file type.").
I think you can replicate the behaviour by just putting a lot of large png-files together and try to crop them fast one after another. After 10 or 15 files have been processed, yo can expect the program to crash (sometimes it just hangs).
I guess the problem may occur, if processing is not completed before the next file is worked on in the GUI of cropgui, maybe some kind of race condition. But that's just a guess.
The text was updated successfully, but these errors were encountered: