Hello,

my question is, if it is possible to monitor the memory (heap) fragmentation
with mpatrol. I'm working on an embedded system (linux) with limited memory. The
program will have to run for years without beeing restarted. So the fragmentaion
of the heap is an considerable issue. The software is written in c++.

I saw the feature of mpatrol to output a heap mem-map. My question now is, if
mpatrol is influencing the usual way of memory allocation (malloc/free
new/delete) as it is done by the gnu libs. Perhaps there is a way to force
mpatrol to do only logging?

Thanks.

Stefan

--- In mpatrol@yahoogroups.com, "Subramanian R" <subbz15@...> wrote:
>
> Hi,
> I'm trying to build mpatrol on a RHEL 5 machine and getting errors during the
make.
> I have followed the below steps:
>    1. Run pkg/auto/setup
>    2. ./configure
>    3. make.
> I get the error message listed below. ("symbol.c:82:17: error: bfd.h: No such
file or directory)
> Could someone please help with the building mpatrol on RHEL 5.

you have to install the development package of binutils. This is where bfd.h and
other related files are

Vincent

Hi,
I'm trying to build mpatrol on a RHEL 5 machine and getting errors during the
make.
I have followed the below steps:
    1. Run pkg/auto/setup
    2. ./configure
    3. make.
I get the error message listed below. ("symbol.c:82:17: error: bfd.h: No such
file or directory)
Could someone please help with the building mpatrol on RHEL 5.

Thanks in Advance,
Subbu


[root@localhost auto]# uname -a
Linux localhost.localdomain 2.6.18-92.el5xen #1 SMP Tue Apr 29

gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wp,-MD,.deps/symbol.pp -c symbol.c 
-fPIC -DPIC -o .libs/symbol.lo
symbol.c:82:17: error: bfd.h: No such file or directory
symbol.c:416: error: expected specifier-qualifier-list before 'bfd'
symbol.c:430: error: expected specifier-qualifier-list before 'bfd_vma'
symbol.c: In function '__mp_closesymbols':
symbol.c:543: error: 'objectfile' has no member named 'file'
symbol.c:544: error: 'objectfile' has no member named 'symbols'
symbol.c: At top level:
symbol.c:866: error: expected declaration specifiers or '...' before 'asymbol'
symbol.c: In function 'addsymbol':
symbol.c:872: error: 'p' undeclared (first use in this function)
symbol.c:872: error: (Each undeclared identifier is reported only once
symbol.c:872: error: for each function it appears in.)
symbol.c:878: error: 'BSF_LOCAL' undeclared (first use in this function)
symbol.c:878: error: 'BSF_GLOBAL' undeclared (first use in this function)
symbol.c:878: error: 'BSF_WEAK' undeclared (first use in this function)
symbol.c: At top level:
symbol.c:1411: error: expected declaration specifiers or '...' before 'bfd'
symbol.c: In function 'addsymbols':
symbol.c:1413: error: 'asymbol' undeclared (first use in this function)
symbol.c:1413: error: 'p' undeclared (first use in this function)
symbol.c:1421: error: 'h' undeclared (first use in this function)
symbol.c:1464: error: expected expression before ')' token
symbol.c:1498: error: 'SEC_CODE' undeclared (first use in this function)
symbol.c:1500: error: too many arguments to function 'addsymbol'
symbol.c:1511: error: 'objectfile' has no member named 'symbols'
symbol.c: In function '__mp_addsymbols':
symbol.c:1619: error: 'bfd' undeclared (first use in this function)
symbol.c:1619: error: 'a' undeclared (first use in this function)
symbol.c:1619: error: 'g' undeclared (first use in this function)
symbol.c:1619: error: 'h' undeclared (first use in this function)
symbol.c:1835: error: 'bfd_archive' undeclared (first use in this function)
symbol.c:1852: error: 'bfd_object' undeclared (first use in this function)
symbol.c:1881: error: 'objectfile' has no member named 'file'
symbol.c:1882: error: 'objectfile' has no member named 'symbols'
symbol.c:1883: error: 'objectfile' has no member named 'base'
symbol.c:1886: error: too many arguments to function 'addsymbols'
symbol.c:1888: warning: passing argument 4 of 'addsymbols' makes integer from
pointer without a cast
symbol.c:1888: error: too many arguments to function 'addsymbols'
symbol.c: In function '__mp_findsymbol':
symbol.c:2418: error: 'BSF_LOCAL' undeclared (first use in this function)
symbol.c:2419: error: 'BSF_WEAK' undeclared (first use in this function)
symbol.c:2420: error: 'BSF_GLOBAL' undeclared (first use in this function)
symbol.c: At top level:
symbol.c:2441: error: expected ')' before '*' token
symbol.c: In function '__mp_findsource':
symbol.c:2488: error: 'sourcepos' has no member named 'addr'
symbol.c:2488: error: 'bfd_vma' undeclared (first use in this function)
symbol.c:2488: error: expected ';' before 'p'
symbol.c:2489: error: 'sourcepos' has no member named 'found'
symbol.c:2492: error: 'sourcepos' has no member named 'symbols'
symbol.c:2492: error: 'objectfile' has no member named 'symbols'
symbol.c:2493: error: 'sourcepos' has no member named 'base'
symbol.c:2493: error: 'objectfile' has no member named 'base'
symbol.c:2494: error: 'objectfile' has no member named 'file'
symbol.c:2494: error: 'findsource' undeclared (first use in this function)
symbol.c:2495: error: 'sourcepos' has no member named 'found'
symbol.c:2497: error: 'sourcepos' has no member named 'func'
symbol.c:2498: error: 'sourcepos' has no member named 'file'
symbol.c:2499: error: 'sourcepos' has no member named 'line'
gmake[2]: *** [symbol.lo] Error 1
gmake[2]: Leaving directory `/root/covtool/REL_1_5_0/pkg/auto/src'
gmake[1]: *** [all-recursive] Error 1
gmake[1]: Leaving directory `/root/covtool/REL_1_5_0/pkg/auto'
gmake: *** [all-recursive-am] Error 2

I have forgotten something important: on Windows (at least using MSYS / MinGW)
you can use pkg-config to compile and link your program against mpatrol. In that
case, mpatrol will be statically linked to your program (it has been reported
that there are problems when using mpatrol dll on Windows and i have also
experienced that).

On linux, pkg-config can also be used, but mpatrol will not be statically linked
to your program and mpatrol shared lib will be used

Vincent Torri

