Hi John,

Yes, mpatrol hasn't been ported to the ARM architecture by me but it
looks like you (or someone at MontaVista?) have got most of it
working judging from the stack traces.

There's some instructions on how to convert libiberty from an archive
library to a shared library hidden away in paragraph six at:

http://www.cbmamiga.demon.co.uk/mpatrol/mpatrol_32.html

But that's assuming that you don't need position independent code
within a shared library on ARM and that you're using the GNU linker,
which you probably are if you're on linux.

If you convert libiberty.a to libiberty.so successfully, you might
want to try not compiling mpatrol with the -finline-functions
switch. Because of the way it performs stack tracebacks, mpatrol
needs to ensure that it knows where it's looking on the stack and
function inlining with the mpatrol source code can break that
assumption. That's perhaps why it's failing for you. Function
inlining within non-mpatrol source code is perfectly OK.

It looks from the log file that you supplied that the memcpy calls
stemming from __do_global_ctors_aux are copying overlapping memory
locations (which should be using memmove) and copying from outside
the allocated buffer. Is this from code within GTK or from within
your application? If this is failing to copy then that's perhaps why
the segmentation fault occurs. You can ignore the errors attempting
to perform operation on free memory at the bottom of the log file
since they are zero-byte operations.

I'm sure there are lots of other possible reasons but this is the one
that jumps out at me. I haven't ever tried using GTK with mpatrol
but perhaps other people on this list have and have had similar
problems, or successes?

And no, you shouldn't have to recompile anything with mpatrol in your
application if you're using the --dynamic option. As long as all of
the executable files and shared libraries have symbols (i.e. not
stripped), you're calling the standard C/C++ memory allocators and
you can get libiberty.so built then you shouldn't have to recompile
anything. You can do so if you wish in order to get more detailed
information in the log file. The following page lists the steps
required to integrate mpatrol into your application, in order of
intrusiveness:

http://www.cbmamiga.demon.co.uk/mpatrol/mpatrol_6.html

Good luck,

Graeme.

--- In mpatrol@yahoogroups.com, "john_boncek" <jboncek@...> wrote:
>
> I am attempting to use MPatrol with MontaVista Linux C++ on PXA270
> (ARM architecture). MontaVista included MPatrol in the
distribution
> but provided no information on how to use it or whether it had even
> been tested. (We have since dropped their useless technical
support.)
>
> I tried to run one of our massive multi-threaded GTK applications
> using the command:
>
> mpatrol --dynamic --threads /opt/hunter/bin/aligner.bin
>
> but it complained it couldn't find libiberty.so. This library is
> provided in our distribution only in .a form. So I have recompiled
> the app without optimization adding "-include mpatrol.h -finline-
> functions" to the compile directives, and adding the libraries
> mpatrolmt, bfd, and iberty to the link directives. This allowed
> compilation and linkage after I changed the mpatrol.h file very
> slightly to force it to select this definition for MP_INLINE:
>
> #define MP_INLINE extern inline
>
> Running the recompiled app produces a short log file that looks
like
> it might contain useful information if run to completion but it seg
> faults in gtk_init very early in the run. Here is the log:
>
> ...
>
> Is GTK incompatible with MPatrol? Do all libraries used (such as
> GTK) have to be recompiled with the MPatrol header? Any other
> ideas? I realize this is not an architecture stated as supported
in
> your documentation but it comes close enough to working that it
seems
> it might be useful to try further.
>