Linux Render Node - Memory Error during Process2dPostEffects

Started by WAS, November 13, 2019, 07:54:06 PM

Previous topic - Next topic

Matt

The TGD file you attached named "terragen-4-benchmark_v1.0-nobloom.tgd" still has "Bloom" enabled. See the attached screenshot. I hope you won't find it disconcerting when I ask for TGD files, because sometimes they are the only way to be sure about these things.

Can you test with "Bloom" turned OFF to find out if that is where the bug occurs?
Just because milk is white doesn't mean that clouds are made of milk.

WAS

The disconcerting issue is I'm doing all the testing for you, regardless of "bloom" on, or off. From a file hosted on your server. Why haven't you tested this? As a business and developer of the software, you should be far better equipped than I am to diagnose your software. Having to change anything when I alerted you to YOUR benchmark failing on YOUR software.

This could have been sent via PM. But it seems you want it public to try and save-face to EVERY build failing on Ubuntu since 41250 and probably before, that's it's just my fault for blooms sake. if it's that hard to get the info you need you need to do it. Cause oopsies happen. Resolution isn't changed either cause nano had no permission access cause I didn't login as Terragen user.

Fact is in reality; a user makes a report, and YOU do all the testing. Including the hassles of installing the distro. Not having tested your benchmark on a widely standardized distro before shipping to begin with was, well. Wow. Regardless of excuse: "we can't test every distro". No, but you can test widely used ones, especially for compatibilities sake.

41250
Process2dPostEffects...
Process2dPostEffects: done
free(): invalid pointer
Aborted (core dumped)


42200
Process2dPostEffects...
free(): invalid next size (fast)free(): invalid next size (fast)

Aborted (core dumped)


44181
Process2dPostEffects...
Process2dPostEffects: done
corrupted size vs. prev_size
Aborted (core dumped)

44440
Process2dPostEffects...
free(): invalid next size (fast)
Aborted (core dumped)

Regardless of "BLOOM" On or Off, and exactly why you cannot rely on users to test for you, your shit is broken. And yeah how you handle this all as the developer, and business owner, is disconcerting, very disconcerting.

I'll spend another hour and half testing all the builds with file edited form desktop...

WAS

TG 44440 is successfull with Resolution 800x450 and No Antialising Bloom (was enabled in 44440) or post bloom.

I will now try 41250 (lowest in line i have).

Edit: 41250 also finished with no bloom / aa bloom, also finished quicker by a minute, not sure what that's about on Windows latest versions are faster.

I also had my datacenter run memtest86 overnight, and I ran stress this morning and have no issues with my RAM or CPU, but still have issue with TG not utilizing one CPU well.

UPDATE: Nevermind. Failed tests. TG was rendering a blank project again and not warning and aborting about project missing. Ugh. so dumb.

WAS

Alright with an absolute path it rendered, I guess using "../" to backup and head into project folder doesn't work.

It still is rendering with Bloom disabled on 44440

WAS

Lowest, 41250 also renders without bloom.

Also just a note that wow, your new robust AA is far superior to old standard. The difference in noise is crazy between 41250 and 44440 is crazy.

Matt

Thanks for doing those tests. I'll work on it this week.
Just because milk is white doesn't mean that clouds are made of milk.

Matt

This has been reported as fixed in Build 4.4.45 (Release).
Just because milk is white doesn't mean that clouds are made of milk.