--- In mpatrol@yahoogroups.com, "vincent.torri" <vtorri@...> wrote:
>
> I've been working for some  months on an autotooled mpatrol using the svn
version, with the help of Graeme Roy (the mpatrol author) for some
> technical details. What i have done is in the AUTOTOOL branch of the svn
repository of mpatrol.
>
> It is work in progress, but I think that I have now a working autotooled
mpatrol (linux and msys/mingw).
>
> If some people are interested in testing that version of mpatrol, do the
following commands:
>
>  * svn co
https://mpatrol.svn.sourceforge.net/svnroot/mpatrol/branches/AUTOTOOL/
mpatrol_autotooled
>  * go to mpatrol_autotooled
>  * autoreconf -f -i
>  * ./configure --without-x
>  * make and make install of course
>
> There is a problem with mptrace, using lesstiff (Graeme told me that the api
of lesstiff has changed several times), that's why i added --without-x as option
in configure to disable its compilation. You can try to compile mptrace (don't
add --without-x) , but you may have some problems when compiling it.
>
> About linux 64 bits, the compilation should be fine.
>
> If you have remarks, ideas, or regression reports, please let me know
>
> regards
>
> Vincent Torri
>

I've been working for some  months on an autotooled mpatrol using the svn
version, with the help of Graeme Roy (the mpatrol author) for some
technical details. What i have done is in the AUTOTOOL branch of the svn
repository of mpatrol.

It is work in progress, but I think that I have now a working autotooled mpatrol
(linux and msys/mingw).

If some people are interested in testing that version of mpatrol, do the
following commands:

  * svn co https://mpatrol.svn.sourceforge.net/svnroot/mpatrol/branches/AUTOTOOL/
mpatrol_autotooled
  * go to mpatrol_autotooled
  * autoreconf -f -i
  * ./configure --without-x
  * make and make install of course

There is a problem with mptrace, using lesstiff (Graeme told me that the api of
lesstiff has changed several times), that's why i added --without-x as option in
configure to disable its compilation. You can try to compile mptrace (don't add
--without-x) , but you may have some problems when compiling it.

About linux 64 bits, the compilation should be fine.

If you have remarks, ideas, or regression reports, please let me know

regards

Vincent Torri

Hello,
I am trying to use mpatrol on the Eclipse Platform and the MinGW tools on
Windows32.

I first built the libraries and executables (I had to remove -lintl in the
makefile because I do not have the library, I do not think this is important as
I do not plan to use the --dynamic option).

I build a simlpe application:


#include <malloc.h>

int main()
{
	 int* pnt, *qnt;

	 pnt = (int*)malloc(32*sizeof(int));

	 qnt = new int[10];

	 free(pnt);
	 delete [] qnt;

     return 0;
}

and link it with the mpatrol library. If I then call mpatrol:

mpatrol.exe --log-all --leak-table   myapp.exe

I get this message:

Application Error

The application failed to initialize properly (0xc0000005). Click on OK to
terminate the application.


Any ideas? Thanks in advance.


Jorge

I am developing an application using C++, MFC and Visual Studio 2008. I have
good reason to believe that it frees memory not properly allocated and it leaks
memory. To remedy this situation, I am trying to use MPatrol.

     When I run MPatrol the generated log file shows these problems. However, the
stack trace is all address, not symbols. What do I do to get it to show symbols?

Thanks

Bob

Thought I would add a couple more observations that I've made regarding the use
of DLLs vs static libs.  I played around a little with compiling and running the
test applications in mpatrol/tests/fail.

1)  If I compile and link the test application against the static mpatrol
library, all works as expected.

2)  If I compile and link the test application against the mpatrol DLL, I get a
crash when I run.

3)  If I compile my executable against the static mpatrol library, all works as
expected.

4)  If I compile my executable against the mpatrol DLL, I get a crash when I
run.  This is the exact situation of my original post.

5)  I compile my executable against the static mpatrol library.  But, this time,
my application contains calls against another DLL (call it "myappDLL"), so I
link my application against myappDLL.  Regardless of whether myappDLL is
compiled against mpatrol static lib or mpatrol DLL, I get a crash.

6)  Same as #5, but this time I do not compile myappDLL against mpatrol.  All
works as expected (but I want to have all of my app DLLs using mpatrol, so this
doesn't help me)

7)  Same as #5, but instead of compiling my executable against myappDLL, I use
LoadLibrary and GetProcAddress to call into myappDLL.  Regardless of whether
myappDLL is compiled against static or DLL version of mpatrol, I get a crash
upon call to LoadLibrary.

I've read Greg Chicares' investigation documents posted in the files section of
this group, but I don't see anything in his work about crashes, only errors and
corruption in the log file.


--- In mpatrol@yahoogroups.com, "greg80303" <grutz@...> wrote:
>
> Windows XP SP3 / MinGW
>
> I have downloaded the 1.5.1 SVN tag tree and built it myself.  I simply went
into <mpatrol>/build/windows and executed "make -f Makefile.mingw all", then
copied the include files to my include directory and the mpatrolmt.dll file to
the same directory as my executable.
>
> I am trying to use mpatrol to do some memory analysis on a piece of software. 
The complete system is pretty complex, but I am starting with only a small
piece.  Our "launcher" is a simple executable that does some reading of
configuration files and then calls DLL entry points (via
LoadLibrary/GetProcAddress) to start the rest of the system.  So, the launcher
itself is not linked against any external DLLs from our system.
>
> The compile line for my launcher looks something like this:
>
> gcc -c   -mno-cygwin -g -DRI_HAVE_STDINT_H -Wall -Ic:/<myproject>/include
-include mpatrol.h -I./Win32  main.c -o
c:/<myproject>/gen/Win32/debug/launcher/main.o
>
> gcc -c   -mno-cygwin -g -DRI_HAVE_STDINT_H -Wall -Ic:/<myproject>/include
-include mpatrol.h -I./Win32 -Ic:/<myproject>/include Win32/port.c -o
c:/<myproject>/gen/Win32/debug/launcher/./Win32/port.o
>
> g++ -mno-cygwin -o c:/<myproject>/install/Win32/debug/bin/ri.exe
c:/<myproject>/gen/Win32/debug/launcher/main.o
c:/<myproject>/gen/Win32/debug/launcher/./Win32/port.o
-Lc:/<myproject>/install/Win32/debug/bin -lmpatrolmt
>
> The program crashes before ever getting to my main().  Running in GDB, I get
the following SIGSEGV notification:
>
> (gdb) run
> Starting program: c:/<myproject>/install/Win32/debug/bin/ri.exe
c:/<myproject>/launcher/launcher_win32.cfg
> [New thread 656.0xaac]
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x7c9104da in ntdll!RtlStatMemoryStream () from C:\WINDOWS\system32\ntdll.dll
> (gdb)
>
> The mpatrol.log file is created and there is some information in it.  So, I
rebuilt mpatrol with debug symbols and put a breakpoint in __mp_printversion()
to see if I could learn anything.
>
> (gdb) run
> Starting program: c:/<myproject>/install/Win32/debug/bin/ri.exe
c:/<myproject>/src/launcher/launcher_win32.cfg
> [New thread 1108.0xd7c]
>
> Breakpoint 1, __mp_printversion () at ../../src/diag.c:1805
> (gdb) where
> #0  __mp_printversion () at ../../src/diag.c:1805
> #1  0x004d575f in __mp_init () at ../../src/inter.c:508
> #2  0x004d5f8a in __mp_alloc (l=128, a=0, f=AT_MALLOC, s=0x0, t=0x0, u=0,
g=0x0, h=0, k=1) at ../../src/inter.c:873
> #3  0x004da8d1 in malloc (l=128) at ../../src/malloc.c:55
> #4  0x004c10c3 in DllMainCRTStartup@12 () from
c:\<myproject>\install\Win32\debug\bin\mpatrolmt.dll
> #5  0x7c90118a in ntdll!LdrSetAppCompatDllRedirectionCallback () from
C:\WINDOWS\system32\ntdll.dll
> #6  0x004c0000 in ?? ()
> #7  0x00000001 in ?? ()
> #8  0x0022fd30 in ?? ()
> #9  0x004c1060 in __dll_exit () from
c:\<myproject>\install\Win32\debug\bin\mpatrolmt.dll
> #10 0x7c91c4da in ntdll!LdrHotPatchRoutine () from
C:\WINDOWS\system32\ntdll.dll
> #11 0x7c921194 in ntdll!RtlMapGenericMask () from
C:\WINDOWS\system32\ntdll.dll
> #12 0x7c92108f in ntdll!RtlMapGenericMask () from
C:\WINDOWS\system32\ntdll.dll
> #13 0x7c90e437 in ntdll!LdrCreateOutOfProcessImage () from
C:\WINDOWS\system32\ntdll.dll
>
> I can step all the way through until I am back in the DllMainCRTStartup
function.  Then, the next step causes the crash.  Any ideas for me?  Any more
information I could provide to help?
>
> Greg
>

