NetRexxC on Mac OS X

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

NetRexxC on Mac OS X

Bruce Skelly
Hi,

I've noticed a behavior of the NetRexx compiler on Mac OS X, and I  
thought I'd ask those that know the source to think about this.

Environment:

Mac OS X 10.5.8 (Leopard)
Java 1.5.0_22 (32 bit) and Java 1.6.0_17 (64 bit)
NetRexxC.jar V2.05, 1/14/2005 355,931 bytes

When NetRexxC is run to perform a compile on an arbitrary NetRexx  
program (hello.nrx) and it is given a classpath, either as an  
environmental variable, or via the -cp command line option, and that  
classpath contains a classpath segment which is a directory, then the  
NetRexx compiler starts searching random directories all over the  
system, until it eventually runs out of memory.

I verified this behavior by monitoring the java process using Activity  
Monitor, and watching as the process opened and closed files.

Now I understand that at this point, this is only happening on my  
system.  I guess I would first like other Mac users to veryify if it  
is happening on their systems as well.

Thanks,

Bruce
_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexxC on Mac OS X

David Requena

El 18/03/2010 15:37, Bruce Skelly escribió:
> When NetRexxC is run to perform a compile on an arbitrary NetRexx
> program (hello.nrx) and it is given a classpath, either as an
> environmental variable, or via the -cp command line option, and that
> classpath contains a classpath segment which is a directory, then the
> NetRexx compiler starts searching random directories all over the
> system, until it eventually runs out of memory.

Bruce,

Have you checked that no links exist in said directory in the classpath?

As I understand the NetRexx compiler recursively reads every available
class in the classpath. If there were any links in that tree the compiler
might be just following them (hence, seemingly reading arbitrary locations)

Now, what would happen if at some point a link pointed back to one of the
already scanned locations? A plain old loop!

Just an idea. Maybe you could notice the pattern with Activity Monitor if
this was happening. In any case it should allow to follow the path the
compiler is scanning.

That said, I'll be further studying what you sent me in separate email. I'm
really intrigued by now :-)

---
Saludos / Kind regards.
David Requena


_______________________________________________
Ibm-netrexx mailing list
[hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: NetRexxC on Mac OS X

Bruce Skelly
Ok, I'm now unable to reproduce this as a general case.  I tried  
setting the classpath to /System/Library/Java/, plus the classes.jar  
and NetRexxC.jar and it worked, so I'm not sure what is happening.  I  
guess I need to run some more tests to try and isolate the behavior  
better.

Bruce


On Mar 18, 2010, at 9:03 AM, David Requena wrote:

>
> El 18/03/2010 15:37, Bruce Skelly escribió:
>> When NetRexxC is run to perform a compile on an arbitrary NetRexx  
>> program (hello.nrx) and it is given a classpath, either as an  
>> environmental variable, or via the -cp command line option, and  
>> that classpath contains a classpath segment which is a directory,  
>> then the NetRexx compiler starts searching random directories all  
>> over the system, until it eventually runs out of memory.
>
> Bruce,
>
> Have you checked that no links exist in said directory in the  
> classpath?
>
> As I understand the NetRexx compiler recursively reads every available
> class in the classpath. If there were any links in that tree the  
> compiler
> might be just following them (hence, seemingly reading arbitrary  
> locations)
>
> Now, what would happen if at some point a link pointed back to one  
> of the
> already scanned locations? A plain old loop!
>
> Just an idea. Maybe you could notice the pattern with Activity  
> Monitor if
> this was happening. In any case it should allow to follow the path the
> compiler is scanning.
>
> That said, I'll be further studying what you sent me in separate  
> email. I'm
> really intrigued by now :-)
>
> ---
> Saludos / Kind regards.
> David Requena
>
>
> _______________________________________________
> Ibm-netrexx mailing list
> [hidden email]
>


_______________________________________________
Ibm-netrexx mailing list
[hidden email]