RE: kdmsIMCURelease
Date: Wed, 10 Jan 2018 09:19:08 +0000
Message-ID: <25557_1515575954_5A55DA92_25557_15218_1_ECDEF0CC6716EC4596FCBC871F48292AB192EF43_at_ZRH-S231>
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: _at_NenadNoveljic
From: tanel_at_poderc.com [mailto:tanel_at_poderc.com] On Behalf Of Tanel Poder
Sent: Mittwoch, 10. Januar 2018 01:41
To: Tanel Poder
Cc: Noveljic Nenad; ORACLE-L (oracle-l_at_freelists.org)
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_at_tanelpoder.com<mailto:tanel_at_tanelpoder.com>> 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>
-- http://www.freelists.org/webpage/oracle-lReceived on Wed Jan 10 2018 - 10:19:08 CET