foam-extend-3.1 Merge Request #67: Reimplementation of printStack (open)

1. Reimplemented printStack using direct dladdr call instead of parsing backtrace_symbols output.
2. (OS X) Added ability to select utility used for address resolution.
3. Removed unused pieces of code.

[Bernhard Gschaider]

In principle this sounds interesting.

Two remarks:
a) can't review it because there are 0 commits in the merge request (not in charge of merging anyhow)
b) would recommend postponing this merge till after the release as this has the POTENTIAL to blow up in unforseen ways (so merge after the release)

[Alexey Matveichev]

Since both merge requests are of new feature type, they are surely can be postponed.

"0 commits" is a feature of SourceForge. Patch that consists of two merge requests can be found on github - https://github.com/mrklein/openfoam-os-x/blob/master/foam-extend-3.1.patch

[Hrvoje Jasak]

Hi Alexey,

I'd like a word re printStack: can you give me some info on why you needed to do this. It looks like competent code and all looks fine, so all I need is a bit of background.

Regarding the CLang port, I have hit the same problem with the Mac; I can see why this works, but it also seems to me to be a bug in the compiler. The specialisation is correctly declared/defined and visible from the fvMatrix.C Furthermore, there are other places with the same pattern (eg. linearElastic.C) where it works fine.

Any comments?

Hrv

[Bernhard Gschaider]

Regarding the printStack. I see the point on the Mac. It is unreliable. Sometimes it fails and it seems to me that this is a timing-probelm. First the printStack works. Then when I rerun in it it fails in the middle of the dump:

During the creation of the MacPatch for OF 2.4 I tried this solution

 void Foam::error::printStack(Ostream& os)
 {
#ifdef darwin
    {
        OStringStream cmd;
        cmd << "lldb -p " << pid() << " -o bt -o 'f 7' -o quit";
        FILE *cmdPipe = popen(cmd.str().c_str(), "r");
        if(cmdPipe) {
            os << endl << "Output of " << cmd.str() << endl << endl;

            char *buf = NULL;

            label cnt=0;

            while(1) {
                size_t linecap = 0;
                ssize_t linelen;
                linelen = getline(&buf, &linecap, cmdPipe);
                if(linelen<0) {
                    // EOF does not work as an indicator
                    cnt++;
                    if(cnt>3) {
                        break;
                    }
                } else {
                    os << string(buf).c_str() << flush;
                }

            }
            if (buf != NULL)
            {
                free(buf);
            }
            pclose(cmdPipe);

            os << endl << "Regular printStack" << endl;
        }
    }
#endif

This basically lets the system-debugger do the complete stack-trace. That is currently running very reliable for me and the stack-traces are much better (for Debug-versions I get the source-lines with the actual failure)

I havn't recommended this for extend yet as I
a) didn't have time to look at Alexys solution
b) I'd like to try to generalize that so that on Linux gdb would be used

[Alexey Matveichev]

Hi,

Concerning printStack reimplementation. It has been started during creation of OS X patch for OpenFOAM 2.3.x. I was unhappy about a) execution of Python script, b) backtrace_symbols strings format was different for glibc (Linux) and libc (OS X). So I have tried to write solution that does not depend on string parsing and Python script. Also in current implementation printStack does this: call backtrace_symbols (this function will call dladdr to get address, do certain pointer arithmetics to get address, produce string with snprintf), parse strings from backtrace_symbols to get address, call addr2line (or addr2line4Mac.py) to resolve source file and line number. This is rather redundant. Implementation that I propose directly uses dladdr to get image name and address; and then uses acquired information to resolve method name and line (in general lldb do better job than atos, latter is better for dynamic libraries). Additional intention was to get rid of Python script call, that in fact only uses regular expressions, since we can use regular expressions directly from C++. Do not know if it is relevant, stripped-down Linux-only patch was accepted in OpenFOAM 2.4.0, this merge request is original OS X version.

Regarding Apple's clang port. Maybe I am missing something but fvMatrix.C code uses zeroGradientFvPatchScalarField::typeName while zeroGradientFvPatchFields.H does not define this property. This leads to "implicit instantiation" (hence the error) of zeroGradientFvPatchField template with scalar type, and then zeroGradientFvPatchFields.C tries to explicitly specialize template. As a reference I can provide http://stackoverflow.com/questions/7774188/explicit-specialization-after-instantiation, since the solution provided there helped.