[
https://issues.apache.org/jira/browse/TRAFODION-2495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880992#comment-15880992
]
ASF GitHub Bot commented on TRAFODION-2495:
-------------------------------------------
Github user sureshsubbiah commented on a diff in the pull request:
https://github.com/apache/incubator-trafodion/pull/977#discussion_r102784331
--- Diff: core/sql/optimizer/NATable.cpp ---
@@ -5481,7 +5481,9 @@ NABoolean createNAFileSets(TrafDesc * table_desc
/*IN*/,
if(postCreateNATableWarnings != preCreateNATableWarnings)
tableConstructionHadWarnings_=TRUE;
- const char *lobHdfsServer = CmpCommon::getDefaultString(LOB_HDFS_SERVER);
+ char lobHdfsServer[256] ; // max length determined by
dfs.namenode.fs-limits.max-component-length(255)
+ memset(lobHdfsServer,0,256);
+ strncpy(lobHdfsServer,CmpCommon::getDefaultString(LOB_HDFS_SERVER),
strlen(CmpCommon::getDefaultString(LOB_HDFS_SERVER)));
--- End diff --
The comment in the next file tells us that there is expectation the max
valid string length will be 255 bytes for this attribute. However with user
error there could be a longer invalid string. Maybe some error handling code
that checks if the specifies string is less that 255 bytes will address the
concern above.
I do have another question.
We are passing a pointer to a local variable (lobHdfsSever) to the CLI call
SQL_EXEC_LobddlInterface(). Is there a guarantee that this call will NOT save
the pointer somewhere that could cause the pointer to be accessed after the
call has returned. I suppose I am not clear on changing the storage of this
actual data from system heap used by NAString (old code) to stack used by newly
created char array will avoid the corruption problem. I am often confused by
such question, so consider this a question, rather than a issue to be resolved.
> HDFS connection issue during LOB creation
> -----------------------------------------
>
> Key: TRAFODION-2495
> URL: https://issues.apache.org/jira/browse/TRAFODION-2495
> Project: Apache Trafodion
> Issue Type: Bug
> Components: sql-exe
> Affects Versions: any
> Reporter: Sandhya Sundaresan
> Assignee: Sandhya Sundaresan
> Fix For: 2.2-incubating
>
>
> In some cases a memory overwrite of the following local variable would cause
> a bad value for hdfsServer to be passed into the LOB interface causing an
> Hdfs error. This was seen intermittently and not always reproducible. The
> code clearly did assume that memory it hadn't allocated would nto be reused
> and that's dangerous. lobHdfsServer needs it's own memory allocated on the
> stack or a heap. If not the ComString newSchName could potentially overwrite
> the memory returned by the call to
> CmpCommon::getDefaultString(LOB_HDFS_SERVER) before gttting passed to the LOB
> interface.
> ----------------------
> const char *lobHdfsServer = CmpCommon::getDefaultString(LOB_HDFS_SERVER);
> Int32 lobHdfsPort = (Lng32)CmpCommon::getDefaultNumeric(LOB_HDFS_PORT);
>
> if (j > 0)
> {
> Int32 rc = sendAllControls(FALSE, FALSE, TRUE);
> //if the table is a volatile table return an error
> if (createTableNode->isVolatile())
> {
> *CmpCommon::diags()
> << DgSqlCode(-CAT_LOB_COLUMN_IN_VOLATILE_TABLE)
> << DgTableName(extTableName);
>
> deallocEHI(ehi);
> processReturn();
> return -1;
> }
> Int64 objUID = getObjectUID(&cliInterface,
> catalogNamePart.data(),
> schemaNamePart.data(),
> objectNamePart.data(),
> COM_BASE_TABLE_OBJECT_LIT);
>
> ComString newSchName = "\"";
> newSchName += catalogNamePart;
> newSchName.append("\".\"");
> newSchName.append(schemaNamePart);
> newSchName += "\"";
> NABoolean lobTrace=FALSE;
> if (getenv("TRACE_LOB_ACTIONS"))
> lobTrace=TRUE;
> rc = SQL_EXEC_LOBddlInterface((char*)newSchName.data(),
> newSchName.length(),
> objUID,
> j,
> LOB_CLI_CREATE,
> lobNumList,
> lobTypList,
> lobLocList,
> (char *)lobHdfsServer,
> lobHdfsPort,
> lobMaxSize,
> lobTrace);
>
> if (rc < 0)
> {
> //sss TBD need to retrive the cli diags here.
> *CmpCommon::diags() << DgSqlCode(-CAT_CREATE_OBJECT_ERROR)
> << DgTableName(extTableName);
> deallocEHI(ehi);
> processReturn();
>
> return -2;
> }
> }
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
