hadoop-hdfs-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Haohui Mai (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HDFS-7010) boot up libhdfs3 project
Date Wed, 08 Oct 2014 05:45:34 GMT

    [ https://issues.apache.org/jira/browse/HDFS-7010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14163115#comment-14163115
] 

Haohui Mai commented on HDFS-7010:
----------------------------------

bq. If the different version of libstdc++ is ABI compatible, it should be fine, otherwise,
other troubles like core dump when throw/catch exception will come first before printing the
call stack.

C++ does *not* standardise name mangling, which means that there is no guarantees that mangling
will stay the same. Basically you're making the assumption that the demangler and the library
is compiled by the exact same compiler, in most case this is not true.

bq. From the current experience of using libhdfs3 in our production, if the function is not
inlined, it can be printed in MacOS with CLang, RHEL5/6 with GCC 4.4.2

Did you ever try a more modern compiler that turns on link time optimization? This is turned
on by default by MSVC. You can turn it on with llvm and recent versions of gcc.

Just to reiterate on the previous comments, there are only public symbols available in the
library. I'm skeptical that you can extract enough information without doing it with the full
DWARF information.

bq. Printing the call stack is not only useful for debug, but also for the writing log. If
the customer report an issue with the call stack, it will save a lot of time to find the root
cause. It benefit both developer and users.

Can you just walk the stack and get the function name on your side? As I pointed out earlier,
there won't be enough symbols to get the names.

bq. I know that printing call stack is not a good way to do such work and has bad portability.
Based on the current test and use experience, it does not introduce trouble yet but provide
much benefit. 

My point is that it is very dangerous to depend on compiler-specific behaviors. The mileage
of your statements can vary a lot -- it might work on your laptop, or on some specific deployments.
On other deployments it might not work at all or simply crash the whole program.

Obviously you have way more experience supporting libhdfs3 than any of us, thus I might underappreciate
the debuggability. However, I'm quite concerned that this particular feature will shoot the
developers on their our foot. This is dangerous enough and it raises a clear red flag to me.

My take is to focus on the core features and to exclude this feature for now, at least at
the first release. Maybe we can continue to investigate on follow up jiras once we have more
experience on supporting the library in production environments.

> boot up libhdfs3 project
> ------------------------
>
>                 Key: HDFS-7010
>                 URL: https://issues.apache.org/jira/browse/HDFS-7010
>             Project: Hadoop HDFS
>          Issue Type: Sub-task
>          Components: hdfs-client
>            Reporter: Zhanwei Wang
>            Assignee: Colin Patrick McCabe
>         Attachments: HDFS-7010-pnative.003.patch, HDFS-7010-pnative.004.patch, HDFS-7010-pnative.004.patch,
HDFS-7010.patch
>
>
> boot up libhdfs3 project with CMake, Readme and license file.
> Integrate google mock and google test



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message