Portability issues in using a memory dump

Portability issues in using a memory dump

Post by Bharat Venkatasubramani » Sat, 19 Dec 1992 07:24:02



Folks!

I have a wierd problem.  I would like to dump the contents of a chunk of
contiguous memory locations.   The contents represent some complex graph
structure which once built is constant over different invocations of the
program.

Instead of traversing the graph and dumping its contents, I would like to
dump the contents of this contiguous memory.  Subsequent invocations of
this program could then use mmap() system call to map the information in
this file to the address used when the file was first created.  This would
also preserve the pointer addresses since I am using the same address
space that was used during the creation of this memory dump.  The program
has static behavior until the creation of this graph and so on the same
machine I will definitely be able to guarantee the availability of that
address space.  One of my concerns is will the address space be different
on different Operating Systems??

If any of you folks have tried something like this before, I would appreciate
it if you could share the problems/pitfalls with this solution.


Thanks in advance.

Bharat

 
 
 

Portability issues in using a memory dump

Post by der Mou » Wed, 23 Dec 1992 01:58:35



Quote:> I have a wierd problem.  I would like to dump the contents of a chunk
> of contiguous memory locations.   The contents represent some complex
> graph structure which once built is constant over different
> invocations of the program.
> Instead of traversing the graph and dumping its contents, I would
> like to dump the contents of this contiguous memory.  Subsequent
> invocations of this program could then use mmap() system call to map
> the information in this file to the address used when the file was
> first created.

It's a bit ugly, but it should be workable on most systems.  Sendmail
does something similar with its frozen config files.

Quote:> The program has static behavior until the creation of this graph and
> so on the same machine I will definitely be able to guarantee the
> availability of that address space.

Are you sure?  Part of that space is probably already occupied by
data/bss.  You'd probably be better off using brk() to set the break to
the appropriate place and then just read()ing in the file.  Be careful
to use only automatic variables....

Unless you are specifically allocating a block of memory for this
purpose, and want to save and restore only that block.  You still may
be better off with read than mmap, if for no other reason than some
systems don't have mmap.

Quote:> One of my concerns is will the address space be different on
> different Operating Systems??

Yes.  The difference is usually fairly minor; most UNIXish systems just
give you text/data/stack at runtime, so if you dump out the data
segment you should be OK, even though the data segment may begin at a
different address and be a different size from system to system.  If
you encounter a system that doesn't fit this model, you may have to
abandon this technique.  (On SunOS 4.x, for example, you will likely
have to link -Bstatic if you want to dump the whole data segment,
because otherwise pieces of the conceptual data segment are up at
random addresses thanks to shared object files being brought in at
run-time.)

                                        der Mouse



 
 
 

Portability issues in using a memory dump

Post by Donn Ca » Wed, 23 Dec 1992 11:03:20



|> I have a wierd problem.  I would like to dump the contents of a chunk
|> of contiguous memory locations.   The contents represent some complex
|> graph structure which once built is constant over different
|> invocations of the program.

|> Instead of traversing the graph and dumping its contents, I would
|> like to dump the contents of this contiguous memory.  Subsequent
|> invocations of this program could then use mmap() system call to map
|> the information in this file to the address used when the file was
|> first created.

| It's a bit ugly, but it should be workable on most systems.  Sendmail
| does something similar with its frozen config files.

Beauty is in the eye of the beholder, I guess.  I've done it, with a tree
structure, and I thought it was rather cute.

|> The program has static behavior until the creation of this graph and
|> so on the same machine I will definitely be able to guarantee the
|> availability of that address space.

| Are you sure?  Part of that space is probably already occupied by
| data/bss.
Part of what space?  He should dump the entire address space, for what?

| Unless you are specifically allocating a block of memory for this
| purpose, and want to save and restore only that block.  You still may
| be better off with read than mmap, if for no other reason than some
| systems don't have mmap.

Specifically allocating a block of memory is likely to be a more
productive strategy, although you do have to ensure that everything that
matters gets allocated from that block.  As for mmap(), not only do some
systems not have it, but it doesn't seem to behave identically between
systems that do.  However, I would suggest starting with mmap(), since
that puts some extra constraints on the problem (e.g., page alignment),
and then add read() (and write()) alternatives if it proves necessary.
It's not greatly different, mmap = read, close = write, and those nice
#ifdefs make your code more readable.  The mmap() incompatibilities I
alluded to aren't severe; no use asking me what they are, as I have
forgotten everything.