Windows XP SP3 / MinGW

I have downloaded the 1.5.1 SVN tag tree and built it myself.  I simply went
into <mpatrol>/build/windows and executed "make -f Makefile.mingw all", then
copied the include files to my include directory and the mpatrolmt.dll file to
the same directory as my executable.

I am trying to use mpatrol to do some memory analysis on a piece of software. 
The complete system is pretty complex, but I am starting with only a small
piece.  Our "launcher" is a simple executable that does some reading of
configuration files and then calls DLL entry points (via
LoadLibrary/GetProcAddress) to start the rest of the system.  So, the launcher
itself is not linked against any external DLLs from our system.

The compile line for my launcher looks something like this:

gcc -c   -mno-cygwin -g -DRI_HAVE_STDINT_H -Wall -Ic:/<myproject>/include
-include mpatrol.h -I./Win32  main.c -o
c:/<myproject>/gen/Win32/debug/launcher/main.o

gcc -c   -mno-cygwin -g -DRI_HAVE_STDINT_H -Wall -Ic:/<myproject>/include
-include mpatrol.h -I./Win32 -Ic:/<myproject>/include Win32/port.c -o
c:/<myproject>/gen/Win32/debug/launcher/./Win32/port.o

g++ -mno-cygwin -o c:/<myproject>/install/Win32/debug/bin/ri.exe
c:/<myproject>/gen/Win32/debug/launcher/main.o
c:/<myproject>/gen/Win32/debug/launcher/./Win32/port.o
-Lc:/<myproject>/install/Win32/debug/bin -lmpatrolmt

The program crashes before ever getting to my main().  Running in GDB, I get the
following SIGSEGV notification:

(gdb) run
Starting program: c:/<myproject>/install/Win32/debug/bin/ri.exe
c:/<myproject>/launcher/launcher_win32.cfg
[New thread 656.0xaac]

Program received signal SIGSEGV, Segmentation fault.
0x7c9104da in ntdll!RtlStatMemoryStream () from C:\WINDOWS\system32\ntdll.dll
(gdb)

The mpatrol.log file is created and there is some information in it.  So, I
rebuilt mpatrol with debug symbols and put a breakpoint in __mp_printversion()
to see if I could learn anything.

(gdb) run
Starting program: c:/<myproject>/install/Win32/debug/bin/ri.exe
c:/<myproject>/src/launcher/launcher_win32.cfg
[New thread 1108.0xd7c]

Breakpoint 1, __mp_printversion () at ../../src/diag.c:1805
(gdb) where
#0  __mp_printversion () at ../../src/diag.c:1805
#1  0x004d575f in __mp_init () at ../../src/inter.c:508
#2  0x004d5f8a in __mp_alloc (l=128, a=0, f=AT_MALLOC, s=0x0, t=0x0, u=0, g=0x0,
h=0, k=1) at ../../src/inter.c:873
#3  0x004da8d1 in malloc (l=128) at ../../src/malloc.c:55
#4  0x004c10c3 in DllMainCRTStartup@12 () from
c:\<myproject>\install\Win32\debug\bin\mpatrolmt.dll
#5  0x7c90118a in ntdll!LdrSetAppCompatDllRedirectionCallback () from
C:\WINDOWS\system32\ntdll.dll
#6  0x004c0000 in ?? ()
#7  0x00000001 in ?? ()
#8  0x0022fd30 in ?? ()
#9  0x004c1060 in __dll_exit () from
c:\<myproject>\install\Win32\debug\bin\mpatrolmt.dll
#10 0x7c91c4da in ntdll!LdrHotPatchRoutine () from C:\WINDOWS\system32\ntdll.dll
#11 0x7c921194 in ntdll!RtlMapGenericMask () from C:\WINDOWS\system32\ntdll.dll
#12 0x7c92108f in ntdll!RtlMapGenericMask () from C:\WINDOWS\system32\ntdll.dll
#13 0x7c90e437 in ntdll!LdrCreateOutOfProcessImage () from
C:\WINDOWS\system32\ntdll.dll

I can step all the way through until I am back in the DllMainCRTStartup
function.  Then, the next step causes the crash.  Any ideas for me?  Any more
information I could provide to help?

Greg

If the app is executed at the prompt ie
./CShell
Segmentation fault
bash>


