trafodion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Qifan Chen <qifan.c...@esgyn.com>
Subject Re: SQL compiler debugging on CentOS 7
Date Wed, 13 Jun 2018 14:34:25 GMT
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 <narendra.goyal@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 <dave.birdsall@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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message