CFD Online Logo CFD Online URL
www.cfd-online.com
[Sponsors]
Home > Forums > OpenFOAM

Stack trace for applications

Register Blogs Members List Search Today's Posts Mark Forums Read

Reply
 
LinkBack Thread Tools Display Modes
Old   April 13, 2006, 07:53
Default At first: congratulations to t
  #1
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
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)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 14, 2006, 05:29
Default Good question! (as in I have n
  #2
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
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!
mattijs is offline   Reply With Quote

Old   April 18, 2006, 07:05
Default My previous experiments showed
  #3
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
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)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 18, 2006, 18:06
Default OK. I now have a version of er
  #4
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
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
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 18, 2006, 20:40
Default Given that there have been a l
  #5
brooksmoses
Guest
 
Posts: n/a
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).
  Reply With Quote

Old   April 18, 2006, 23:51
Default I aggree that as specified in
  #6
Senior Member
 
Martin Beaudoin
Join Date: Mar 2009
Posts: 330
Rep Power: 13
mbeaudoin will become famous soon enough
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?
mbeaudoin is offline   Reply With Quote

Old   April 19, 2006, 00:22
Default Yeah, on second thought I most
  #7
brooksmoses
Guest
 
Posts: n/a
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.)
  Reply With Quote

Old   April 19, 2006, 04:36
Default @deactivating demangling: Yes,
  #8
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
@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 ....)
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 19, 2006, 10:23
Default I have added correct demanglin
  #9
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
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.
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   April 20, 2006, 05:53
Default Thanks, will try it. Sounds pl
  #10
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
Thanks, will try it. Sounds pleasantly dodgy - reading /proc/ ;-)
mattijs is offline   Reply With Quote

Old   June 2, 2006, 08:01
Default Hi Bernhard, going through
  #11
Super Moderator
 
Mattijs Janssens
Join Date: Mar 2009
Posts: 1,416
Rep Power: 16
mattijs is on a distinguished road
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?
mattijs is offline   Reply With Quote

Old   June 2, 2006, 08:33
Default Hi Mattijs! Latest Version:
  #12
Assistant Moderator
 
Bernhard Gschaider
Join Date: Mar 2009
Posts: 3,912
Rep Power: 40
gschaider will become famous soon enoughgschaider will become famous soon enough
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).
__________________
Note: I don't use "Friend"-feature on this forum out of principle. Ah. And by the way: I'm not on Facebook either. So don't be offended if I don't accept your invitation/friend request
gschaider is offline   Reply With Quote

Old   June 2, 2006, 12:47
Default Well, I've been using this for
  #13
Senior Member
 
Hrvoje Jasak
Join Date: Mar 2009
Location: London, England
Posts: 1,758
Rep Power: 21
hjasak will become famous soon enough
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
__________________
Hrvoje Jasak
Providing commercial FOAM/OpenFOAM and CFD Consulting: http://wikki.co.uk
hjasak is offline   Reply With Quote

Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
how to trace the interface information ? sriah FLUENT 0 August 14, 2006 02:30
Particle trace Thien CFX 1 April 12, 2006 14:54
A stack trace error... Vyatscheslav CD-adapco 0 October 5, 2005 02:52
how to trace the streamline hezhao FLUENT 1 October 14, 2004 21:20
front trace rookie FLUENT 0 May 28, 2003 09:04


All times are GMT -4. The time now is 11:46.