yes a mpatrol.log is generated...
@(#) mpatrol 1.5.1 (08/12/16)
Copyright (C) 1997-2008 Graeme S. Roy

This is free software, and you are welcome to redistribute it under
certain
conditions; see the GNU Lesser General Public License for details.

For the latest mpatrol release and documentation,
visit http://sourceforge.net/projects/mpatrol.

operating system:       UNIX
system variant:         Linux
processor architecture: Intel 80x86
processor word size:    32-bit
object file format:     BFD
dynamic linker type:    SVR4

Log file generated on Thu Feb  5 10:45:51 2009
read 425 symbols from
/home/tmichals/Linux-x86/release/libs/libSystemManager.so
read 269 symbols from
/home/tmichals/Linux-x86/release/libs/libCServices.so
read 137 symbols from
/home/tmichals/Linux-x86/release/libs/libvtyThreads.so
read 257 symbols from /home/tmichals/Linux-x86/release/libs/libluabind.so
read 758 symbols from /home/tmichals/Linux-x86/release/libs/liblua.so
read 772 symbols from
/home/tmichals/Linux-x86/release/libs/liblog4cplus.so.2
read 164 symbols from
/home/tmichals/Linux-x86/release/libs/libboost_thread-gcc42-mt-1_36.so.1.36.0
read 229 symbols from
/home/tmichals/Linux-x86/release/libs/libboost_signals-gcc42-mt-1_36.so.1.36.0
read 154 symbols from
/home/tmichals/Linux-x86/release/libs/libboost_filesystem-gcc42-mt-1_36.so.1.36.\
0
read 601 symbols from
/home/tmichals/Linux-x86/release/libs/libboost_program_options-gcc42-mt-1_36.so.\
1.36.0
read 11 symbols from
/home/tmichals/Linux-x86/release/libs/libboost_system-gcc42-mt-1_36.so.1.36.0
read 4050 symbols from /home/tmichals/Linux-x86/release/libs/libxml2.so.2
read 347 symbols from /usr/local/lib/libmpatrolmt-1.5.1.so
read 708 symbols from /usr/lib/libbfd-2.18.0.20080103.so
read 410 symbols from /lib/libreadline.so.5
read 53 symbols from /lib/libhistory.so.5
read 47 symbols from /lib/i686/cmov/libdl.so.2
read 9688 symbols from
/home/tmichals/Linux-x86/release/libs/libmkl_intel.so
read 5377 symbols from
/home/tmichals/Linux-x86/release/libs/libmkl_intel_thread.so
read 2495 symbols from
/home/tmichals/Linux-x86/release/libs/libmkl_lapack.so
read 735 symbols from /home/tmichals/Linux-x86/release/libs/libiomp5.so
read 1665 symbols from
/home/tmichals/Linux-x86/release/libs/libmkl_core.so
read 996 symbols from /lib/i686/cmov/libpthread.so.0
read 2275 symbols from /usr/lib/libstdc++.so.6
read 1050 symbols from /lib/i686/cmov/libm.so.6
read 91 symbols from /lib/libgcc_s.so.1
read 7002 symbols from /lib/i686/cmov/libc.so.6
read 135 symbols from /lib/i686/cmov/librt.so.1
read 64 symbols from /usr/lib/libz.so.1
read 438 symbols from /lib/libncurses.so.5
read 241 symbols from /lib/ld-linux.so.2
read 510 symbols from ./CShell
<end of file>

if I run it against mpatrol

@(#) mpatrol 1.5.1 (08/12/16)
Copyright (C) 1997-2008 Graeme S. Roy

This is free software, and you are welcome to redistribute it under
certain
conditions; see the GNU Lesser General Public License for details.

For the latest mpatrol release and documentation,
visit http://sourceforge.net/projects/mpatrol.

operating system:       UNIX
system variant:         Linux
processor architecture: Intel 80x86
processor word size:    32-bit
object file format:     BFD
dynamic linker type:    SVR4

WARNING: [FRENUL]: free: attempt to free a NULL pointer

Log file generated on Thu Feb  5 10:48:02 2009
........ ton of stuff.....
WARNING: [RSZNUL]: realloc: attempt to resize a NULL pointer

and this was the last message and the prompt is returned...

and if I just use gdb ./CShell
it stops that the seg fault issue...


--- In mpatrol@yahoogroups.com, "Graeme Roy" <graeme_roy@...> wrote:
>
> If you haven't changed the mpatrol source code then it'll be using the
> default so that answers my question ;-)
>
> There's a signal-handler in the mpatrol stack walking code that handles
> SIGSEGV if it walks off the end of the call stack, so that might be
causing
> the break in gdb, although mpatrol can recover from this.  Did you get
> anything in mpatrol.log when not running it in gdb?
>

Yep, that was the problem with this issue.... relinked with mpatrolmt
and this issue is not happening...



--- In mpatrol@yahoogroups.com, "Graeme Roy" <graeme_roy@...> wrote:
>
> Hi,
>
> Double-check that you're using the thread-safe version of mpatrol
> (libmpatrolmt).  Using the normal version will cause multithreaded
programs
> to fail.
>
> Graeme.
>
>   _____
>
> From: mpatrol@yahoogroups.com [mailto:mpatrol@yahoogroups.com] On
Behalf Of
> tcmichals
> Sent: 04 February 2009 20:39
> To: mpatrol@yahoogroups.com
> Subject: [mpatrol] tracing ILLMEM in Boost C++
>
>
>
> I'm trying to figure out what is going on with this trace using the
> latest mpatrol... 1.5.1
>
> ERROR: [ILLMEM]: illegal memory access at address 0xB4C9B4C4
> 0xB4C9B4C4 not in heap
>
> call stack
> 0xB7C861CE __mp_getalloc+190
> 0xB7C887E2 __mp_getmemory+242
> 0xB7C9A5F5 __mp_alloc+421
> 0xB7C9CACD malloc+93
> 0xB7E5265C _ZN5boost6detail25get_once_per_thread_epochEv+92
>
> here is the code, it is only trying to allocate 4 bytes...
>
> boost::uintmax_t& get_once_per_thread_epoch()
> {
>
> BOOST_VERIFY(!pthread_once(&epoch_tss_key_flag,create_epoch_tss_key));
> void* data=pthread_getspecific(epoch_tss_key);
> if(!data)
> {
> data=malloc(sizeof(boost::uintmax_t));
> BOOST_VERIFY(!pthread_setspecific(epoch_tss_key,data));
> *static_cast<boost::uintmax_t*>(data)=UINTMAX_C(~0);
> }
> return *static_cast<boost::uintmax_t*>(data);
> }
>

All I did was go into the pkg/auto changed the build script to do the
following...

configure --without-x

because there is not X tools installed, and did a build and install.

Then just added mpatrol.h to the top of the main cpp file and execute
mpatrol.

Yes, very much the newbie on this....
So, I really don't know the answer to the question, send the config.h?
Or how can I tell.

Thanks.... for the help!!!


--- In mpatrol@yahoogroups.com, "Graeme Roy" <graeme_roy@...> wrote:
>
> Hi,
>
> You can't selectively choose which libraries in a program to run with
> mpatrol - it has to be the whole program or nothing (unless you link the
> shared library in question with libc.a, but then you'll open a whole
can of
> worms if you pass and receive pointers to allocated memory).
>
> That said, the crash looks to be occuring when mpatrol is working
out the
> stack trace.  It looks to be an Intel i686 processor you're running
it on.
> What stack trace mechanism is mpatrol using - the default or one of the
> MP_*STACK_SUPPORT macros in config.h?
>
> Graeme.
>
>   _____
>
> From: mpatrol@yahoogroups.com [mailto:mpatrol@yahoogroups.com] On
Behalf Of
> tcmichals
> Sent: 04 February 2009 21:09
> To: mpatrol@yahoogroups.com
> Subject: [mpatrol] Segmentation fault
>
>
>
> Also, ran into to this issue. When the application is started it
> dies, so tossed it into gdb and get the following stack trace..
>
> It is trying to trace into an intel library MLK (math kernel library)
> is there so how I can skip over this library? Or some way not to
> trace this one?
>
> $3 = (stackinfo *) 0xbf812364
> (gdb) bt
> #0 __mp_getframe (p=0xbf812364) at stack.c:713
> #1 0xb7bc019c in __mp_getaddrs (h=0xb7bda6e0, p=0xbf812364) at
addr.c:147
> #2 0xb7bbe832 in __mp_getmemory (h=0xb7bda5a0, l=20, a=0,
> v=0xbf812330) at info.c:418
> #3 0xb7bd05f5 in __mp_alloc (l=20, a=0, f=AT_CALLOC, s=0x0, t=0x0,
> u=0, g=0x0, h=0, k=1) at inter.c:922
> #4 0xb7bd29f1 in calloc (l=1, n=3068825376) at malloc.c:81
> #5 0xb7a940c6 in _dlerror_run () from /lib/i686/cmov/libdl.so.2
> #6 0xb7a93b61 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2
> #7 0xb6e5857a in _mkl_dll_to_load_code () from
> /home/txxxx/Linux-x86/release/libs/libmkl_core.so
>

