[
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)
