[
https://issues.apache.org/jira/browse/TRAFODION-2888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16317163#comment-16317163
]
ASF GitHub Bot commented on TRAFODION-2888:
-------------------------------------------
Github user asfgit closed the pull request at:
https://github.com/apache/trafodion/pull/1376
> Streamline setjmp/longjmp concepts in Trafodion
> -----------------------------------------------
>
> Key: TRAFODION-2888
> URL: https://issues.apache.org/jira/browse/TRAFODION-2888
> Project: Apache Trafodion
> Issue Type: Improvement
> Components: sql-general
> Reporter: Selvaganesan Govindarajan
> Assignee: Selvaganesan Govindarajan
> Fix For: 2.3
>
>
> I happened to come across a core dump with longjmp in executor layer that
> brought down the node. Unfortunately, the core dump wasn’t useful to figure
> out what was the root cause for the longjmp. Hence,
> a) I wonder is there a way to figure out what caused longjmp from the core?
> b) If no, why do longjmp? It might be better to let it dump naturally by
> accessing the invalid address or null pointer right at the point of failure.
> Was longjmp put in place in legacy Trafodion code base to avoid node being
> brought down when the privilege code gets into segment violation?
> If a) is not possible, I would want to remove the remnants of setjmp and
> longjmp from the code to enable us to debug the issue better.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
