libfoundation-users — libFoundation Users

Re: [Libfoundation-users] Conversion of a WO 4.01 NT program to use GNU LibFoundation

[Helge H. <hel...@sk...>]

Hi Mike,

I suggest that you try gstep-base (www.gnustep.org) for compilation on 
Windows. This has much better support for Windows now than 
libFoundation. It's probably easiest to use Cygwin as the basis (like WO 
NT ;-)
Also be sure to subscribe gnustep-discuss to ask gstep-base/NT related 
questions.

Greetings
  Helge

Mike Llewellyn wrote:

> Hello,
>
> I have a cmd-line program written in Objective-C using the WebObjects 
> 4.01 Developer tools, for Win NT 4.0. The program only uses the 
> Foundation library, and the runtime (machd and nmserver required when 
> running).
>
> I would like to be able to use the Gnu version and remove dependency 
> on any license-required libraries/run-times.
>
> Does anyone have experience of such an operation for NT? I would be 
> grateful to hear of positive experiences using these libraries, and 
> any guidance on how to get started.
>
> I have downloaded the source and hoping to compile later today, but 
> I'm still not clear on how the run-time aspect is replaced.
>
> Many many thanks for any help!
>
> Best regards,
> Mike Llewellyn
>

[Libfoundation-users] Conversion of a WO 4.01 NT program to use GNU LibFoundation

[Mike L. <mi...@Ne...>]

Hello,

I have a cmd-line program written in Objective-C using the WebObjects 4.01
Developer tools, for Win NT 4.0. The program only uses the Foundation
library, and the runtime (machd and nmserver required when running).

I would like to be able to use the Gnu version and remove dependency on any
license-required libraries/run-times.

Does anyone have experience of such an operation for NT? I would be grateful
to hear of positive experiences using these libraries, and any guidance on
how to get started. 

I have downloaded the source and hoping to compile later today, but I'm
still not clear on how the run-time aspect is replaced.

Many many thanks for any help!

Best regards,
Mike Llewellyn

Re: [Libfoundation-users] Debugging Retain Cycles

[Sven C. K. <sc...@sn...>]

On Mon, Aug 20, 2001 at 11:56:54AM +0200, Helge Hess wrote:
> As long as ObjC objects are concerned Boehm GC *does* use typed memory
> and is exact ! It only needs to guess on stack and global variables.
> While it may not find all leaks it will find 99.99% of the leaks.

Cool!

> > One could read the return address from the stack, and translate it
> > afterwards via binutils's addr2line program, but that's very evil!
> 
> More important: it's very slow which makes it unusable. You can get the
> callee information in the RETAIN macros, but even then tracking all RC
> owners will be a huge memory problem !
> 
> #define RETAIN(x) \
>   [x retainFromFunction:__PRETTY_FUNCTION__ \
>      file:__FILE__ line:__LINE__];

I am afraid, my source code doesn't use the RETAIN et al. macros like lF
does.  So, bascially I would wrap retain et al., and write the callees
address and the address of the object to retain to a logfile.
Afterwards, I would read the logfile with a script and search for retain 
cycles.  Then I would  translate all the callee addresses that are part
of cycles to line numbers via addr2line or using a generated addresses
map to speed up processing.

But I think this scenario is pretty fictional, since I hope GCObject will
do this already for me. 

Regards,

Sven

Re: [Libfoundation-users] Debugging Retain Cycles

[Helge H. <hel...@sk...>]

"Sven C. Koehler" wrote:
> Concerning Boehm GC, I am somewhat suspicious regarding conservative GC,
> since it doesn't use typed memory, and so it might not see all leaks that
> are there--but I did not read yet much in the documentation of Boehm GC.
> Another thing is that it seems to require a rebuilt of libobjc, what is
> expensive.

As long as ObjC objects are concerned Boehm GC *does* use typed memory
and is exact ! It only needs to guess on stack and global variables.
While it may not find all leaks it will find 99.99% of the leaks.

> One could read the return address from the stack, and translate it
> afterwards via binutils's addr2line program, but that's very evil!

More important: it's very slow which makes it unusable. You can get the
callee information in the RETAIN macros, but even then tracking all RC
owners will be a huge memory problem !

#define RETAIN(x) \
  [x retainFromFunction:__PRETTY_FUNCTION__ \
     file:__FILE__ line:__LINE__];

Greetings
  Helge
-- 
SKYRIX Software AG - http://www.skyrix.com
Web Application Technology for Enterprises

Re: [Libfoundation-users] Debugging Retain Cycles

[Sven C. K. <sc...@sn...>]

