bugGNUstep - Bugs: bug #45032, [base] Bundle not correctly...

Group
 
 

bug #45032: [base] Bundle not correctly returned for Class in Framework

Submitter:  Riccardo Mottola <rmottola>
Submitted:  Tue 05 May 2015 09:23:54 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 09 Jun 2015 10:06:01 PM UTC, comment #11: 

I made configure detect nm, giving gnm priority if avaiable.
The solution does check for nm, not the cross-compile version, as it was doign currently anyway.

target.make updated to use $(NM)

the variable is not settable by the user and it is not looked for in non-PATH paths.

It should be a good enough improvement and fixes solaris when using nm from binutils.

Riccardo Mottola <rmottola>
Group Member
Mon 08 Jun 2015 09:32:17 PM UTC, comment #10: 

The problem is essentially in target.make

EXTRACT_CLASS_NAMES_COMMAND

uses nm

I guess we should have something like $(NM) and have it platform dependent or even configure detected.

Riccardo Mottola <rmottola>
Group Member
Mon 08 Jun 2015 09:07:47 PM UTC, comment #9: 

I notice that while building I get:
 Compiling file FSNPathComponentsViewer.m ...
 Creating derived_src/NSFramework_FSNode.m...
/bin/sh: nm: not found
/bin/sh: nm: not found


I suppose nm is used to get the symbols. Solaris does not provide nm, the GNU binutils should be used, which is installed as gnm

Riccardo Mottola <rmottola>
Group Member
Mon 08 Jun 2015 04:08:43 PM UTC, comment #8: 

I have attached a patch to correct this issue.  Please download and apply it by going to the make directory under core... then do this...

patch -p0 < framework.make.patch

This should apply the patch to the framework.make file in the Instance directory. 

I have not yet tested this, but I am confident it should work.   Please let me know.

Gregory John Casamento <gcasa>
Group administrator
Mon 08 Jun 2015 01:17:42 PM UTC, comment #7: 

Hey guys... after doing some research on this on Riccardo's SPARC box I've seen this:

Breakpoint 13, +[NSBundle(Private) _addFrameworkFromClass:] (self=0xfea34304 <_OBJC_Class_NSBundle>, _cmd=0xfea34590 <_OBJC_SELECTOR_TABLE+488>,
    frameworkClass=0xff30eb28 <_OBJC_Class_NSFramework_FSNode>) at NSBundle.m:889
889           fmClasses = [frameworkClass frameworkClasses];
(gdb) step
objc_msg_lookup (receiver=0xff30eb28 <_OBJC_Class_NSFramework_FSNode>, op=0xfea34568 <_OBJC_SELECTOR_TABLE+448>)
    at /home/dam/mgar/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.9.2/libobjc/sendmsg.c:445
445     /home/dam/mgar/pkg/gcc4/trunk/work/solaris10-sparc/build-isa-sparcv8plus/gcc-4.9.2/libobjc/sendmsg.c: No such file or directory.
(gdb) b NSFramework_FSNode.m:13
Breakpoint 14 at 0xff2a145c: file derived_src/NSFramework_FSNode.m, line 13.
(gdb) c
Continuing.

Breakpoint 14, +[NSFramework(FSNode) _frameworkClasses] (self=0xff30eb28 <_OBJC_Class_NSFramework_FSNode>, _cmd=0xfea34568 <_OBJC_SELECTOR_TABLE+448>)
    at derived_src/NSFramework_FSNode.m:13
13      + (NSString const)frameworkClasses { return allClasses; }
(gdb) p allClasses
$5 = {0x0}
(gdb)

This is a method GNUstep-make is auto generating for the framework.  Here's the class in it's entirety....

#include <Foundation/NSString.h>
@interface NSFramework_FSNode : NSObject
+ (NSString *)frameworkEnv;
+ (NSString *)frameworkPath;
+ (NSString *)frameworkVersion;
+ (NSString const)frameworkClasses;
@end
@implementation NSFramework_FSNode
+ (NSString *)frameworkEnv { return nil; }
+ (NSString *)frameworkPath { return @"/usr/GNUstep/Local/Library/Frameworks"; }
+ (NSString *)frameworkVersion { return @"0"; }
static NSString *allClasses[] = {@"FSNode", @"FSNodeRep", @"FSNTextCell", @"FSNBrowserCell", @"FSNCellNameEditor", @"FSNBrowserScroll", @"FSNBrowserMatrix", @"FSNBrowserColumn", @"FSNBrowser", @"FSNIcon", @"FSNIconNameEditor", @"FSNIconsView", @"FSNListView", @"FSNListViewDataSource", @"FSNListViewNameEditor", @"FSNListViewNodeRep", @"FSNPathComponentView", @"FSNPathComponentsViewer", NULL};
+ (NSString const)frameworkClasses { return allClasses; }
@end

Now... as is apparent from the trace above "allClasses" at the time frameworkClasses is called from NSBundle.m:889 (current SVN revision as of this date) is returning NULL:

887           /* A NULL terminated list of class names - the classes contained
888              in the framework.  */
889           fmClasses = [frameworkClass frameworkClasses];
890    
891           while (*fmClasses != NULL)
892             {
893               NSValue *value;
894               Class    class = NSClassFromString(*fmClasses);
895    
(gdb) p fmClasses
$6 = (struct NSString **) 0xff31a6c4 <allClasses>
(gdb) p *fmClasses
$7 = (struct NSString *) 0x0
(gdb)

I'm a bit confused as, I thought that the static variable in the global scope should be initialized before everything else, but, apparently, this is not something which can be relied on to happen on SOLARIS.

I'm wondering if this is a more generalized issue.  Could this happen on other OSs.  Currently I have only seen this on SOLARIS, but that doesn't rule out the possibility that it could happen elsewhere.


Gregory John Casamento <gcasa>
Group administrator
Wed 20 May 2015 10:29:28 AM UTC, comment #6: 

I checked step for step Solaris against OpenBSD to see where the behaviour differs. The problem appears to be un bundleForClass around line 1525. The first lookup done:
bundle = (NSBundle *)NSMapGet(_byClass, aClass);

already returns a valid bundle on OpenBSD, it does not on Solaris.

Why? If this is the error, it makes no sense to check and debug all the rest of the heuristic which I think is fkaley since it checks only Libraries and not Frameworks.

Riccardo Mottola <rmottola>
Group Member
Tue 12 May 2015 10:32:27 PM UTC, comment #5: 

I see what is wrong, but I wonder why it is specifc to solaris?

I put some nslogs in bundleForLibrary when the class fo FSNode is looked up:
2015-05-13 00:20:04.137 GWorkspace[5386:1817400] bundleForClass: FSNodeRep
2015-05-13 00:20:04.138 GWorkspace[5386:1817400] lib: /opt/GNUstep/Local/Library/Frameworks/FSNode.framework/Versions/0/libFSNode.so.0.1.0
2015-05-13 00:20:04.139 GWorkspace[5386:1817400] bundleForLibrary: clean libraryName: libFSNode.so.0.1.0
2015-05-13 00:20:04.139 GWorkspace[5386:1817400] bundleForLibrary: libraryName without extension: libFSNode, interface version:0.1
2015-05-13 00:20:04.140 GWorkspace[5386:1817400] looking for specific version: /opt/GNUstep/Local/Library/Libraries/FSNode/Versions/0.1/Resources
2015-05-13 00:20:04.141 GWorkspace[5386:1817400] bundle for library: (null)

it is looking for
 /opt/GNUstep/Local/Library/Libraries/FSNode/Versions/0.1/Resources

first, there is no "0.1" version, second the resources are inside the Framework, as on e.g. FreeBSD:
/opt/GNUstep/Local/Library/Frameworks/FSNode.framework/Versions/0/Resources

why this does work on FreeBSD though I don't know, but it is confusing. at line 3118 if the path does not exist the NSFileManager won't find it and thus return nil.

Riccardo Mottola <rmottola>
Group Member
Tue 12 May 2015 10:04:53 PM UTC, comment #4: 

indeed, even if "lib" has a sensible value, bundleForLibrary returns nil, investigating further.

Riccardo Mottola <rmottola>
Group Member
Mon 11 May 2015 06:14:23 PM UTC, comment #3: 

I have seen it only on Solaris SPARC right now.

If someone has solaris on x86 and can try to run GWorkspace...


Riccardo Mottola <rmottola>
Group Member
Sat 09 May 2015 06:48:02 AM UTC, comment #2: 

It seems like the problem is at -bundleForLibrary:version:. Is this problem only with sparc architecture?

Germán Arias <espectador>
Wed 06 May 2015 09:09:39 PM UTC, comment #1: 

I am adding some logs to NSBundle to see where the problem is:

2015-05-06 22:31:27.087 GWorkspace[7234:1817400] bundleForClass: FSNodeRep
2015-05-06 22:31:27.088 GWorkspace[7234:1817400] lib: /opt/GNUstep/Local/Library/Frameworks/FSNode.framework/Versions/0/libFSNode.so.0.1.0
2015-05-06 22:31:27.090 GWorkspace[7234:1817400] setting bundle to mainBundle
2015-05-06 22:31:27.091 GWorkspace[7234:1817400] returning bundle, _path: NSObject
2015-05-06 22:31:27.091 GWorkspace[7234:1817400] bundle resource path: /opt/GNUstep/Local/Applications/GWorkspace.app/Resources


So first we see that the GSPrivateSymbolPath looks correct (around line 1572)
However later bundle is nil, so it is set to the main bundle. Why?

To be sure, I tried to print out the added frameworks in _addFrameworks:
2015-05-06 23:10:24.784 GWorkspace[9015:1817400] frameworks added: ("<NSBundle: 0x268088> </opt/GNUstep/Local/Library/Frameworks/Operation.framework> (loaded)", "<NSBundle: 0x294b40> </opt/GNUstep/Local/Library/Frameworks/FSNode.framework> (loaded)", "<NSBundle: 0x2970a8> </opt/GNUstep/Local/Library/Frameworks/Inspector.framework> (loaded)")

thus FSNode is there, what is not working?

Riccardo Mottola <rmottola>
Group Member
Tue 05 May 2015 09:23:54 PM UTC, original submission:  

I was able to reproduce this on Solaris only (5.8 and 5.10) both with release as current SVN.

In GWorkspace, in FSNodeRep, there is code that gets the current bundle this way

NSBundle *bundle = [NSBundle bundleForClass: [FSNodeRep class]];

FSNodeRep is in the FSNode framwework.

On my Solaris box, the bundle returned is the application bundle, on e.g. NetBSD, the correct /System/Library/Framework/FSNode.framework is returned.

Since the bundle is then used to get resources like images and nib files, other code fails.

Riccardo Mottola <rmottola>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #34180:  framework.make.patch added by gcasa (775B - text/x-patch - Potential patch for issue found in this bug on Solaris.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by gcasa (Posted a comment)
  • -email is unavailable- added by espectador (Posted a comment)
  • -email is unavailable- added by rmottola (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2015-11-25 rmottola StatusReady For Test Fixed
        Open/ClosedOpen Closed
    2015-06-09 rmottola StatusNone Ready For Test
    2015-06-08 gcasa Attached File- Added framework.make.patch, #34180

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code