I have a cdev that dynamically loads code using initialLoad. In that code I use quite a bit of mallocs to allocate memory. In start up code of my dynamically loaded code I make the following calls to initialize the environment so I can use malloc.

SystemUserID(dataIn->userID, NULL);
SystemMinStack();
SystemEnvironmentInit();


Everything work in my code without issue. On exit from the dynamically loaded code back to the calling CDEV code I sometimes get an error about being low on memory and needing 400kb of memory...but I have allocated 8MB to the system so I know it is not
that. Is there something I need to call to shutdown the environment to prevent this error? I can avoid this error by calling reboot after the code is done but that is not a solution. I never see any sort of memory corruption so I don't believe it is that.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2020-11-22 20:57:49 +0000, [email protected] said:

I have a cdev that dynamically loads code using initialLoad. In that
code I use quite a bit of mallocs to allocate memory. In start up code
of my dynamically loaded code I make the following calls to initialize
the environment so I can use malloc.
SystemUserID(dataIn->userID, NULL);
SystemMinStack();
SystemEnvironmentInit();

Everything work in my code without issue. On exit from the dynamically
loaded code back to the calling CDEV code I sometimes get an error
about being low on memory and needing 400kb of memory...but I have
allocated 8MB to the system so I know it is not that. Is there
something I need to call to shutdown the environment to prevent this
error? I can avoid this error by calling reboot after the code is done
but that is not a solution. I never see any sort of memory corruption
so I don't believe it is that.

You may need to call SystemMMShutDown() at the end of the dynamically
loaded code. That should deallocate everything that it allocated.
Note that this will call DisposeAll() on the user ID that the ORCA
libraries were using (which is the ID you specified or'd with $0100),
so make sure that you are done with anything allocated under that ID
before calling it.

(This is handled automatically in a typical S16/EXE program that exits
by calling exit() or returning from main(), but it sounds like that's
not what you're doing.)

--
Stephen Heumann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Stephen,

I am calling GetNewID(0x5000) rather than just or'ing it with the assigned ID. I narrowed it down a little more in my code which just confuses me more ;) During bootup the cdev load some dynamic code to handle request events...much like a PIF would do.
The PIF and the CDEV will load an additional dynamic code and execute that....and free it when it is done. Calling the dynamic code from the CDEV seems to have no issues. It is on returning from the PIF that seems to cause the finder issues.

On Tuesday, November 24, 2020 at 9:34:15 PM UTC-5, [email protected] wrote:

On 2020-11-22 20:57:49 +0000, [email protected] said:

I have a cdev that dynamically loads code using initialLoad. In that
code I use quite a bit of mallocs to allocate memory. In start up code
of my dynamically loaded code I make the following calls to initialize
the environment so I can use malloc.
SystemUserID(dataIn->userID, NULL);
SystemMinStack();
SystemEnvironmentInit();

Everything work in my code without issue. On exit from the dynamically loaded code back to the calling CDEV code I sometimes get an error
about being low on memory and needing 400kb of memory...but I have allocated 8MB to the system so I know it is not that. Is there
something I need to call to shutdown the environment to prevent this error? I can avoid this error by calling reboot after the code is done
but that is not a solution. I never see any sort of memory corruption
so I don't believe it is that.

You may need to call SystemMMShutDown() at the end of the dynamically
loaded code. That should deallocate everything that it allocated.
Note that this will call DisposeAll() on the user ID that the ORCA
libraries were using (which is the ID you specified or'd with $0100),
so make sure that you are done with anything allocated under that ID
before calling it.

(This is handled automatically in a typical S16/EXE program that exits
by calling exit() or returning from main(), but it sounds like that's
not what you're doing.)

--
Stephen Heumann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2020-11-29 19:29:55 +0000, [email protected] said:

I am calling GetNewID(0x5000) rather than just or'ing it with the assigned ID.

SystemUserID() will internally OR the ID passed to it with $0100. That shouldn't ordinarily cause a problem, but it may be useful to keep in
mind when debugging.

I narrowed it down a little more in my code which just confuses me more
;) During bootup the cdev load some dynamic code to handle request events...much like a PIF would do. The PIF and the CDEV will load an additional dynamic code and execute that....and free it when it is
done. Calling the dynamic code from the CDEV seems to have no issues.
It is on returning from the PIF that seems to cause the finder issues.

Are you expecting the memory for the PIF (both the static code/data and
what it dynamically allocated) to be freed by that point? If so, are
you making calls to do that (e.g. calling UserShutDown after the PIF is
done)?

It sounds like you have a fairly complex setup with several things
taking up memory. If I'm understanding right, you have static
code/data in both the CDEV and the PIF, plus memory dynamically
allocated by each of them. You should think about when each of these
are supposed to be deallocated, and make sure that is happening. It
may be helpful to have separate user IDs for these various classes of
memory to help with that (in particular, the CDEV and the PIF should
definitely have distinct user IDs).

It would also be good to check if your problems are due to the amount
of memory actually being allocated, or if the Memory Manager's data
structures are somehow getting corrupted. Is the overall amount of
memory that appears to be used consistent with what you expect for your
program (all components)? The memory stats in the Finder's "About this
Apple IIgs" window gives an overview of how much memory has been
allocated. Debugging tools like Nifty List can give more detailed
info, including a dump of handles for a specific user ID or of all the allocated handles in the system.

--
Stephen Heumann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

What toolset or library are these calls from? I don't see documentation for them in any of the 3 toolbox volumes?

Thanks.

SystemUserID(dataIn->userID, NULL);
SystemMinStack();
SystemEnvironmentInit();

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2020-12-02 14:39:28 +0000, Paul MacMillan said:

What toolset or library are these calls from? I don't see documentation
for them in any of the 3 toolbox volumes?

Thanks.

SystemUserID(dataIn->userID, NULL);
SystemMinStack();
SystemEnvironmentInit();

These are calls involved with initializing the ORCA libraries. You can
find documentation for them in the ORCA/C manual or the ORCA/M release
notes.

You only need to explicitly call these functions from C code in fairly
unusual circumstances (like what Chris is doing) -- in ordinary
programs, the ORCA compilers will automatically generate the code for
doing this initialization.

--
Stephen Heumann

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)