Also, ran into to this issue.  When the application is started it
dies, so tossed it into gdb and get the following stack trace..

It is trying to trace into an intel library MLK (math kernel library)
  is there so how I can skip over this library? Or some way not to
trace this one?

$3 = (stackinfo *) 0xbf812364
(gdb) bt
#0  __mp_getframe (p=0xbf812364) at stack.c:713
#1  0xb7bc019c in __mp_getaddrs (h=0xb7bda6e0, p=0xbf812364) at addr.c:147
#2  0xb7bbe832 in __mp_getmemory (h=0xb7bda5a0, l=20, a=0,
v=0xbf812330) at info.c:418
#3  0xb7bd05f5 in __mp_alloc (l=20, a=0, f=AT_CALLOC, s=0x0, t=0x0,
u=0, g=0x0, h=0, k=1) at inter.c:922
#4  0xb7bd29f1 in calloc (l=1, n=3068825376) at malloc.c:81
#5  0xb7a940c6 in _dlerror_run () from /lib/i686/cmov/libdl.so.2
#6  0xb7a93b61 in dlopen@@GLIBC_2.1 () from /lib/i686/cmov/libdl.so.2
#7  0xb6e5857a in _mkl_dll_to_load_code () from
/home/txxxx/Linux-x86/release/libs/libmkl_core.so

I'm trying to figure out what is going on with this trace using the
latest mpatrol... 1.5.1

ERROR: [ILLMEM]: illegal memory access at address 0xB4C9B4C4
     0xB4C9B4C4 not in heap

     call stack
	 0xB7C861CE __mp_getalloc+190
	 0xB7C887E2 __mp_getmemory+242
	 0xB7C9A5F5 __mp_alloc+421
	 0xB7C9CACD malloc+93
	 0xB7E5265C _ZN5boost6detail25get_once_per_thread_epochEv+92

here is the code, it is only trying to allocate 4 bytes...

        boost::uintmax_t& get_once_per_thread_epoch()
         {

BOOST_VERIFY(!pthread_once(&epoch_tss_key_flag,create_epoch_tss_key));
             void* data=pthread_getspecific(epoch_tss_key);
             if(!data)
             {
                 data=malloc(sizeof(boost::uintmax_t));
                 BOOST_VERIFY(!pthread_setspecific(epoch_tss_key,data));
                 *static_cast<boost::uintmax_t*>(data)=UINTMAX_C(~0);
             }
             return *static_cast<boost::uintmax_t*>(data);
         }

Congrats everyone

Yippee 1.51 is official ..

Regarding Backtrace () , I am using backtrace()  and this works super for me ..

Thanks and Regards
Sagar




On Tue, Dec 16, 2008 at 4:58 PM, Daniel Jacobowitz <drow@...> wrote:
> On Tue, Dec 16, 2008 at 03:16:38PM -0000, Graeme Roy wrote:
>> The 1.5.1 release of mpatrol has just been completed and released to the
>> Subversion repository at SourceForge,
>
> Awesome, thank you!
>
>> I didn't make libunwind the default stack traversal mechanism for MIPS yet
>> as
>> I know some people are still using the existing MIPS mechanism and until
>> the
>> patches for getting libunwind to work on MIPS are public there didn't seem
>> any
>> point in changing the current default.
>
> FWIW, they are public; they're in the libunwind GIT repository.
> Leaving the default alone makes sense if anyone's using the existing
> mechanism, though - libunwind on MIPS has some limitations.
>
>> Also, it might be better to use libunwind rather than backtrace() for the
>> 64-bit x86 processors as there are less limitations. I just didn't know
>> what
>> the support was like for that processor in libunwind.
>
> Ought to work. After IA-64 it's probably the best-supported
> processor. Everyone has glibc, though, and not everyone has
> libunwind.
>
> --
> Daniel Jacobowitz
> CodeSourcery
>

On Tue, Dec 16, 2008 at 03:16:38PM -0000, Graeme Roy wrote:
> The 1.5.1 release of mpatrol has just been completed and released to the
> Subversion repository at SourceForge,

Awesome, thank you!

> I didn't make libunwind the default stack traversal mechanism for MIPS yet
> as
> I know some people are still using the existing MIPS mechanism and until the
> patches for getting libunwind to work on MIPS are public there didn't seem
> any
> point in changing the current default.

FWIW, they are public; they're in the libunwind GIT repository.
Leaving the default alone makes sense if anyone's using the existing
mechanism, though - libunwind on MIPS has some limitations.

> Also, it might be better to use libunwind rather than backtrace() for the
> 64-bit x86 processors as there are less limitations.  I just didn't know
> what
> the support was like for that processor in libunwind.

Ought to work.  After IA-64 it's probably the best-supported
processor.  Everyone has glibc, though, and not everyone has
libunwind.

--
Daniel Jacobowitz
CodeSourcery

The 1.5.1 release of mpatrol has just been completed and released to the
Subversion repository at SourceForge,
http://sourceforge.net/svn/?group_id=19456.

It contains the following major changes from release 1.5.0.

* mpatrol can be built to use libunwind for call stack traversal on any UNIX
   system that has libunwind installed.  It is the default for ARM and IA64
   but can be turned on for other processor architecures by defining
   MP_LIBUNWIND_SUPPORT when building the mpatrol library.  [Code supplied by
   Daniel Jacobowitz of CodeSourcery].

* mpatrol can be built to use the backtrace() routine for call stack
   traversal on any UNIX system that has glibc installed.  This doesn't give
   valid frame pointers (they are simulated) and only has support for a
finite
   number of frames (currently set at 64).  It is the default for 64-bit x86
   Linux systems but can be turned on for other processor architectures and
   systems by defining MP_GLIBCBACKTRACE_SUPPORT when building the mpatrol
   library.

