Tilted Forum Project Discussion Community - long shot, but... any Obj-C coders use CoreFoundation and can help me out?

- Tilted Technology (https://thetfp.com/tfp/tilted-technology/)

- - long shot, but... any Obj-C coders use CoreFoundation and can help me out? (https://thetfp.com/tfp/tilted-technology/31653-long-shot-but-any-obj-c-coders-use-corefoundation-can-help-me-out.html)

long shot, but... any Obj-C coders use CoreFoundation and can help me out?

ok, well... I'm TRYING to use the CoreFoundation XML parser under OS X. right now I'm hitting a problem where it SIGBUS's when I call any inherited functions... code below. any hints, lemme know!

Code:

#import "xml.h"





@implementation xml

+(void)parseXML: (NSString *)path

{

    NSLog(@"I am here!");

    CFXMLTreeRef    cfXMLTree;

    CFDataRef       xmlData;

    CFURLRef pathURL = CFURLCreateFromFileSystemRepresentation (

                    kCFAllocatorDefault,

                    [path cString],

                    [path cStringLength],

                    NO);





    // Load the XML data using its URL.

    NSLog(@"about to load the XML file");

    CFURLCreateDataAndPropertiesFromResource(kCFAllocatorDefault, 

                pathURL, &xmlData, NULL, NULL, NULL);



// Parse the XML and get the CFXMLTree.

    NSLog(@"loaded XML, about to parse it!");

    cfXMLTree = CFXMLTreeCreateFromData(kCFAllocatorDefault,

                    xmlData, 

                    pathURL, 

                    kCFXMLParserSkipWhitespace,

                    kCFXMLNodeCurrentVersion);

    NSLog(@"finished parsing");

    

    //int childCount = CFTreeGetChildCount(cfXMLTree); THIS CRASHES IT.

    NSLog(@"childcount");

    int index;

    CFXMLTreeRef    xmlTreeNode;

    CFXMLNodeRef    xmlNode;



    NSLog(@"about to for-loop");

    for (index = 0; index < 2; index++) 

    {

        NSLog(@"just about to call CFTree");

        xmlTreeNode = CFTreeGetChildAtIndex(cfXMLTree, index); //SO DOES THIS.

        NSLog(@"called CFTree, calling CFXML");

        xmlNode = CFXMLTreeGetNode(xmlTreeNode);

        CFShow(CFXMLNodeGetString(xmlNode));

        //NSLog("%s\n",CFXMLNodeGetString(xmlNode));

    }

}



@end

current output: 2003-10-14 17:28:24.790 experiment[13414] I am here!
2003-10-14 17:28:24.799 experiment[13414] about to load the XML file
2003-10-14 17:28:24.807 experiment[13414] loaded XML, about to parse it!
2003-10-14 17:28:24.816 experiment[13414] finished parsing
2003-10-14 17:28:24.824 experiment[13414] childcount
2003-10-14 17:28:24.832 experiment[13414] about to for-loop
2003-10-14 17:28:24.840 experiment[13414] just about to call CFTree

experiment has exited due to signal 10 (SIGBUS).

note that it dies when it calls the CFTree function with a CFXMLTree object (XMLTree is a subclass of Tree, btw). I'm baffled...

Don't worry, you'll find the bug eventually. :)

Seems to me that knowledge of the API would be most useful... and since I've never done ObjC I've never seen this API.

Although I'd just as soon point out I've seen SIGBUS occur due to hardware issues.

SIGBUS can be caused by a bad memory access, are we absolutely sure that the index and cfXMLTree are valid pointers/data at the time of calling? Log those or check in the debugger.

don't see why they shouldn't be, but I'll give 'er a run through the debugger see what I get...

*edit* eats words... ok, now WHY is my treereference pointing at memory location 0x0 is hte question ;) thanks for the shove in the right direction!

ah.. victory at last. the culprit? an unclosed xml tag. was crashing the actual parse function, who wasn'tbothering to mention that it was crashing, or why. so, then, i try'n access it, and BAM program go crashy crashy.

Library bugs waste a lot of programmer time. That's why it's so important not to fall in the NIH syndrome. Because every rewrite will lose the bugfixes.

There was a good article about how Mozilla wasted so much by rewriting the source. Unfortunately I can't seem to find it at the moment, but it sure convinced me...

http://www.wikipedia.org/wiki/Not_Invented_Here

"Not Invented Here (or NIH) refers to the problem when people in companies continue to ignore existing solutions to problems because it was not created in-house. It is endemic to the computer industry.

In many cases NIH occurs as a result of simple ignorance, as many companies simply never do the research to know if a solution already exists. But equally common are deliberate cases where the engineering staff rejects a solution, typically because they believe they can do better.

Many millions of manhours and billions of dollars have been wasted as a result of NIH. "

kel answered your question succinctly. It is indeed a very big problem in the computer industry. :(

It's one of the problems that open source software may help solve, but for now, that remains to be seen.