Partially discolored or black sky

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
dpJudas
 
 
Posts: 2861
Joined: Sat May 28, 2016 1:01 pm

Re: Partially discolored or black sky

Post by dpJudas »

Hmm that sure looks weird! How does it look like on this branch?
Blzut3
 
 
Posts: 3090
Joined: Wed Nov 24, 2004 12:59 pm
Github ID: Blzut3
Graphics Processor: ATI/AMD with Vulkan Support

Re: Partially discolored or black sky

Post by Blzut3 »

Works fine on that branch.
dpJudas
 
 
Posts: 2861
Joined: Sat May 28, 2016 1:01 pm

Re: Partially discolored or black sky

Post by dpJudas »

Excellent. I'll PR that branch once I've disabled the ray query stuff on it (nvidia crashes with that on a driver worker thread with a null pointer exception - thanks nvidia!). It contains a much newer version of the backend.
User avatar
Chris
Posts: 2841
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan Support

Re: Partially discolored or black sky

Post by Chris »

Moved back to Bugs since it's certainly not fixed yet, and is waiting on a PR.
User avatar
Chris
Posts: 2841
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan Support

Re: Partially discolored or black sky

Post by Chris »

The PR for this was recently merged, however now it's crashing on load, after the window is created but before the title screen or anything comes up. It does not crash in Debug mode (and everything including the sky looks correct), but RelWithDebInfo results in the attached crash log, Seems there's some stack smashing going on, given the backtrace:

Code: Select all

Thread 1 (Thread 0x7f28668ba440 (LWP 122804) "gzdoom"):
#0  0x00007f2867aeda67 in __GI___wait4 (pid=pid@entry=122840, stat_loc=stat_loc@entry=0x562bde157e74 <altstack+6804>, options=options@entry=0, usage=usage@entry=0x0) at ../sysdeps/unix/sysv/linux/wait4.c:30
No locals.
#1  0x00007f2867aed9e7 in __GI___waitpid (pid=pid@entry=122840, stat_loc=stat_loc@entry=0x562bde157e74 <altstack+6804>, options=options@entry=0) at waitpid.c:38
No locals.
#2  0x0000562bdd80b47c in crash_catcher (signum=11, siginfo=<optimized out>, context=<optimized out>) at /home/kitty/projects/gzdoom/src/common/platform/posix/sdl/crashcatcher.c:248
        status = 0
        dbg_pid = 122840
        fd = {49, 50}
#3  <signal handler called>
No locals.
#4  0x0000562bdd7d871b in VulkanImage::~VulkanImage (this=0x1100100000001, __in_chrg=<optimized out>) at /home/kitty/projects/gzdoom/src/common/rendering/vulkan/system/vk_objects.h:1063
No locals.
#5  std::default_delete<VulkanImage>::operator() (__ptr=0x1100100000001, this=<optimized out>) at /usr/include/c++/11/bits/unique_ptr.h:85
No locals.
#6  0x0000562bdd7d87f8 in std::default_delete<VulkanImage>::operator() (__ptr=<optimized out>, this=<optimized out>) at /usr/include/c++/11/bits/unique_ptr.h:79
No locals.
#7  std::unique_ptr<VulkanImage, std::default_delete<VulkanImage> >::~unique_ptr (this=0x562be5e9edb0, __in_chrg=<optimized out>) at /usr/include/c++/11/bits/unique_ptr.h:361
        __ptr = @0x562be5e9edb0: 0x1100100000001
#8  ImageBuilder::Create (this=<optimized out>, device=<optimized out>, allocatedBytes=<optimized out>) at /home/kitty/projects/gzdoom/src/common/rendering/vulkan/system/vk_builders.cpp:365
        image = 0x562be6809670
        allocation = 0x10101e0
        result = <optimized out>
        obj = std::unique_ptr<VulkanImage> = {get() = 0x1100100000001}
#9  0x0000000000000000 in ?? ()
No symbol table info available.
I've seen other random values for those final __ptrs and thiss, including 0x1.

EDIT:
I think I found it:

Code: Select all

/home/kitty/projects/gzdoom/src/common/rendering/vulkan/system/vk_builders.cpp: In member function ‘GraphicsPipelineBuilder& GraphicsPipelineBuilder::BlendMode(const FRenderStyle&)’:
/home/kitty/projects/gzdoom/src/common/rendering/vulkan/system/vk_builders.cpp:263:18: warning: control reaches end of non-void function [-Wreturn-type]
  263 |         BlendMode((VkBlendOp)blendequation, (VkBlendFactor)srcblend, (VkBlendFactor)dstblend);
      |         ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The function is missing a return at the end. If I add return *this;, it stops crashing.
You do not have the required permissions to view the files attached to this post.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Partially discolored or black sky

Post by Graf Zahl »

fixed that.
dpJudas
 
 
Posts: 2861
Joined: Sat May 28, 2016 1:01 pm

Re: Partially discolored or black sky

Post by dpJudas »

Really puzzled why something like this isn't considered a compile error in C++
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 47995
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: Partially discolored or black sky

Post by Graf Zahl »

Old C baggage. :?
User avatar
Chris
Posts: 2841
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan Support

Re: Partially discolored or black sky

Post by Chris »

So far so good, at least. No crashes, and the sky hasn't been discolored after running it a few separate times. It was an intermittent issue, so I can't say for 100% definite it's not a problem anymore, but I'm feeling confident after a few runs and a couple rebuilds, it hasn't occurred again.
User avatar
Chris
Posts: 2841
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan Support

Re: Partially discolored or black sky

Post by Chris »

I think it's safe to say this has been fixed now.

Return to “Closed Bugs”