* Only do a backup copy of the call stack context where it is necessary in
   __mp_getaddrs().  [Code supplied by Daniel Jacobowitz of Code Sourcery].

* No longer free allocations created by alloca() when in a recursive call
   within the mpatrol library, and check for the possibility that the call
   stack traversal may have failed before performing a call stack comparison
   in checkalloca().  [Code supplied by Daniel Jacobowitz of Code Sourcery].

* Added support for reading symbols and/or line number information from
   stripped executable files or shared libraries generated by gcc that have
   their debugging information in a separate file (referenced by the
   .gnu_debuglink section).  [Code supplied by Daniel Jacobowitz of Code
   Sourcery].

* Now use dl_iterate_phdr() on Linux systems to determine the shared
   libraries loaded by a program rather than the _DYNAMIC symbol.  This might
   mean that statically linked programs can no longer be built with
   libmpatrol.a if dl_iterate_phdr() is only available to dynamically linked
   programs.  [Code supplied by Daniel Jacobowitz of Code Sourcery].

I didn't make libunwind the default stack traversal mechanism for MIPS yet
as
I know some people are still using the existing MIPS mechanism and until the
patches for getting libunwind to work on MIPS are public there didn't seem
any
point in changing the current default.

Also, it might be better to use libunwind rather than backtrace() for the
64-bit x86 processors as there are less limitations.  I just didn't know
what
the support was like for that processor in libunwind.

I never quite got round to migrating the mpatrol web site to SourceForge,
but
I'll see what I can get done over the next few months.

Have a good Christmas,

Graeme.

On Thu, Nov 20, 2008 at 10:09:17AM -0000, Graeme Roy wrote:
> Hi,
>
> I'm assuming backtrace() is a gcc 4 function because I can't find it in gcc
> 3, but yes, it looks like what you want.

It's a glibc function rather than a gcc function; include
<execinfo.h> to get it on any GNU/Linux system.

--
Daniel Jacobowitz
CodeSourcery

Hi,

I'm assuming backtrace() is a gcc 4 function because I can't find it in gcc
3, but yes, it looks like what you want.  The only problem is that it's not
just a simple rewrite.  There's no stack frame information returned by
backtrace(), only return addresses, and mpatrol currently uses the frame
pointer to identify the position in the stack before then going on to look
at the return address.  You shouldn't need backtrace_symbols() because
mpatrol already has symbol support, including more formats than
backtrace_symbols() supports, and it should work fine with the return
addresses that backtrace() supplies.

I think only stack.[ch] and addr.c would need to be changed to accommodate
this change, and possibly checkalloca() in inter.c (since it also uses the
frame pointers to determine if an allocation can be freed when a function
has returned).

And now you're going to ask me how to do it ;-)

You might be best looking at all the code contained within the
MP_BUILTINSTACK_SUPPORT macro and changing it to use backtrace() instead.
The __builtin_frame_address/__builtin_return_address mechanism and
backtrace() are quite similar, except that the former has a hard-limit to
the size of the stack at compile-time, and the latter returns no frame
pointers as described above.  I'll add this to my things to do in the future
with mpatrol but you should be able to get something working at the moment
with the minimum of changes.  And more to the point, you shouldn't need to
worry about any assembler code.  Alternatively, if you really need something
working quickly, you could just try building mpatrol with
MP_BUILTINSTACK_SUPPORT to see if that works for you.

Good luck,

Graeme.

-----Original Message-----
From: Sagar [mailto:sagarseth@...]
Sent: 17 November 2008 13:08
To: Daniel Jacobowitz; mpatrol; graeme_roy@...
Subject: Re: [mpatrol] mpatrol 64 bit issue ....

Hello everyone,,

I got an interesting comment from suse guys ,,,

"One easy way to do backtracing in a portable way over multiple Linux
architectures is to use glibc's backtrace() function. "

http://www.gnu.org/software/libtool/manual/libc/Backtraces.html

does it makes sense for us ,, can we use this and questions comes .. how
....???

i know i am asking too many questions and many of them could be dumb but
please bear with me ...

Thanks
Sagar

On 11/17/08, Sagar <sagarseth@...> wrote:
> Hello Friend ,,
>
> I am confused ... from what i see inside the code i need to re-write
>
> 1. struct frameinfo and stackinfo ( for 64bit) 2. then need to write
> the getaddr unwind getframe and all other functions in stack.c
>
> right ???
>
> please help with some documentation.. better will be an example ..
>
> here is something useful that i found over the weekend ,... please
> have look ,, let me know about further steps...
>
>
> thanks in advance...
> Seth
>
>
>
>
> From: Graeme Roy <graeme_roy@...>
> Date: Fri, 14 Nov 2008 22:09:22 -0000
> Subject: RE: [mpatrol] mpatrol 64 bit issue ....
> To: Sagar <sagarseth@...>
>
> Hi,
>
>
>
> If you've got the time to have a look, the code for all the stack
> tracebacks is in mpatrol/src/stack.c.  Just look for the x86-specific
> code - there's not much because for 32-bit x86 it's really easy, you
> just follow the chain of frame pointers.  Daniel from CodeSourcery
> replied to the mpatrol group as well, suggesting that it's a lot more
> complicated for 64-bit x86 since you have to look at the .eh_frame
> section in the executable file and any shared libraries.
>
>
>
> What you could do is try defining MP_BUILTINSTACK_SUPPORT when you
> build the mpatrol library.  This will make gcc plant some code to help
> traverse the stack instead of using mpatrol's code.  Unfortunately it
> will only work for a finite size stack (see the comments in
> mpatrol/src/config.h) but it'll get you up and running, I hope.  It
> doesn't always work on all platforms but it's worth you giving it a try.
>
>
>
> Good luck,
>
>
>
> Graeme.
>
>
>
>   _____
>
> From: Sagar [mailto:sagarseth@...]
> Sent: 14 November 2008 12:51
> To: graeme_roy@...
> Subject: Re: [mpatrol] mpatrol 64 bit issue ....
>
>
>
> Hi Friend,
>
> Can u show me where is the
> "source code for getting stack tracebacks in 32 bit"
>
> I can try to put effort for developing the source for 64 bit..
>
> may be i can help u in developing 64 bit version.....
>
> i got a free weekend ...
>
> Sagar
>
> On 11/14/08, Graeme Roy <graeme_roy@...> wrote:
>> Hi,
>>
>> Yes, it sounds like there's been no support added for stack
>> tracebacks on 64-bit x86.  The 32-bit x86 code will not work, as you
>> have found out and
> I
>> haven't written support for 64-bit x86 as I don't have access to it.
>>
>> If anyone has written the extra source code for getting stack
>> tracebacks
> to
>> work for mpatrol on that architecture could they post it here?  It
>> should only be a few lines of diffs anyway, compared to what I'd
>> expect support
> for
>> Itanium to be.
>>
>> Thanks,
>>
>> Graeme.
>>
>>   _____
>>
>> From: mpatrol@yahoogroups.com [mailto:mpatrol@yahoogroups.com] On
>> Behalf
> Of
>> Sagar
>> Sent: 11 November 2008 11:11
>> To: mpatrol@yahoogroups.com
>> Subject: [mpatrol] mpatrol 64 bit issue ....
>>
>>
>>
>> Hello Graeme,
>>
>> Thanks for the update ,, we took the target.h file and places where
>> the ARCH and ENVIRON variables were defined .. we did a undef and
>> redefined them to ARCH_IX86 and ENVIRON_64.
>>
>> CPUs in the box are AMD opteron 275.
>>
>> Now we are getting a core for mpatrol .
>>
>> When we did the analysis on the core then I am getting #0
>> 0x0000002a9567cab4 in __mp_getframe () from /src/lib64/libmpatrol.so
>>
>> What could be wrong .
>>
>> .....-----------------
>>
>> Glad to hear it's working OK for you, at least on one of your machines.
>>
>> For SuSE Enterprise 64-bit, I assume that it's running on Intel Core
>> 2 Duo
>
>> and is therefore x86-64 (and not Itanium). mpatrol has been ported to
>> 64-bit architectures before (MIPS and SPARC for example) but I don't
>> know
> if
>> anything's been done by anyone to port it to 64-bit x86 (i.e. running
>> in a
>
>> 64-bit environment and not just under a 32-bit OS). For example, the
>> stack
>
>> reading code will most likely be different which is probably why
>> you're
> not
>> getting any location information for the allocations.
>>
>> Has anyone here run mpatrol on a 64-bit x86 architecture and got
>> stack tracebacks to work? I imagine there won't be too many changes
>> to make
> (just
>> ensure that ARCH = ARCH_IX86 and ENVIRON = ENVIRON_64 when building
> mpatrol)
>> - just look for ENVIRON_64 in the mpatrol source code to see where I
>> did
> the
>> changes for MIPS and SPARC. I don't have access to a 64-bit OS at the
>> moment so I can't really help much.
>>
>>
>>
>>
>
>
>
> --
> Thanks and Regards
> Sagar
>
>
>
>
> --
> Thanks and Regards
> Sagar
>


