[gschaider]

At first: congratulations to the stack-trace in the new version. It is really a big help.
The only problem I have is that the demangling only seems to be implemented for classes/functions that reside in so-Libraries, not for classes/functions that are in the executable. Like this example-stack-trace (OK. In this example I can deduce it from the first metho in the Libraries, but for other examples it's not that simple and it would be nice to know who called whom):

Foam::error::printStack(Foam:stream&)
Foam::error::abort()
Foam::operator+(Foam::dimensionSet const&, Foam::dimensionSet const&)
Foam::tmp<foam::geometricfield<double,> > Foam::operator+<double,>(Foam::tmp<foam::geometric field<double,> > const&, Foam::tmp<foam::geometricfield<double,> > const&)
mySpecialFoam [0x80c551b]
mySpecialFoam [0x805b769]
__libc_start_main
__gxx_personality_v0
Aborted

I havn't changed compiler switches from the distribution (plus I noticed it's also the case for the distributed applications).

So my question: is this something that can't be done with this backtrace mechanisms (maybe because the dynamic libraries need the symbols anyway for rebinding but the applications don't) or can the desired behaviour be achived by compiler-switches (or similar)

[mattijs]

Good question! (as in I have no idea) We just picked that piece of code up from the web.

If you come up with a better way please let me know. Also it would be great if you see an easy way to get filenames and linenumbers in there!

[gschaider]

My previous experiments showed, that the backtrace_symbols only returns the information about the executable and the address.

If the executable was compiled with Debug symbols the utility addr2line returns the file and the line number (given the executable and the address). In http://gcc.gnu.org/ml/gcc/2004-06/msg01861.html it is suggested to reimplement the functionality of addr2line (I'll have a look at that, when I have time, but for my current-problem it's sufficient to do it by hand)

[gschaider]

OK. I now have a version of error.C that
- supports function/method-names in the applications
- source-file and line number for stuff compiled with debug (not in libraries, don't know if that is possible)

The additional stuff is implemented by calling the addr2line-application via the popen-system call. This means that the binutils have to be installed. I know that calling an external application is an additional point of failure, but reimplementing the functionality by stealing code from the sources addr2link and objdump would have meant that the bdf-library had to be linked to all executables (creating an additional dependency). And it would have been more work ;-)

I also changed the #ifdef in such a way that the demangling-code is only compiled on platforms where it is known to work (Linux-i386 and AMD64)

error.C

Given that there have been a lot of people (including me) having compilation difficulties with the demangling code even on Linux-i386 due to not having the correct binutils libraries installed, I would actually suggest changing the #ifdef to use an environment variable that's defined in the bashrc files, so that one can easily turn it off on a particular system without mucking about in the source code.

That would also move the logic for when the demangling is activated off to the same place as all the other system-dependent switches (e.g., the switches for the various MPI implementations).

[mbeaudoin]

I aggree that as specified in the new error.C file, the line "#if defined(__linux__) && (defined(__i386__) || defined(__x86_64__))" on a RedHat x86 system would still enable the HAS_DEMANGLING pre-processor constant and you are still stuck with the demangle.h problem.

But you can't disable the following pre-processor statement:

#include <demangle.h>

by simply using environment variables. This is a compilation issue, not a runtime issue.

So in my opinion, using conditional compilation is still the best way to de-activate the demangling code in error.C, but by specifying the conditional compilation constant "HAS_DEMANGLING" in the "options" file for the library libOpenFOAM.

On the other hand, do we really want to deactivate the new demangling capabilities from OpenFOAM?

Yeah, on second thought I mostly agree with you. I didn't think that all the way through -- I forgot that one couldn't directly check an environment variable in a #ifdef statement, but that it has to go through a conditional compilation constant. I also forgot that this was all in error.C rather than in a .H file, and thus that the only time it's compiled is when libOpenFOAM is compiled; I was thinking that the constant would need to be specified for all of the (quite a lot of) libraries that include files out of the OpenFOAM source tree.

I think it still might be useful to relate the -DHAS_DEMANGLE line in OpenFOAM/make/options back to an environment variable set in the part of bashrc that's doing all the other system and compiler checks, though.

Personally, as for your last question: Sometimes, yes, I do want to. I've been testing out source code changes on a machine that doesn't have demangle.h, and installing it properly looks like more of a hassle than simply deactivating that part of OpenFOAM. But maybe that's just me. I certainly wouldn't want to have it deactivated in the pre-compiled distribution.

(I should make clear, though, that aside from the cases where I'm testing out compilations, I think the feature is definitely a useful thing, and I'm quite appreciative of the effort put into including it.)

[gschaider]

@deactivating demangling: Yes, I want to deactivate it when I compile OF on my Mac. And I havn't found something similar to demangle.h there (not that I was looking too hard, if somebody knows something, give me a shout).

The #ifdef guard was just a quick-shot. But to add an alternative (apart from environment variables and compiler switches): I'd prefer a central include file (for instance machineFeatures.h) where such preprocessor symbols can be centrally edited by the local "Foam-admin" (and I think there are going to be more problems like the demangle.h-thing discussed in the Suse 9.1-tread when OpenFOAM spreads and nobody can/wants to think about these minor differences (for instance RedHat vs Suse) in the vanilla distribution. I mean having separate wmake/rules for Suse and RedHat just because of a missing header ....)

[gschaider]

I have added correct demangling for the Libraries. The problems were the offsets of the .so, I now get them from the /proc/<pid>/maps-file. That way I would be pleasently surprised if it works on any other platform than Linux (and I have only tested it on 2.6-Kernels (i386 and AMD), it may work on 2.4, I'm not sure about 2.8 ;-) )

error.C

I think the functionality is complete. The form of the output is negotiable. The form of the source needs improvement.

[mattijs]

Thanks, will try it. Sounds pleasantly dodgy - reading /proc/ ;-)

[mattijs]

Hi Bernhard,

going through above error.C. Is that version the latest? What is all that /proc/maps reading for? Does it work? Anywhere I can read something about this?

[gschaider]

Hi Mattijs!

Latest Version: I think so, but I'm not sure (I'll send you the file I'm currently using by separate mail)

The /proc/pid/map reading solves the following problem with debug symbols in .so-filess: the addresses that are reported by the stackdump are the real addresses. In the so file itself all addresses are relative to the start of the .so. When the .so gets loaded it is assigned an offset and all addresses in the so are recalculated with that offset (the "real" addresses). The offsets of the .sos are in the maps files. Subtracting this offset from the real address obviously gives the relative address in the so and with that address addr2line gives us the symbol name for that address. Without the recalculation of the addresses I wouldn't get the debug-symbol.

The exact process of dynamic linking I don't have a reference handy (the information above is what I remembered).

[hjasak]

Well, I've been using this for at least a couple of weeks and there are no problems. I have added a little strategically placed:


if (!env("FOAM_ABORT"))
{
return;

}

This avoids the code bitching at me if I don't have FOAM_ABORT set up, which makes it look much more graceful...

Apart from that (and a bit of formatting) all is well.

Hrv