Lance wrote on Mon, 14 October 2024 17:37

ok. please see attached.

Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch...

Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory...

After that, you can try to activate the fix, uncomment / #if 1

CtrlCore/CtrlPos.cpp:157
CtrlCore/CtrlDraw.cpp:52

Mirek

mirek wrote on Tue, 15 October 2024 03:02

Lance wrote on Mon, 14 October 2024 17:37

ok. please see attached.

Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch...

Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory...

After that, you can try to activate the fix, uncomment / #if 1

CtrlCore/CtrlPos.cpp:157
CtrlCore/CtrlDraw.cpp:52

Mirek

I have actived the tentative fix. I am about to start testing the fix.

Lance wrote on Tue, 15 October 2024 23:56

mirek wrote on Tue, 15 October 2024 03:02

Lance wrote on Mon, 14 October 2024 17:37

ok. please see attached.

Thanks it, hopefully getting close... More logs added, so please repeat after pulling "logs" branch...

Also, I have potential fix included, but I really would like to get freezed log first to confirm my theory...

After that, you can try to activate the fix, uncomment / #if 1

CtrlCore/CtrlPos.cpp:157
CtrlCore/CtrlDraw.cpp:52

Mirek

I have actived the tentative fix. I am about to start testing the fix.

Oops, no, I would really like to see the new log before the fix! (Just to confirm I am fixing the right problem this time).

Caught one. Please see attached.

Lance wrote on Tue, 15 October 2024 15:21

Caught one. Please see attached.

Cool. It is consistent with the attempt at fixing it...

No rush. I likely had another freeze but I am not 100% sure. Would it be possible for you to log a indicator version number etc in the log file?

Caught another one. Please see attached.

Any context BTW? I mean any action performed before it got stuck? Maximise/minimise/moving window or something like that?

Lance wrote on Thu, 17 October 2024 21:02

Caught another one. Please see attached.

Uh oh... More logs added to "logs". Please keep testing.

I can pretty much be sure the bug is still around. theide hasn't failed yet, but my application compiled with the logs branch u++ libary failed just now.

And what about logs?

Mirek

mirek wrote on Mon, 21 October 2024 07:17

And what about logs?

Mirek

Oh, I though the one generated while running theide is more desirable. Please see attached.

No. It was fine. But after it froze, I left it unkilled for a while, afraid of another run will erase the log file. OK, here I got a log file from ide.

It has been in good condition after many suspension-resume sessions. Just now I decided to give it some focus. I moved it from one monitor to another, dragged another window from another monitor to the one ide resided, and on top of ide, keeping mouse down and adjusting its position until I saw a color changing in ide underneath the window I was playing with, signalling possibly negotiating drag-n-drop(?). It successfuly brought down ide. It doesn't always. But it seems this set of actions is dangerous to ide. It breaks under other totally unrelated, unrecorded sequence of actions too.


BTW, please feel free to delete used log files from uppweb to free up resouces. Or maybe I shall do that?

By "brought down" do you mean crash or (the usual) repainting stopped?

If the second one, it starts to look like yet another xwayland bug (assuming you run wayland - I think you do). Log clearly shows that I call gdk_window_invalidate_rect with proper parameters (it is the INVALIDATE word in the log), after which gtk is supposed to call me back and do the repaint (GtkDraw in the log). Log shows the repaint properly happens at the beginning, but then stops doing so near the end of log....

Anyway, I have added even more logging, so please one last time pull logs branch and keep testing...