FW: SQL compiler debugging on CentOS 7

[Narendra Goyal <na...@esgyn.com>]

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 <da...@esgyn.com>
> Sent: Tuesday, May 29, 2018 10:29 AM
> To: dev@trafodion.apache.org
> 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

Re: SQL compiler debugging on CentOS 7

[Qifan Chen <qi...@esgyn.com>]

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 <na...@esgyn.com>
Sent: Tuesday, June 12, 2018 11:06:33 AM
To: dev@trafodion.apache.org
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 <da...@esgyn.com>
> Sent: Tuesday, May 29, 2018 10:29 AM
> To: dev@trafodion.apache.org
> 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