arneme@nic.uit.no (Arne Munch-Ellingsen) (07/10/90)
I am working on a fairly large thinkC project that divides the code into 8 code segments. Trying to debug the project I single steps the program using the "step" and "in" commands up to the following statement: button_name = (char *)malloc( maximum_name_length + 1 ); Using the Data window gives this value for maximum_name_length: maximum_name_length = 27 The call to malloc never returns, the mac hangs on me. This makes me wonder about how thinkC handles it's CODE segments. It seems to me that the CODE segment from where malloc is called is relocated while the malloc is executing. On return from malloc the return address is taken from the stack, and oops, the CODE segment is not there anymore. I had another problem of this sort, running code in CODE segment 1, calling a routine in another segment resulted in a jump to an address where the code for the called routine was not located. Moving the file in question to CODE segment 1 resulted in that the routine was found and executed without problems. I am not doing any UnloadSeg or GetResource calls in my program source. Has anyone experienced similar behavior when using thinkC, or is it probable that my guess on what is happening is far out? Arne.
jholt@adobe.COM (Joe Holt) (07/11/90)
Code resources are never unlocked unless you explicitly UnloadSeg(). Even in such a case, as soon as code begins executing in that segment, it is locked down and stays locked until another UnloadSeg() -- again, explicitly by you. It would be disastrous if code segments could move around between calls with no OS support! Remember, tho', that unlocked handles may move. Be careful passing a dereferenced handle which is unlocked to a routine in another segment. Even if that routine doesn't move memory, simply calling it may. Yikes. This reminds me of Microsoft Windows 3.0's approach to code segments. They *can* move around between calls, but Windows has a daemon which actually walks the return stack and patches addresses so that they jive. Zowie. -- joe
oster@well.sf.ca.us (David Phillip Oster) (07/18/90)
In article <3806@adobe.UUCP> jholt@adobe.com (Joe Holt) writes: >This reminds me of Microsoft Windows 3.0's approach to code segments. They >*can* move around between calls, but Windows has a daemon which actually >walks the return stack and patches addresses so that they jive. Zowie. Ouch. My C coding style uses lots of pointers to functions as arguments, and lots of data structures using pointers to functions. I can understand walking the calling stack looking at the return addresses and fixing them up, but unless the C compiler pushes a type descriptor for every argument, it can't tell if an arbitrary argument is a long integer or a procedure pointer. How is it going to know to adjust it? And how about pointers sitting in data structures just waiting to be executed? I suppose the C compiler could put every entrypoint it knew about into a jump table, but then its assembler would have to include an ENTRYPOINT meta command, so I could create entrypoints in assembly langauge that didn't use the C calling conventions. What a nightmare! -- -- David Phillip Oster - Note new address. Old one has gone Bye Bye. -- oster@well.sf.ca.us = {backbone}!well!oster