RE: kdmsIMCURelease
- From: Noveljic Nenad <nenad.noveljic@xxxxxxxxxxxx>
- To: 'Tanel Poder' <tanel@xxxxxxxxxxxxxx>
- Date: Wed, 10 Jan 2018 09:19:08 +0000
Hi Tanel,
Thank you for geeking into the problem! ☺
I’ll set both IM memory parameters to false. However, the problem appeared just
once and I can’t reproduce it at will. What I can do, is to check with DTrace
whether the execution of kdmsIMCURelease gets suppressed when the parameters
are set to false.
By the way, there are some more details to the problem:
Disass information :
kdmsIMCURelease()+13 (0x23fc95d) push %r15
kdmsIMCURelease()+15 (0x23fc95f) sub $88,%rsp
kdmsIMCURelease()+19 (0x23fc963) mov %rdi,%r13
kdmsIMCURelease()+22 (0x23fc966) mov 0x1c8(%r13),%rbx
kdmsIMCURelease()+29 (0x23fc96d) mov 0x188(%rbx),%r12
kdmsIMCURelease()+36 (0x23fc974) lea 0x28(%rbx),%rdi
kdmsIMCURelease()+40 (0x23fc978) xor %rax,%rax
kdmsIMCURelease()+43 (0x23fc97b) call 0x24275d0
Curiously, the disassembled code is in the trace file.
SIGSEGV was generated while executing the line 29 based on the %rbx register,
which sadly contained an invalid address:
%rbx: 0xff00000000000000
%rbx, in turn, was initialized in the line 22 based on the address stored in
%r13, which contains some PGA address:
%r13: 0xffff80ffbbf30ff8
Hi Andy,
Thank you for taking a look at the problem! I’ll open an SR and send you the
reference.
Best regards,
Nenad
http://nenadnoveljic.com/blog/
Twitter: @NenadNoveljic
From: tanel@xxxxxxxxxx [
mailto:tanel@xxxxxxxxxx] On Behalf Of Tanel Poder
Sent: Mittwoch, 10. Januar 2018 01:41
To: Tanel Poder
Cc: Noveljic Nenad; ORACLE-L (oracle-l@xxxxxxxxxxxxx)
Subject: Re: kdmsIMCURelease
You can also try to set optimizer_inmemory_aware = false as a second parameter
to test, although the crash didn't happen in optimization phase, but later
during the execution (but optimizer's earlier actions do of course affect
execution-time activities later on).
--
Thanks,
Tanel Poder
On Tue, Jan 9, 2018 at 6:26 PM, Tanel Poder
<tanel@xxxxxxxxxxxxxx<
mailto:tanel@xxxxxxxxxxxxxx>> wrote:
Thanks for a good excuse for geeking out ;-)
This stack trace shows that the problem happens during execution phase of your
select statement - selexe(). The QEC in qecrlssub() means something like Query
Execution sql Capability checking.
And I guess you are hitting a bug when finishing a table or partition scan -
qertbRelease() - Oracle tries to release a pin on some in-memory compression
unit that it thinks has been pinned during the scan. Perhaps it thinks that
some IMCU has been "opened" due to the capability check of whether a
table/block region is cached in the IM columnstore. Or something like that
(it's a bug, who knows).
But given that Oracle's trying to do IMCU checks when you don't even have
tables cached in memory - try setting alter session set inmemory_query = false
(it's true by default) and rerun your query, maybe it alters the code path so
it doesn't even hit this buggy codepath.
--
Thanks,
Tanel Poder
P.S. Oh, almost forgot to mention, I'm running my AOT seminar one more time
this year ;-)
http://blog.tanelpoder.com/seminar
____________________________________________________
Please consider the environment before printing this e-mail.
Bitte denken Sie an die Umwelt, bevor Sie dieses E-Mail drucken.
<html xmlns="
http://www.w3.org/1999/xhtml";>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css">p { font-family: Arial;font-size:9pt }</style>
</head>
<body>
<p>
<br>Important Notice</br>
<br>This message is intended only for the individual named. It may contain
confidential or privileged information. If you are not the named addressee you
should in particular not disseminate, distribute, modify or copy this e-mail.
Please notify the sender immediately by e-mail, if you have received this
message by mistake and delete it from your system.</br>
<br>E-mail transmission may not be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete. Also
processing of incoming e-mails cannot be guaranteed. All liability of the
Vontobel Group and its affiliates for any damages resulting from e-mail use is
excluded. You are advised that urgent and time sensitive messages should not be
sent by e-mail and if verification is required please request a printed
version.<br/>
</p>
</body>
</html>
Other related posts:
