dan@bbn.com (Dan Franklin) (02/16/90)
In reply to gandalf@csli.stanford.edu, who writes: > I also encountered some strange "Segmentation faults" with some of my > (dynamically linked) programs, which go away if I use -Bstatic. However, > I am not sure whether these bugs are due to bugs in the libraries or the > library handling, or whether the bugs are in my programs... I had the same problem when we first tried to use undump on a SunOS 4.0 executable. From poking around, it seems to be a misfeature of 4.0 shared libraries that is impossible to work around (reliably). The problem is initialized data associated with shared library routines. If your process changes such data before you core-dump it to make the new executable, the executable won't work because when it starts up, it will link in the shared library with the *original* (=wrong) value of the shared data. This happens because static data associated with shared library routines is not core-dumped (and even if it were, it would be difficult to restore to the right place across shared library updates). Dynamic memory allocation breaks immediately. The sbrk() library routine has a word of initialized data that's set to &end when your executable starts up, and increased by each sbrk() to continue to point to the end of your data space. Core-dumping the process loses the updated value. When you start up the undumped version, it will have the enlarged data space, but sbrk() will have its original &end value. Calls to sbrk() will return the same addresses they did before. Since malloc() calls sbrk(), this is a serious problem! I actually hacked around that one, and tried again--then sbrk() worked fine, but malloc() core dumped after a few hundred calls. It too has initialized data, where it sets up its initial storage heap, so I assume that was the problem. I was probably trying to free() something allocated in the earlier execution, though I wasn't really sure. I didn't try to hack around that problem; the trend was clear. I just used -Bstatic from then on. Dan Franklin
viktor@melon.princeton.edu (Viktor Dukhovni) (02/17/90)
While indeed undump may be tricky for Dynamic executables under SunOS 4.0, I am sure it is not impossible. I have just sent a shared library "unexec" to be used with emacs 19.0 to the FSF, I am using it now to reliably build a shared emacs-18.55 Emacs uses its own malloc, so all one needs to do on entry is adjust the break. I had at one point been undumping TeX succesfully with 4.0.1 again (undump needed some modification), but this was made easy by the fact that TeX does not use malloc. I have not tries to unexec any executables that use the shared malloc, so I cannot comment on how this might be done. I approach would be to use your own malloc and link it statically into any program you plan to undump. Viktor Dukhovni <viktor@math.princeton.edu> : ARPA <...!uunet!princeton!math!viktor> : UUCP Fine Hall, Washington Rd., Princeton, NJ 08544 : US-Post +1-(609)-258-5792 : VOICE