Overview
Examples
Screenshots
Comparisons
Applications
Download
Documentation
Tutorials
Bazaar
Status & Roadmap
FAQ
Authors & License
Forums
Funding Ultimate++
Search on this site
Search in forums












SourceForge.net Logo
Home » Community » U++ community news and announcements » 2019.2 rc5
Re: 2019.2 (pre)released [message #52562 is a reply to message #52561] Tue, 22 October 2019 12:42 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Tue, 22 October 2019 12:37

The testcase is logically pretty close to what I'm doing here, so let's focus on that for a while as it crashes very similarly, shall we?

Best regards,

Tom


Definitely, I have not hoped for testcase, that is perfect. Thank you.

Mirek
Re: 2019.2 (pre)released [message #52563 is a reply to message #52558] Tue, 22 October 2019 12:51 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Tue, 22 October 2019 12:51
Tom1 wrote on Tue, 22 October 2019 11:47
They both (ib and bpainter) are actually members of different classes, but both classes are continuously alive throughout the life of the window.

BR,

Tom


Would it be possible to test with temporary ib? Just to get some clues...

Also, obvious reason, is not it possible that bpainter gets used (any method called) between ib being resized and Create called? (As in it would be referencing old data of ImageBuffer).

Is Finish called properly?

Mirek


Temporary ib would change the rendering in a big way as it is my base for getting Paint and Render separated.

While that would be a sensible explanation for what is happening here, I do not think it is possible for bpainter to be used when ib is out-of-order after resizing. As you can see from the testcase, Layout doing ib.Create calls Render doing bpainter.Create(ib) immediately.

Best regards,

Tom
Re: 2019.2 (pre)released [message #52564 is a reply to message #52549] Tue, 22 October 2019 12:55 Go to previous messageGo to next message
Oblivion is currently offline  Oblivion
Messages: 1091
Registered: August 2007
Senior Contributor
Quote:

OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well.

Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags.

https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/

Mirek
https://github.com/clearlinux/clr-installer/pull/545


My workaround was to suppress the message in CtrlCore/Gtk.h
This should be qualified though. IMO the auppression should be disabled in release mode.

#ifdef __GNUC__
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#endif

#include <gtk/gtk.h>
#include <gdk/gdkkeysyms.h>

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif



Best regards,
Oblivion


[Updated on: Tue, 22 October 2019 12:56]

Report message to a moderator

Re: 2019.2 (pre)released [message #52566 is a reply to message #52560] Tue, 22 October 2019 13:51 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Tom1 wrote on Tue, 22 October 2019 12:20
Hi,

Thanks! I will look into your suggestions next.

Meanwhile, here's a "crashable" testcase:


Hopefully fixed - does not crash in trunk anymore.

Can you please check the trunk in your application?

Mirek
Re: 2019.2 (pre)released [message #52569 is a reply to message #52564] Tue, 22 October 2019 14:22 Go to previous messageGo to next message
mirek is currently offline  mirek
Messages: 13975
Registered: November 2005
Ultimate Member
Oblivion wrote on Tue, 22 October 2019 12:55
Quote:

OK, so as we have to investigate issue reported by Tom error anyway, we might try to fix this as well.

Unfortunately, it seems like internal inconsistency of gtk2 dev libraries (AFAIK, I do not even use GTimeVal anywhere). Unfortunately, this error does not happend on any of distros I have available, so it is a bit hard for me to fix, but I guess we should fix it by specifying max gtk2 version somehow, e.g. -DGLIB_VERSION_MAX_ALLOWED=GLIB_VERSION_2_60 in compiler flags or perhaps even before gtk/glib include (that is prefered IMO) or by -Wno-deprecated-warnings in compiler flags.

https://tecnocode.co.uk/2019/08/24/gtimeval-deprecation-in-g lib-2-61-2/

Mirek
https://github.com/clearlinux/clr-installer/pull/545


My workaround was to suppress the message in CtrlCore/Gtk.h
This should be qualified though. IMO the auppression should be disabled in release mode.

#ifdef __GNUC__
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#endif

#include <gtk/gtk.h>
#include <gdk/gdkkeysyms.h>

#ifdef __GNUC__
#pragma GCC diagnostic pop
#endif



Best regards,
Oblivion


Thank you, applied. I am not much worried about release here... This is temporary solution until the next release anyway.
Re: 2019.2 (pre)released [message #52570 is a reply to message #52566] Tue, 22 October 2019 14:33 Go to previous messageGo to next message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
Hi Mirek,

Thanks for your prompt action on this. Now I have already left the office for today, but I will test it as soon as I get back there tomorrow.

Thanks and best regards,

Tom
Re: 2019.2 (pre)released [message #52577 is a reply to message #52566] Wed, 23 October 2019 08:34 Go to previous message
Tom1
Messages: 1212
Registered: March 2007
Senior Contributor
mirek wrote on Tue, 22 October 2019 14:51
Tom1 wrote on Tue, 22 October 2019 12:20
Hi,

Thanks! I will look into your suggestions next.

Meanwhile, here's a "crashable" testcase:


Hopefully fixed - does not crash in trunk anymore.

Can you please check the trunk in your application?

Mirek


Thanks Mirek! The fix works perfectly.

Best regards,

Tom
Previous Topic: 2019.2rc4
Next Topic: 2019.2
Goto Forum:
  


Current Time: Fri Mar 29 07:54:39 CET 2024

Total time taken to generate the page: 0.01691 seconds