[Not a bug] Problem debugging 4.1.3 with gdb

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Problem debugging 4.1.3 with gdb

Postby PhysixCat » Fri Jul 05, 2019 11:18 am

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_on_Linux#Debugging. However, it seems that I'm getting stuck after trying to actually run GZDoom in the debugger tool

Code: Select allExpand view
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.
PhysixCat
 
Joined: 15 Jan 2019

Re: Problem debugging 4.1.3 with gdb

Postby Chris » Fri Jul 05, 2019 1:47 pm

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.
User avatar
Chris
 
Joined: 17 Jul 2003

Re: Problem debugging 4.1.3 with gdb

Postby _mental_ » Fri Jul 05, 2019 2:18 pm

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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Problem debugging 4.1.3 with gdb

Postby PhysixCat » Fri Jul 05, 2019 2:43 pm

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 3:06 pm, edited 1 time in total.
PhysixCat
 
Joined: 15 Jan 2019

Re: Problem debugging 4.1.3 with gdb

Postby PhysixCat » Fri Jul 05, 2019 3:06 pm

_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 allExpand view
(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
PhysixCat
 
Joined: 15 Jan 2019

Re: Problem debugging 4.1.3 with gdb

Postby Chris » Fri Jul 05, 2019 4:29 pm

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
Chris
 
Joined: 17 Jul 2003

Re: Problem debugging 4.1.3 with gdb

Postby ketmar » Fri Jul 05, 2019 8:09 pm

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.
ketmar
k8vavoom developer
 
Joined: 01 Oct 2016


Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests