My understanding is that in our master executor or ESP processes, SIGSEGV may
come from java run-time where de-referencing a pointer (sometime a null
pointer) is common. So theoretically gdb can receive a SIGSEGV anytime when
debug the compiler or executor code.
That pgdb trick works great. Thanks for sharing.
One word of caution is that "handle SIGSEGV nopass" masks out any true
segmentation violation condition: when a null pointer (such as selection_
below) is referenced. One probably should do "p selection_" first to make sure
selection_ is not a null.
Breakpoint 1, Scan::bindNode (this=0x7fffc25119e8, bindWA=0x7ffffffe9340)
at ../optimizer/BindRelExpr.cpp:7868
7868 if (nodeIsBound())
(gdb) pgdb selection_
$1 = (ItemExpr *) 0x7fffc2512af0
(gdb) p selection_->display()
(A = 1)
$2 = void
(gdb) c
Thanks --Qifan
________________________________
From: Narendra Goyal <[email protected]>
Sent: Tuesday, June 12, 2018 11:06:33 AM
To: [email protected]
Subject: FW: SQL compiler debugging on CentOS 7
Not sure why it's happening. Perhaps something to do with some signal handling.
Setting the SIGSEGV handler (in a gdb session) to 'nopass' before doing a 'p
<method>' and resetting it to 'pass' immediately after the call seems to work.
With the following methodology one doesn't have to remember setting/resetting
the handler.
Add the following to ~/.gdbinit:
define pgdb
handle SIGSEGV nopass
p $arg0
handle SIGSEGV pass
end
and then in the gdb session, call:
pgdb <method>
If there are args for the <method>, just need to call <method(arg1,arg2..)>
without spaces.
Thanks,
-Narendra
> -----Original Message-----
> From: Dave Birdsall <[email protected]>
> Sent: Tuesday, May 29, 2018 10:29 AM
> To: [email protected]
> Subject: SQL compiler debugging on CentOS 7
>
> Hi,
>
> I'm doing some debugging in the SQL compiler on a Trafodion instance on
> CentOS 7.
>
> One of the things I commonly do is use the "display()" function in gdb on
> various ItemExpr-related classes. So, at the gdb prompt, I might do "p
> keyList.display()".
>
> This works fine on RedHat instances. But today I tried it for the first time
> on a CentOS 7 instance, and, after showing some output, the function appears
> to go into an infinite loop. Top shows gdb running at close to 100%.
>
> Has anyone else seen this? Does anyone know what the issue is?
>
> Thanks,
>
> Dave