--
Thanks and Regards
Sagar

Has anyone tried using mpatrol with Linux running Xenomai?

I try to compile and link the test1.c example that comes with mpatrol
and get the following linking error.

[rob@localhost fail]$ ppc_6xx-g++ -I/opt/eldk-4.1/ppc_6xx/usr/include
test1.c -L/eldk-4.1/ppc_6xx/usr/lib -lmpatrol -lbfd -liberty
/opt/eldk-4.1/usr/../ppc_6xx/usr/lib/libbfd.a(cache.o): In function
`bfd_open_file':
: undefined reference to `unlink_if_ordinary'
collect2: ld returned 1 exit status

After googling "undefined reference to unlink_if_ordinary", I found this
reference to a similar problem
http://gcc.gnu.org/ml/gcc-help/2007-08/msg00036.html

Any help or ideas on how to solve this problem would be greatly
appreciated.

Rob

Hello everyone,,

I got an interesting comment from suse guys ,,,

"One easy way to do backtracing in a portable way over multiple
Linux architectures is to use glibc's backtrace() function. "

http://www.gnu.org/software/libtool/manual/libc/Backtraces.html

does it makes sense for us ,, can we use this and questions comes .. how ...???

i know i am asking too many questions and many of them could be dumb
but please bear with me ...

Thanks
Sagar

On 11/17/08, Sagar <sagarseth@...> wrote:
> Hello Friend ,,
>
> I am confused ... from what i see inside the code i need to re-write
>
> 1. struct frameinfo and stackinfo ( for 64bit)
> 2. then need to write the getaddr unwind getframe and all other
> functions in stack.c
>
> right ???
>
> please help with some documentation.. better will be an example ..
>
> here is something useful that i found over the weekend ,... please
> have look ,, let me know about further steps...
>
>
> thanks in advance...
> Seth
>
>
>
>
> From: Graeme Roy <graeme_roy@...>
> Date: Fri, 14 Nov 2008 22:09:22 -0000
> Subject: RE: [mpatrol] mpatrol 64 bit issue ....
> To: Sagar <sagarseth@...>
>
> Hi,
>
>
>
> If you've got the time to have a look, the code for all the stack tracebacks
> is in mpatrol/src/stack.c.  Just look for the x86-specific code - there's
> not much because for 32-bit x86 it's really easy, you just follow the chain
> of frame pointers.  Daniel from CodeSourcery replied to the mpatrol group as
> well, suggesting that it's a lot more complicated for 64-bit x86 since you
> have to look at the .eh_frame section in the executable file and any shared
> libraries.
>
>
>
> What you could do is try defining MP_BUILTINSTACK_SUPPORT when you build the
> mpatrol library.  This will make gcc plant some code to help traverse the
> stack instead of using mpatrol's code.  Unfortunately it will only work for
> a finite size stack (see the comments in mpatrol/src/config.h) but it'll get
> you up and running, I hope.  It doesn't always work on all platforms but
> it's worth you giving it a try.
>
>
>
> Good luck,
>
>
>
> Graeme.
>
>
>
>   _____
>
> From: Sagar [mailto:sagarseth@...]
> Sent: 14 November 2008 12:51
> To: graeme_roy@...
> Subject: Re: [mpatrol] mpatrol 64 bit issue ....
>
>
>
> Hi Friend,
>
> Can u show me where is the
> "source code for getting stack tracebacks in 32 bit"
>
> I can try to put effort for developing the source for 64 bit..
>
> may be i can help u in developing 64 bit version.....
>
> i got a free weekend ...
>
> Sagar
>
> On 11/14/08, Graeme Roy <graeme_roy@...> wrote:
>> Hi,
>>
>> Yes, it sounds like there's been no support added for stack tracebacks on
>> 64-bit x86.  The 32-bit x86 code will not work, as you have found out and
> I
>> haven't written support for 64-bit x86 as I don't have access to it.
>>
>> If anyone has written the extra source code for getting stack tracebacks
> to
>> work for mpatrol on that architecture could they post it here?  It should
>> only be a few lines of diffs anyway, compared to what I'd expect support
> for
>> Itanium to be.
>>
>> Thanks,
>>
>> Graeme.
>>
>>   _____
>>
>> From: mpatrol@yahoogroups.com [mailto:mpatrol@yahoogroups.com] On Behalf
> Of
>> Sagar
>> Sent: 11 November 2008 11:11
>> To: mpatrol@yahoogroups.com
>> Subject: [mpatrol] mpatrol 64 bit issue ....
>>
>>
>>
>> Hello Graeme,
>>
>> Thanks for the update ,, we took the target.h file and places where
>> the ARCH and ENVIRON variables were defined .. we did a undef and
>> redefined them to ARCH_IX86 and ENVIRON_64.
>>
>> CPUs in the box are AMD opteron 275.
>>
>> Now we are getting a core for mpatrol .
>>
>> When we did the analysis on the core then I am getting
>> #0 0x0000002a9567cab4 in __mp_getframe () from /src/lib64/libmpatrol.so
>>
>> What could be wrong .
>>
>> .....-----------------
>>
>> Glad to hear it's working OK for you, at least on one of your machines.
>>
>> For SuSE Enterprise 64-bit, I assume that it's running on Intel Core 2 Duo
>
>> and is therefore x86-64 (and not Itanium). mpatrol has been ported to
>> 64-bit architectures before (MIPS and SPARC for example) but I don't know
> if
>> anything's been done by anyone to port it to 64-bit x86 (i.e. running in a
>
>> 64-bit environment and not just under a 32-bit OS). For example, the stack
>
>> reading code will most likely be different which is probably why you're
> not
>> getting any location information for the allocations.
>>
>> Has anyone here run mpatrol on a 64-bit x86 architecture and got stack
>> tracebacks to work? I imagine there won't be too many changes to make
> (just
>> ensure that ARCH = ARCH_IX86 and ENVIRON = ENVIRON_64 when building
> mpatrol)
>> - just look for ENVIRON_64 in the mpatrol source code to see where I did
> the
>> changes for MIPS and SPARC. I don't have access to a 64-bit OS at the
>> moment so I can't really help much.
>>
>>
>>
>>
>
>
>
> --
> Thanks and Regards
> Sagar
>
>
>
>
> --
> Thanks and Regards
> Sagar
>


