Problem debugging 4.1.3 with gdb

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.
Post Reply
User avatar
PhysixCat
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

Problem debugging 4.1.3 with gdb

Post by PhysixCat »

Hello, I compiled the 4.1.3 release with the Debug flag enabled on Debian Sid according to the guide here https://zdoom.org/wiki/Compile_GZDoom_o ... #Debugging. However, it seems that I'm getting stuck after trying to actually run GZDoom in the debugger tool

Code: Select all

ignacio@heim:~/data/gzdoom_build/gzdoom/build$ gdb ./gzdoom
GNU gdb (Debian 8.2.1-2) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./gzdoom...done.
(gdb) set logging on gzdoomdebug.log
Copying output to gzdoomdebug.log.
(gdb) run
Starting program: /home/ignacio/data/gzdoom_build/gzdoom/build/gzdoom
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff513d700 (LWP 9195)]
GZDoom g4.1.3 - 2019-06-08 07:56:19 -0400 - SDL version
Compiled on Jul  5 2019

Thread 2 "gzdoom" received signal SIG33, Real-time event 33.
[Switching to Thread 0x7ffff513d700 (LWP 9195)]
futex_wait_cancelable (private=0, expected=0, futex_word=0x555556de2b60 <renderPool+256>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
88      ../sysdeps/unix/sysv/linux/futex-internal.h: No such file or directory.
(gdb)
As you can see, I'm getting a SIG33, and the program tries to access a file called futex-internal.h that isn't there. I have no experience with debugging at this level, so I wanted to ask here how I could get past this hurdle. The reason I'm trying to get the debugger to work is I'm investigating a strange crash I'm getting with Hideous Destructor that doesn't seem to affect other users.
User avatar
Chris
Posts: 2940
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Problem debugging 4.1.3 with gdb

Post by Chris »

Run 'c' (or 'continue') to continue execution. This is GZDoom (more likely one of its libs) receiving a real-time event signal from somewhere telling it to do something or that something is done, though I can't say I've seen gdb stop execution on them before. It trying to access futex-internal.h is just it trying to show the actual line of code it got the signal on, but it's part of a system lib you don't have the source available for.
_mental_
 
 
Posts: 3812
Joined: Sun Aug 07, 2011 4:32 am

Re: Problem debugging 4.1.3 with gdb

Post by _mental_ »

Without a backtrace such reports are mostly useless. Please do bt command in GDB and post its output.
Personally, I never encountered this issue with many Linux distros I was using.
User avatar
PhysixCat
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

Re: Problem debugging 4.1.3 with gdb

Post by PhysixCat »

Run 'c' (or 'continue') to continue execution. This is GZDoom (more likely one of its libs) receiving a real-time event signal from somewhere telling it to do something or that something is done, though I can't say I've seen gdb stop execution on them before. It trying to access futex-internal.h is just it trying to show the actual line of code it got the signal on, but it's part of a system lib you don't have the source available for.
Thank you Chris, I was afraid ignoring it might cause issues with the debugging itself. So there's no harm in lacking that lib?
Last edited by PhysixCat on Fri Jul 05, 2019 2:06 pm, edited 1 time in total.
User avatar
PhysixCat
Posts: 43
Joined: Tue Jan 15, 2019 11:14 am

Re: Problem debugging 4.1.3 with gdb

Post by PhysixCat »

_mental_ wrote:Without a backtrace such reports are mostly useless. Please do bt command in GDB and post its output.
Personally, I never encountered this issue with many Linux distros I was using.
Here is the backtrace

Code: Select all

(gdb) bt
#0  futex_wait_cancelable (private=0, expected=0, futex_word=0x555556de2b60 <renderPool+256>) at ../sysdeps/unix/sysv/linux/futex-internal.h:88
#1  __pthread_cond_wait_common (abstime=0x0, mutex=0x555556de2b10 <renderPool+176>, cond=0x555556de2b38 <renderPool+216>) at pthread_cond_wait.c:502
#2  __pthread_cond_wait (cond=0x555556de2b38 <renderPool+216>, mutex=0x555556de2b10 <renderPool+176>) at pthread_cond_wait.c:655
#3  0x00007ffff78e13bc in std::condition_variable::wait(std::unique_lock<std::mutex>&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x0000555555fd6ea9 in std::condition_variable::wait<ctpl::thread_pool::set_thread(int)::{lambda()#1}::operator()() const::{lambda()#1}>(std::unique_lock<std::mutex>&, ctpl::thread_pool::set_thread(int)::{lambda()#1}::operator()() const::{lambda()#1}) (this=0x555556de2b38 <renderPool+216>, __lock=..., __p=...)
    at /usr/include/c++/8/condition_variable:99
#5  0x0000555555fd591e in ctpl::thread_pool::set_thread(int)::{lambda()#1}::operator()() const (__closure=0x555557b0b178)
    at /home/ignacio/data/gzdoom_build/gzdoom/src/utility/ctpl.h:227
#6  0x0000555555fd858f in std::__invoke_impl<void, ctpl::thread_pool::set_thread(int)::{lambda()#1}>(std::__invoke_other, ctpl::thread_pool::set_thread(int)::{lambda()#1}&&)
    (__f=...) at /usr/include/c++/8/bits/invoke.h:60
#7  0x0000555555fd6f3e in std::__invoke<ctpl::thread_pool::set_thread(int)::{lambda()#1}>(std::__invoke_result&&, (ctpl::thread_pool::set_thread(int)::{lambda()#1}&&)...) (
    __fn=...) at /usr/include/c++/8/bits/invoke.h:95
#8  0x0000555555fdca94 in std::thread::_Invoker<std::tuple<ctpl::thread_pool::set_thread(int)::{lambda()#1}> >::_M_invoke<0ul>(std::_Index_tuple<0ul>) (this=0x555557b0b178)
    at /usr/include/c++/8/thread:244
#9  0x0000555555fdca10 in std::thread::_Invoker<std::tuple<ctpl::thread_pool::set_thread(int)::{lambda()#1}> >::operator()() (this=0x555557b0b178)
    at /usr/include/c++/8/thread:253
#10 0x0000555555fdc966 in std::thread::_State_impl<std::thread::_Invoker<std::tuple<ctpl::thread_pool::set_thread(int)::{lambda()#1}> > >::_M_run() (this=0x555557b0b170)
    at /usr/include/c++/8/thread:196
#11 0x00007ffff78e6b2f in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#12 0x00007ffff7643fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#13 0x00007ffff75744cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
User avatar
Chris
Posts: 2940
Joined: Thu Jul 17, 2003 12:07 am
Graphics Processor: ATI/AMD with Vulkan/Metal Support

Re: Problem debugging 4.1.3 with gdb

Post by Chris »

PhysixCat wrote:Thank you Chris, I was afraid ignoring it might cause issues with the debugging itself. So there's no harm in lacking that lib?
For SIG33 (and similar), it's fine to continue past. It's things like SIGSEGV or SIGILL or SIGBUS that you want to watch for. There's not usually any harm in lacking the source for those libs, unless there's a problem in those libs you need to track down. Generally it's GZDoom's code that's more important, what it's doing when calling certain functions that causes a crash.
User avatar
ketmar
Posts: 160
Joined: Sat Oct 01, 2016 6:26 am
Contact:

Re: Problem debugging 4.1.3 with gdb

Post by ketmar »

yeah, it is mostly safe to ignore such signals. you can put this into your "~/.gdbinit" (create one if it is not here):

handle SIG33 noprint pass

and gdb won't bother you with it anymore.
Post Reply

Return to “Closed Bugs [GZDoom]”