Having problems with message search?
Hi Fahri,
You don’t have much physical memory
on your chip, so you won’t have very much available to your process after
the operating system eats some of it up, although at least it looks from the
log file that your program is now running to completion, albeit with errors in
free().
I would suggest building mpatrol with –DFORMAT=FORMAT_NON
Because you don’t have enough memory
to run mpatrol with it recording symbolic stack traces, you need to include
mpatrol.h in your source files to get at least some indication of where the
allocations come from in the log file. You may hit a problem with mpatrol.h
and the macro overriding of operator new and delete. I’ve got no idea
why “16384” is displaying instead of the function name. Perhaps
gcc’s __PR
It’s possible that the errors you’re
seeing at the end of the log file are coming from the
Good luck,
Graeme.
From:
mpatrol@yahoogroups.com [mailto:mpatrol@yahoogroups.com] On Behalf Of fsoenmez
Sent: 15 May 2008 14:09
To: mpatrol@yahoogroups.com
Subject: [mpatrol] Re:
Hi Graeme,
thanks much for your response.
This is our system:
CPU: MPC5200B
RAM: 64 MB = 32 MB RAM + 32 MB Filesystem
OS:
We translated the mpatrol lib with debuginfo +
MP_BUILTINTSTACK_
__mp_getframe (stackinfo * p) -> returnaddresses (p-> addrs, f,
MP_MAXSTACK (line 424) crashed. And if we translated mpatrol lib with
debuginfo without MP_BUILTINTSTACK_
signals.c: 82 static void signalhandler (int s, int c, struct
sigcontext * n, void * f) crashed. We could translated the lib with
debugging information and MP_LIBRARYSTACK_
@(#) mpatrol 1.4.8 (02/01/08)
Copyright (C) 1997-2002 Graeme S. Roy
This is free software, and you are welcome to redistribute it under
certain
conditions; see the GNU Library General Public License for details.
For the latest mpatrol release and documentation,
visit http://www.cbmamiga
operating system: UNIX
system variant: Linux
processor architecture: PowerPC
processor word size: 32-bit
object file format: BFD
dynamic linker type: Unknown
Log file generated on Sat Jan 1 00:12:04 2000
read 7968 symbols from CXAppl
ALLOC: operator new (42, 18 bytes, 8 bytes) [16384|-|-|-
returns 0x10272398
ALLOC: operator new (43, 30 bytes, 8 bytes) [16384|-|-|-
returns 0x102723B0
FR
0x10272398 (18 bytes)
ALLOC: malloc (44, 376 bytes, 8 bytes) [16384|-|-|-
....
....
....
....
system page size: 4096 bytes
default alignment: 8 bytes
overflow size: 0 bytes
overflow byte: 0xAA
allocation byte: 0xFF
free byte: 0x55
allocation stop: 0
reallocation stop: 0
free stop: 0
unfreed abort: 0
small boundary: 32 bytes
medium boundary: 256 bytes
large boundary: 2048 bytes
lower check range: 0
upper check range: 0
check frequency: 1
failure frequency: 0
failure seed: 946685524
prologue function: <unset>
epilogue function: <unset>
handler function: <unset>
log file: mpatrol.log
profiling file: mpatrol.out
tracing file: mpatrol.trace
program filename: CXAppl
symbols read: 7968
autosave count: 0
freed queue size: 0
allocation count: 13107
allocation peak: 1690 (2208295 bytes)
allocation limit: 0 bytes
allocated blocks: 722 (919416 bytes)
marked blocks: 0 (0 bytes)
freed blocks: 0 (0 bytes)
free blocks: 439 (1476744 bytes)
internal blocks: 71 (1163264 bytes)
total heap usage: 3559424 bytes
total compared: 76625 bytes
total located: 40 bytes
total copied: 665124 bytes
total set: 571780 bytes
total warnings: 0
total errors: 10
Square brackets include no right information.
Kind regards & thank you Fahri
--- In mpatrol@yahoogroups
>
> Hi,
>
> As long as you don't use the following mpatrol options, then your
> program's heap will be reasonably compact, as you'd expect:
>
> NOFR
>
> However, the library will still use quite a lot of memory for its
> internal record-keeping, such as symbolic stack traces, profiling,
> tracing, etc. You don't really have any control over whether mpatrol
> reads symbols or not, but you could always recompile the library to
> disable that, probably saving quite a lot of memory but losing that
> capability. The following options will increase the amount of memory
> mpatrol uses internally:
>
> PROF, TRAC
>
> You mention that the program should "log on further and not stop when
> not being loaded completely". Is it stopping because you're running
> out of memory? How much memory do you have available on your embedded
> system? What is the OS that it's running on? Is it an embedded Linux
> such as ucLinux?
>
> Remember that you don't need to log everything from mpatrol. If there
> is an error, mpatrol will log it automatically. If the log file is
> being placed in a ram disk on your system then cutting the size of the
> log file might give you more memory to run your program.
>
> Graeme.
>
> --- In mpatrol@yahoogroups
> >
> > Hi,
> >
> > on our PowerPC we start our software with mpatrol, which creates a
> > very big logfile (105 MB). The memory allocation grows to big (twice
> > as big as usually). The program should log on further and not stop
> > when not being loaded completely.
> >
> > Does anybody have an idea how it can be avoided that the program
stops
> > and needs such a big memory allocation?
> > What do you suggest to get an acceptable result?
> >
> > Kind regards & thank you
> >
> > Fahri
> >
>
Offline 
Send Email