Problem debugging 4.1.3 with gdb

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 a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: Problem debugging 4.1.3 with gdb

Re: Problem debugging 4.1.3 with gdb

by ketmar » Fri Jul 05, 2019 7: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.

Re: Problem debugging 4.1.3 with gdb

by Chris » Fri Jul 05, 2019 3: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.

Re: Problem debugging 4.1.3 with gdb

by PhysixCat » Fri Jul 05, 2019 2: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 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

Re: Problem debugging 4.1.3 with gdb

by PhysixCat » Fri Jul 05, 2019 1: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?

Re: Problem debugging 4.1.3 with gdb

by _mental_ » Fri Jul 05, 2019 1: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.

Re: Problem debugging 4.1.3 with gdb

by Chris » Fri Jul 05, 2019 12: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.

Problem debugging 4.1.3 with gdb

by PhysixCat » Fri Jul 05, 2019 10: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_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.

Top