|> One of my concerns is will the address space be different on
|> different Operating Systems??

| Yes.  The difference is usually fairly minor; most UNIXish systems just
| give you text/data/stack at runtime, so if you dump out the data
| segment you should be OK, even though the data segment may begin at a
| different address and be a different size from system to system.  If
| you encounter a system that doesn't fit this model, you may have to
| abandon this technique.  (On SunOS 4.x, for example, you will likely
| have to link -Bstatic if you want to dump the whole data segment,
| because otherwise pieces of the conceptual data segment are up at
| random addresses thanks to shared object files being brought in at
| run-time.)

On the other hand, if you don't aspire to dump the whole data segment, but
rather have a discrete chunk of data that's supposed to reside at a particular
address, and you have allocated the memory required for that, then the
address space is exactly the same, right?  To me, this seems like the way
to go.  Do consider labelling the data, inside the file, with some information
about the starting address and extent of your data - at least then when you
recompile the program and change addresses, your program can tell you that
you have obsoleted your old data.

        Donn Cave, University Computing Services, University of Washington

 
 
 

Portability issues in using a memory dump

Post by Gordon Burdi » Thu, 24 Dec 1992 05:42:38


Quote:>Yes.  The difference is usually fairly minor; most UNIXish systems just
>give you text/data/stack at runtime, so if you dump out the data
>segment you should be OK, even though the data segment may begin at a
>different address and be a different size from system to system.  If

One of the biggest ugly problems with this technique is saving
and later restoring data that you don't know exists.  Some of
the things you might end up restoring are:

- Your terminal type, and internal curses/termcap/terminfo variables
related to it.  Bad news if you restart on a different terminal type.
- Stdio information about open files that aren't open in the restoring
process.  This often includes the FILE * stream used to save the data.
- On fixed-stack machines, your stack and all auto variables may be
included in what you are restoring.  KABOOM!
- Environment variables, or copies made of them by library routines.
- Malloc and sbrk's records of memory allocation.

At least one version of the game rogue used this technique, although
it tried saving data AND bss AND malloc space.  I rapidly learned to
hate it.  Save/restore cycles ended up leaking memory, FILE * descriptors,
and after a couple dozen cycles, the game generally fell apart with
SIGSEGV's.

                                        Gordon L. Burditt
                                        sneaky.lonestar.org!gordon

 
 
 

1. AIX Kernel Dump: Is this a paging/memory issue?

When running jagsrv (executable), the AIX 4.3 (RS/6000 machine with 128
MB RAM) freezes.
Does this look like a memory issue? or a file system issue? Any ideas?

Thanks,
Meyer

# crash vmcore.4
Using /unix as the default namelist file.
SLT ST    PID   PPID   PGRP   UID  EUID  TCNT  NAME
  2 a     204      0      0     0     0     1  wait
        FLAGS: swapped_in no_swap fixed_pri kproc
 22 a    1632      1   1632     0     0     1  errdemon
        FLAGS: swapped_in orphanpgrp signochld
 64 a    4082   389a   3a92 41007 41007    17  jagsrv
        FLAGS: swapped_in orphanpgrp execed
STACK TRACE:
0xf0002b20 (excpt=bf01ff94:40000000:60000ee2:bf01ff94:00000106)
(intpri=0)
        IAR:      ._moveeq+84 (0011fc04):    lwzu   r7,0x4(r4)
        LR:       .thread_getregs+1f4 (0000e9e0)
        f03d1fc0: .sys_call_ret+0 (00003a60)
0452-771: Cannot read return address at address 0x208bc1cc.

2. modem init

3. Memory issues in using JNI

4. Star BASIC

5. gcc-2.96/RH7,3 .vs gcc-3.2/RH8.0 portability issues

6. help! route: netmask doesn't match route address

7. G++ portability issues

8. Viewing file in /dosc

9. Portability issues forum

10. Portability issues

11. POSIX Portability issue.

12. Portability issues from UNIX Sys V.4 to AIX

13. using ld memory map for core dumps