Hi Helge, 

On Mon, Aug 20, 2001 at 10:40:36AM +0200, Helge Hess wrote:
> are you searching for RC leaks *inside* of lF or in code using lF ? If
> you look for leaks outside of lF you might consider using the GCObject
> class instead of NSObject, since it provides a simple, RC based, garbage
> collector (which tracks cycles ...).

Thanks for the hint to GCObject!
No, I am not searching leaks inside the lF.  I did once use purify to
search for memory leaks/access faults, and they all turned out to be
based on my own fault--so lF seems to be pretty leak-less. (Actually,
purify reported some unintialized memory reads, but they did not seem to
hurt.)

> Another good way to find memory leaks is Boehm GC in leak mode, but it's
> now long ago that I used that feature. I think dmalloc also supports a
> similiar tracing feature.

Concerning Boehm GC, I am somewhat suspicious regarding conservative GC,
since it doesn't use typed memory, and so it might not see all leaks that
are there--but I did not read yet much in the documentation of Boehm GC.
Another thing is that it seems to require a rebuilt of libobjc, what is
expensive.  

> > My next idea would be to somehow wrap NSObject's retain (either on the
> > source code or on the linker level), and to log the information I
> > need.  But before I do this, I'd just like to know whether there are
> > better ways.
> 
> I doubt that you can get the info you want by overiding -retain/-release
> ! Methods don't know where they are called from.

One could read the return address from the stack, and translate it
afterwards via binutils's addr2line program, but that's very evil!

Regards,

Sven Koehler

Re: [Libfoundation-users] Debugging Retain Cycles

[Helge H. <hel...@sk...>]

Hi Sven,

are you searching for RC leaks *inside* of lF or in code using lF ? If
you look for leaks outside of lF you might consider using the GCObject
class instead of NSObject, since it provides a simple, RC based, garbage
collector (which tracks cycles ...).

Another good way to find memory leaks is Boehm GC in leak mode, but it's
now long ago that I used that feature. I think dmalloc also supports a
similiar tracing feature.

> My next idea would be to somehow wrap NSObject's retain (either on the
> source code or on the linker level), and to log the information I
> need.  But before I do this, I'd just like to know whether there are
> better ways.

I doubt that you can get the info you want by overiding -retain/-release
! Methods don't know where they are called from.

Greetings
  Helge

"Sven C. Koehler" wrote:
> I am looking for best practices to debug retain cycles.  So far, I
> tried to track them down by reading source, which can be very frustrating
> when there is a lot of source code; another try was to read lF's internal
> data structures (in a category of e.g. NSAutoreleasePool), and to search
> those objects that are part of the cycle--unfortunately, it turned out
> that lF does not know from where objects were retained (correct me if I am
> wrong).
> 
> My next idea would be to somehow wrap NSObject's retain (either on the
> source code or on the linker level), and to log the information I
> need.  But before I do this, I'd just like to know whether there are
> better ways.
> 
> Thanks in advance,
> 
> Sven Koehler
> 
> _______________________________________________
> libFoundation-users mailing list
> lib...@li...
> http://lists.sourceforge.net/lists/listinfo/libfoundation-users

-- 
SKYRIX Software AG - http://www.skyrix.com
Web Application Technology for Enterprises

[Libfoundation-users] Debugging Retain Cycles

[Sven C. K. <sc...@sn...>]

Hi,

I am looking for best practices to debug retain cycles.  So far, I
tried to track them down by reading source, which can be very frustrating
when there is a lot of source code; another try was to read lF's internal
data structures (in a category of e.g. NSAutoreleasePool), and to search
those objects that are part of the cycle--unfortunately, it turned out
that lF does not know from where objects were retained (correct me if I am
wrong).

My next idea would be to somehow wrap NSObject's retain (either on the
source code or on the linker level), and to log the information I
need.  But before I do this, I'd just like to know whether there are
better ways.

Thanks in advance,

Sven Koehler

[Libfoundation-users] Patch for NSFileManager's fileAttributesAtPath:traverseLink: on Windows

[Sven C. K. <sc...@sn...>]

Hello!

I tried to use fileAttributesAtPath:traverseLink: on Windows, which gave
me an access violation.  The following patch worked for me.

Regards,

Sven Koehler

--- NSFileManager.m     Tue Jun 26 14:18:45 2001
+++ NSFileManager.new.m Thu Aug  2 17:01:15 2001
@@ -856,6 +856,8 @@
        values[9] = [NSString stringWithCString:pw->pw_name];
     else
        count = 9;
+#else 
+    count = 8;
 #endif