I’ve encountered a reproducible problem when trying to run an old workflow in KNIME 3.7 on MS 10 Windows enterprise.
It will sometimes run successfully the 1st time, but not always; a change to a new input dataset will definitely cause it to freeze in mid-process see the image below -
it will show a ! triangle over the groupby node but hovering over that with the mouse pointer shows no further info. If I then try to open the error log window the graphics start freezing up in different ways (see 2nd image).
KNIME is completely unresponsive at this point, doesn’t recover and requires a forced end task to close. Some others windows on the PC also start suffering graphics issues when this happens. I’m wondering if the graphics requirements have changed with 3.7? KNIME 3.6 was extremely stable / reliable on this same PC.
have you tried resetting the whole workflow and changing the storage policy to Parquet? If you could upload and example (maybe with dummy data) I could check on my Mac if I can get any hint.
Next thing could be to change the storage policy of the node in question to either keep everything in memory or force it to store it on disk.
Ok - good (well, still bad, but not worse - so good…) - both this and KNIME 3.7 freezes do appear to be hitting the same underlying GDI Object issue - but on first blush there seems no UI level commonality between what is going on in KAP when it happens. … will investigate
Thanks for the suggestions and questions. Here are the outcomes (all negative sadly) :-
Resetting the workflow is impossible once it has got to that stage as KNIME/Eclipse is totally non functional beyond resizing the window.
Retested this morning and the same problem came up when running the workflow on the same data a 2nd time after a reset – it’s frozen up as before and the task manager is showing the following which is weird because there is no Joiner node in the entire workflow! But there is node that matches those criteria in a separate open workflow but that’s saved and idle.
This output has only come up once in Task manager.
The majority of the below tests failed first time after restarting KNIME.
I tried setting GroupBy node to all in memory but this made no difference.
Also set GroupBy to write table to disc – this also froze but didn’t give the error flag ! in the GroupBy node it’s just showing queued.
I also then tried setting the whole loop to write to disc, and also to all in memory, but both runs failed.
The change of storage policy to Parquet also failed on it’s own and in combination with the above.
I’ll upload the workflow with some data to see if folks can reproduce the problem.
Thanks for the workflow - i can get this to occur on the fourth or fifth re-run of the workflow and i have an idea about why. We’ll investigate and hopefully have a nightly build for you to test early next week.
Good to hear that the problem is reproducible for you. Also interesting to learn that it took 4-5 rerun to occur; I got a sense that this “cleaner” example build was a bit more reliable than the version I originally found the problem with.
Looking forward to having the test to try out next week.
I tried several variations with reset of the Loops and Memory Policy settings on a Mac and can not reproduce the problem, so it might be confined to a Windows system.
Indeed, i cannot replicate it on Mac - Windows historically has an issue with SWT & handles to its graphics subsystem if you misstep; we’ve evidently introduced a misstep that eluded our test suites :- /
Same here on Windows 10 64 bit and KNIME 3.7. Freezes happen. Related to annotations: every time I’m clicking or double-clicking on an annotation (not sure where exactly - border or text), I got a freeze. Only solution is Task Manager > kill the process and open again (tip-toeing around annotations to avoid another freeze…). I’ll try to reproduce it again to bring more details to the discussion. If you know a fix in the meantime, would be great. Thanks! FYI - I got this bug while working on dual monitor as well as single monitor.
If you could come up with a reproducible method, that would be very helpful; we’ve identified the sources of the OP’s use case, but they arise due to the frequent updating of node states within the many-time-iterated loop.
It sounds like from what you’ve written, that you’re “simply” clicking on annotations (?while you are are in Annotation Edit mode (with the nodes greyed out)?) and that causes the freeze you see. Is that correct?
@johnprime - a fix that addresses your issue is in the PR process; if you’re technically comfortable copying a jar and don’t want to wait for the nightly build following the PR merge, I can supply you with a jar for the workbench editor plugin. You can email me at Gmail, my username.
Yep, that’s it. Simply clicking on annotations in Editing Mode - others nodes being grayed out. Also noticed that freezes could happen when switching back to the model after editing the annotation. I cannot reproduce it on the model I am working on right now (only 1 annotation present on the map). It looks like the freeze only occurs when multiple annotations are present in the model. I’ll go back to the model that causes the bug later on and keep you posted on any method I may come up with. Thanks!
If you’re able, and wouldn’t mind, could you attach the workflow to this forum post? Have you executed this workflow or any other workflow during your running of KAP prior to the freeze? If so, have any of the executions included loops? Thanks - loki
Hi,
Just for following this problem because I’m in the same situation : Knime 3.7 (on windows 7 professionel, version 6.1.7601, service pack 1 Build 7601) freezes when editing an annotation (double click on the left corner) even when no workflow element is running.
:-