Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.apple2.programmer > #5477 > unrolled thread

Orca/C malloc

Back to article view | Back to comp.sys.apple2.programmer

Contents

  Orca/C malloc Chris Vavruska <vavruska@gmail.com> - 2020-04-05 13:28 -0700
    Re: Orca/C malloc Stephen Heumann <stephen.heumann@gmail.com> - 2020-04-05 20:56 -0500
      Re: Orca/C malloc Chris Vavruska <vavruska@gmail.com> - 2020-04-05 20:05 -0700
        Re: Orca/C malloc Stephen Heumann <stephen.heumann@gmail.com> - 2020-04-05 22:55 -0500
          Re: Orca/C malloc Chris Vavruska <vavruska@gmail.com> - 2020-04-06 16:14 -0700
            Re: Orca/C malloc Chris Vavruska <vavruska@gmail.com> - 2020-04-06 16:35 -0700
              Re: Orca/C malloc Stephen Heumann <stephen.heumann@gmail.com> - 2020-04-06 21:59 -0500
                Re: Orca/C malloc Chris Vavruska <vavruska@gmail.com> - 2020-04-08 16:38 -0700

#5477 — Orca/C malloc

I know that malloc is implemented in orca/c by having the memory manager alloc a large block and divide it up based on malloc allocations. When I use malloc in an application it works just fine, but if I take the same code an try to run it in an NDA/CDEV it runs into issues, ie hangs and crashes. Is there a reason for this? Is the C memory manager not initialized for a NDA/CDEV? Could the memory be moved around so the pointers are no longer valid? I have worked around this by using NewHandle and dereferencing the handle to get the pointer.

[toc] | [next] | [standalone]

#5478

On 2020-04-05 20:28:03 +0000, Chris Vavruska said:

> I know that malloc is implemented in orca/c by having the memory 
> manager alloc a large block and divide it up based on malloc 
> allocations. When I use malloc in an application it works just fine, 
> but if I take the same code an try to run it in an NDA/CDEV it runs 
> into issues, ie hangs and crashes. Is there a reason for this? Is the C 
> memory manager not initialized for a NDA/CDEV? Could the memory be 
> moved around so the pointers are no longer valid? I have worked around 
> this by using NewHandle and dereferencing the handle to get the pointer.

AFAIK, malloc should work in an NDA or CDEV written with ORCA/C, and 
I'm not aware of a bug that would cause the problems you are seeing.

The ORCA libraries, including the memory management code, do require 
initialization.  If the NDA/CDEV is written in ORCA/C using the 
corresponding pragma, then the generated .root file should contain 
calls to do the necessary initialization.  If not (e.g. if you are 
calling C subroutines from a main program written in assembly), then 
you may need to manually initialize things.  There is some 
documentation about this in the ORCA/M release notes (Asm65816.notes).

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5480

On Sunday, April 5, 2020 at 9:56:59 PM UTC-4, Stephen Heumann wrote:
> On 2020-04-05 20:28:03 +0000, Chris Vavruska said:
> 
> > I know that malloc is implemented in orca/c by having the memory 
> > manager alloc a large block and divide it up based on malloc 
> > allocations. When I use malloc in an application it works just fine, 
> > but if I take the same code an try to run it in an NDA/CDEV it runs 
> > into issues, ie hangs and crashes. Is there a reason for this? Is the C 
> > memory manager not initialized for a NDA/CDEV? Could the memory be 
> > moved around so the pointers are no longer valid? I have worked around 
> > this by using NewHandle and dereferencing the handle to get the pointer.
> 
> AFAIK, malloc should work in an NDA or CDEV written with ORCA/C, and 
> I'm not aware of a bug that would cause the problems you are seeing.
> 
> The ORCA libraries, including the memory management code, do require 
> initialization.  If the NDA/CDEV is written in ORCA/C using the 
> corresponding pragma, then the generated .root file should contain 
> calls to do the necessary initialization.  If not (e.g. if you are 
> calling C subroutines from a main program written in assembly), then 
> you may need to manually initialize things.  There is some 
> documentation about this in the ORCA/M release notes (Asm65816.notes).
> 
> -- 
> Stephen Heumann

I did some deeper diving and think part of the issue is that I am loading code from a CodeResource and executing it. If I do that MMStartUp return a zero value where as MMStartup returns a valid value. 
I will take a look at the the orca/m release notes to see if I can figure it out.

[toc] | [prev] | [next] | [standalone]

#5482

On 2020-04-06 03:05:06 +0000, Chris Vavruska said:

