OpenMW 0.43.0

Anything related to PR, release planning and any other non-technical idea how to move the project forward should be discussed here.
User avatar
raevol
Posts: 3067
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OpenMW 0.43.0

Post by raevol » 17 Nov 2017, 09:03

Atahualpa wrote:
16 Nov 2017, 22:14
Sorry, RL kept me from working on the videos recently. The WIP engine video should be ready by Saturday; the editor video on Sunday.
No worries!! Sounds good!

User avatar
psi29a
Posts: 4803
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.43.0

Post by psi29a » 17 Nov 2017, 09:33

Do we have a tag? Once tagged, I can get busy with Debian and Ubuntu and fix our PPA woes....

You can keep it as 'draft' mode on github so that only github members see it or those following git development.

User avatar
raevol
Posts: 3067
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OpenMW 0.43.0

Post by raevol » 17 Nov 2017, 22:47

psi29a wrote:
17 Nov 2017, 09:33
Do we have a tag? Once tagged, I can get busy with Debian and Ubuntu and fix our PPA woes....
Is that ok to go ahead and do? I don't know enough about the system, is everyone ok if I apply the tag early?

User avatar
Grilly
Posts: 36
Joined: 14 Feb 2016, 05:00

Re: OpenMW 0.43.0

Post by Grilly » 18 Nov 2017, 07:28

Further testing on the Linux RC, it seems like the engine stutters and hangs up more and more frequently the longer I play and the more places I visit. Eventually, it even goes gray. I was assuming it was dues to optimizations but maybe it's not handling memory very well.

User avatar
Ace (SWE)
Posts: 843
Joined: 15 Aug 2011, 14:56

Re: OpenMW 0.43.0

Post by Ace (SWE) » 18 Nov 2017, 09:21

A problem with applying the tag in advance is that the moment the tag is applied, any maintainers outside of our team are going to start instantly rolling up release packages. So we might end up released early on those distros.

User avatar
raevol
Posts: 3067
Joined: 07 Aug 2011, 01:12
Location: Caldera

Re: OpenMW 0.43.0

Post by raevol » 18 Nov 2017, 09:25

Grilly wrote:
18 Nov 2017, 07:28
Further testing on the Linux RC, it seems like the engine stutters and hangs up more and more frequently the longer I play and the more places I visit. Eventually, it even goes gray. I was assuming it was dues to optimizations but maybe it's not handling memory very well.
Is anyone else noticing this? This was definitely not an issue on previous versions, I played for many many hours with no slowdown.
Ace (SWE) wrote:
18 Nov 2017, 09:21
So we might end up released early on those distros.
That's what I was worried about...

User avatar
drummyfish
Posts: 154
Joined: 22 Oct 2017, 10:13
Contact:

Re: OpenMW 0.43.0

Post by drummyfish » 18 Nov 2017, 11:54

raevol wrote:
18 Nov 2017, 09:25
Is anyone else noticing this? This was definitely not an issue on previous versions, I played for many many hours with no slowdown.
I tried running 0.43 branch with valgrind to detect memory leaks, but it crashes right at start with

Code: Select all

*** Fatal Error ***
==6351== Syscall param execve(filename) points to uninitialised byte(s)
==6351==    at 0xACC8777: execve (syscall-template.S:84)
==6351==    by 0xACC8B49: execl (execl.c:67)
==6351==    by 0x1641AFD: crash_catcher(int, siginfo_t*, void*) (crashcatcher.cpp:259)
==6351==    by 0x947F38F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
==6351==    by 0x4058EF2: ??? (in /tmp/.glYbJvaU (deleted))
==6351==  Address 0x1eb84c0 is 0 bytes inside data symbol "_ZL5argv0"
==6351== 
==6351== Syscall param execve(argv[i]) points to uninitialised byte(s)
==6351==    at 0xACC8777: execve (syscall-template.S:84)
==6351==    by 0xACC8B49: execl (execl.c:67)
==6351==    by 0x1641AFD: crash_catcher(int, siginfo_t*, void*) (crashcatcher.cpp:259)
==6351==    by 0x947F38F: ??? (in /lib/x86_64-linux-gnu/libpthread-2.23.so)
==6351==    by 0x4058EF2: ??? (in /tmp/.glYbJvaU (deleted))
==6351==  Address 0x1eb84c0 is 0 bytes inside data symbol "_ZL5argv0"
==6351== 
Address not mapped to object (signal 11)
Address: 0x2a039e00
Do we know about this happening?

User avatar
psi29a
Posts: 4803
Joined: 29 Sep 2011, 10:13
Location: Belgium
Gitlab profile: https://gitlab.com/psi29a/
Contact:

Re: OpenMW 0.43.0

Post by psi29a » 18 Nov 2017, 14:40

Ace (SWE) wrote:
18 Nov 2017, 09:21
A problem with applying the tag in advance is that the moment the tag is applied, any maintainers outside of our team are going to start instantly rolling up release packages. So we might end up released early on those distros.
That's me... ;)

User avatar
Ace (SWE)
Posts: 843
Joined: 15 Aug 2011, 14:56

Re: OpenMW 0.43.0

Post by Ace (SWE) » 18 Nov 2017, 14:45

psi29a wrote:
18 Nov 2017, 14:40
Ace (SWE) wrote:
18 Nov 2017, 09:21
A problem with applying the tag in advance is that the moment the tag is applied, any maintainers outside of our team are going to start instantly rolling up release packages. So we might end up released early on those distros.
That's me... ;)
Well, yes. But we'll also end up released on Arch, Gentoo, OpenSUSE, Fedora, etc. And I'm most definitely going to push the one letter change that'll release on flatpak as soon as possible as well ;)

Chocolatey won't allow me to publish the build until after the news post is up though, so Windows will stay on point.

User avatar
drummyfish
Posts: 154
Joined: 22 Oct 2017, 10:13
Contact:

Re: OpenMW 0.43.0

Post by drummyfish » 18 Nov 2017, 17:45

Now valgrind runs somehow and detects some leaks (after simply starting and closing the game):

Code: Select all

==20413== HEAP SUMMARY:
==20413==     in use at exit: 164,689 bytes in 664 blocks
==20413==   total heap usage: 6,238,442 allocs, 6,237,778 frees, 10,703,774,455 bytes allocated
==20413== 
==20413== LEAK SUMMARY:
==20413==    definitely lost: 8,496 bytes in 5 blocks
==20413==    indirectly lost: 39 bytes in 2 blocks
==20413==      possibly lost: 0 bytes in 0 blocks
==20413==    still reachable: 156,154 bytes in 657 blocks
==20413==         suppressed: 0 bytes in 0 blocks
==20413== Rerun with --leak-check=full to see details of leaked memory
==20413== 
==20413== For counts of detected and suppressed errors, rerun with: -v
==20413== Use --track-origins=yes to see where uninitialised values come from
==20413== ERROR SUMMARY: 39 errors from 7 contexts (suppressed: 0 from 0)
EDIT: Most of it is SDL and similar stuff, only found one small leak in OpenMW: https://github.com/OpenMW/openmw/blob/m ... p.cpp#L379.

Post Reply