--
Thanks and Regards
Sagar

Hello Friend ,,

I am confused ... from what i see inside the code i need to re-write

1. struct frameinfo and stackinfo ( for 64bit)
2. then need to write the getaddr unwind getframe and all other
functions in stack.c

right ???

please help with some documentation.. better will be an example ..

here is something useful that i found over the weekend ,... please
have look ,, let me know about further steps...


thanks in advance...
Seth




From: Graeme Roy <graeme_roy@...>
Date: Fri, 14 Nov 2008 22:09:22 -0000
Subject: RE: [mpatrol] mpatrol 64 bit issue ....
To: Sagar <sagarseth@...>

Hi,



If you've got the time to have a look, the code for all the stack tracebacks
is in mpatrol/src/stack.c.  Just look for the x86-specific code - there's
not much because for 32-bit x86 it's really easy, you just follow the chain
of frame pointers.  Daniel from CodeSourcery replied to the mpatrol group as
well, suggesting that it's a lot more complicated for 64-bit x86 since you
have to look at the .eh_frame section in the executable file and any shared
libraries.



What you could do is try defining MP_BUILTINSTACK_SUPPORT when you build the
mpatrol library.  This will make gcc plant some code to help traverse the
stack instead of using mpatrol's code.  Unfortunately it will only work for
a finite size stack (see the comments in mpatrol/src/config.h) but it'll get
you up and running, I hope.  It doesn't always work on all platforms but
it's worth you giving it a try.



Good luck,



Graeme.



   _____

From: Sagar [mailto:sagarseth@...]
Sent: 14 November 2008 12:51
To: graeme_roy@...
Subject: Re: [mpatrol] mpatrol 64 bit issue ....



Hi Friend,

Can u show me where is the
"source code for getting stack tracebacks in 32 bit"

I can try to put effort for developing the source for 64 bit..

may be i can help u in developing 64 bit version.....

i got a free weekend ...

Sagar

On 11/14/08, Graeme Roy <graeme_roy@...> wrote:
> Hi,
>
> Yes, it sounds like there's been no support added for stack tracebacks on
> 64-bit x86.  The 32-bit x86 code will not work, as you have found out and
I
> haven't written support for 64-bit x86 as I don't have access to it.
>
> If anyone has written the extra source code for getting stack tracebacks
to
> work for mpatrol on that architecture could they post it here?  It should
> only be a few lines of diffs anyway, compared to what I'd expect support
for
> Itanium to be.
>
> Thanks,
>
> Graeme.
>
>   _____
>
> From: mpatrol@yahoogroups.com [mailto:mpatrol@yahoogroups.com] On Behalf
Of
> Sagar
> Sent: 11 November 2008 11:11
> To: mpatrol@yahoogroups.com
> Subject: [mpatrol] mpatrol 64 bit issue ....
>
>
>
> Hello Graeme,
>
> Thanks for the update ,, we took the target.h file and places where
> the ARCH and ENVIRON variables were defined .. we did a undef and
> redefined them to ARCH_IX86 and ENVIRON_64.
>
> CPUs in the box are AMD opteron 275.
>
> Now we are getting a core for mpatrol .
>
> When we did the analysis on the core then I am getting
> #0 0x0000002a9567cab4 in __mp_getframe () from /src/lib64/libmpatrol.so
>
> What could be wrong .
>
> .....-----------------
>
> Glad to hear it's working OK for you, at least on one of your machines.
>
> For SuSE Enterprise 64-bit, I assume that it's running on Intel Core 2 Duo

> and is therefore x86-64 (and not Itanium). mpatrol has been ported to
> 64-bit architectures before (MIPS and SPARC for example) but I don't know
if
> anything's been done by anyone to port it to 64-bit x86 (i.e. running in a

> 64-bit environment and not just under a 32-bit OS). For example, the stack

> reading code will most likely be different which is probably why you're
not
> getting any location information for the allocations.
>
> Has anyone here run mpatrol on a 64-bit x86 architecture and got stack
> tracebacks to work? I imagine there won't be too many changes to make
(just
> ensure that ARCH = ARCH_IX86 and ENVIRON = ENVIRON_64 when building
mpatrol)
> - just look for ENVIRON_64 in the mpatrol source code to see where I did
the
> changes for MIPS and SPARC. I don't have access to a 64-bit OS at the
> moment so I can't really help much.
>
>
>
>



--
Thanks and Regards
Sagar




--
Thanks and Regards
Sagar

On Fri, Nov 14, 2008 at 11:40:45AM -0000, Graeme Roy wrote:
> Hi,
>
> Yes, it sounds like there's been no support added for stack tracebacks on
> 64-bit x86.  The 32-bit x86 code will not work, as you have found out and I
> haven't written support for 64-bit x86 as I don't have access to it.
>
> If anyone has written the extra source code for getting stack tracebacks to
> work for mpatrol on that architecture could they post it here?  It should
> only be a few lines of diffs anyway, compared to what I'd expect support for
> Itanium to be.

I don't have such code, but what I'd recommend is using either
libunwind or just libgcc; x86_64 is special in that the platform ABI
requires presence of .eh_frame unwind tables, so that compilers have
more freedom in stack layout than they do on x86.

--
Daniel Jacobowitz
CodeSourcery