> I did some deeper diving and think part of the issue is that I am 
> loading code from a CodeResource and executing it. If I do that 
> MMStartUp return a zero value where as MMStartup returns a valid value.
> I will take a look at the the orca/m release notes to see if I can 
> figure it out.

You will definitely need to have a valid user ID in order to use malloc 
(since it internally calls NewHandle and needs to provide a user ID).  
If your code does not automatically get a user ID at startup, you may 
need to allocate one by calling GetNewID.  You could then tell the ORCA 
libraries to use that ID by calling SystemUserID (documented in the 
ORCA/C manual or the ORCA/M release notes).

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5483

On Sunday, April 5, 2020 at 11:55:18 PM UTC-4, Stephen Heumann wrote:
> On 2020-04-06 03:05:06 +0000, Chris Vavruska said:
> 
> > I did some deeper diving and think part of the issue is that I am 
> > loading code from a CodeResource and executing it. If I do that 
> > MMStartUp return a zero value where as MMStartup returns a valid value.
> > I will take a look at the the orca/m release notes to see if I can 
> > figure it out.
> 
> You will definitely need to have a valid user ID in order to use malloc 
> (since it internally calls NewHandle and needs to provide a user ID).  
> If your code does not automatically get a user ID at startup, you may 
> need to allocate one by calling GetNewID.  You could then tell the ORCA 
> libraries to use that ID by calling SystemUserID (documented in the 
> ORCA/C manual or the ORCA/M release notes).
> 
> -- 
> Stephen Heumann

That seems to have done the trick. Thanks Stephen!

[toc] | [prev] | [next] | [standalone]

#5484

On Monday, April 6, 2020 at 7:14:22 PM UTC-4, Chris Vavruska wrote:
> On Sunday, April 5, 2020 at 11:55:18 PM UTC-4, Stephen Heumann wrote:
> > On 2020-04-06 03:05:06 +0000, Chris Vavruska said:
> > 
> > > I did some deeper diving and think part of the issue is that I am 
> > > loading code from a CodeResource and executing it. If I do that 
> > > MMStartUp return a zero value where as MMStartup returns a valid value.
> > > I will take a look at the the orca/m release notes to see if I can 
> > > figure it out.
> > 
> > You will definitely need to have a valid user ID in order to use malloc 
> > (since it internally calls NewHandle and needs to provide a user ID).  
> > If your code does not automatically get a user ID at startup, you may 
> > need to allocate one by calling GetNewID.  You could then tell the ORCA 
> > libraries to use that ID by calling SystemUserID (documented in the 
> > ORCA/C manual or the ORCA/M release notes).
> > 
> > -- 
> > Stephen Heumann
> 
> That seems to have done the trick. Thanks Stephen!

One question. Should GetNewId(0x5000) be returning a zero? 

[toc] | [prev] | [next] | [standalone]

#5485

On 2020-04-06 23:35:47 +0000, Chris Vavruska said:

> One question. Should GetNewId(0x5000) be returning a zero?

No, it should be returning an ID of the form $50xx.

About the only reason I can think of that it would fail is if you have 
allocated so many IDs that no more are available (which would be 
indicated by a tool error code).

You should generally only allocate one ID at the beginning of your 
program, and then call DisposeAll followed by DeleteID at the end of 
the program to deallocate all memory using that ID and then free the ID 
itself.  (And again, these manual steps are only necessary if you are 
not starting the program via the normal initialization code generated 
by ORCA/C.)

-- 
Stephen Heumann

[toc] | [prev] | [next] | [standalone]

#5487

On Monday, April 6, 2020 at 10:59:43 PM UTC-4, Stephen Heumann wrote:
> On 2020-04-06 23:35:47 +0000, Chris Vavruska said:
> 
> > One question. Should GetNewId(0x5000) be returning a zero?
> 
> No, it should be returning an ID of the form $50xx.
> 
> About the only reason I can think of that it would fail is if you have 
> allocated so many IDs that no more are available (which would be 
> indicated by a tool error code).
> 
> You should generally only allocate one ID at the beginning of your 
> program, and then call DisposeAll followed by DeleteID at the end of 
> the program to deallocate all memory using that ID and then free the ID 
> itself.  (And again, these manual steps are only necessary if you are 
> not starting the program via the normal initialization code generated 
> by ORCA/C.)
> 
> -- 
> Stephen Heumann

Turns out it was the debugger giving the wrong value. I am sure I confused it by having the same variable name in both the main code as well as the rCodeResource code.

Thanks...all is well now.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.sys.apple2.programmer

csiph-web