Bug 1082260 - Using COLLADA 1.4.1 DAE::open always returns NULL
Summary: Using COLLADA 1.4.1 DAE::open always returns NULL
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: collada-dom
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Till Hofmann
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-03-29 22:22 UTC by Casey Dahlin
Modified: 2014-06-18 08:47 UTC (History)
3 users (show)

Fixed In Version: collada-dom-2.4.3-1.fc20
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-17 23:23:35 UTC


Attachments (Terms of Use)

Description Casey Dahlin 2014-03-29 22:22:40 UTC
Attempting to port my code to collada-dom 2.4.2, I discovered that dae.open now always returns NULL.

Looking at the code, it appears the issue happens here:

domCOLLADAProxy* DAE::openCommon(const string& path, daeString buffer) {
    close(path);
    string uri = makeFullUri(path);
    plugin->setDatabase(database);
    if (plugin->read(daeURI(*this, uri.c_str()), buffer) != DAE_OK)
        return NULL;
    return getRoot(uri);
}

the return NULL in the if statement is being triggered. That appears to come from here:

daeInt daeIOPluginCommon::read(const daeURI& uri, daeString docBuffer)
{
    // Make sure topMeta has been set before proceeding
    if (topMeta == NULL)
    {
        return DAE_ERR_BACKEND_IO;
    }

*snip*

The topMeta variable should be populated by the owning DAE object at DAE::setIOPlugin on this line:

    int res = plugin->setMeta(getMeta(getDomCOLLADAID()));

The nested getDomCOLLADAID call is to this code:

daeInt getDomCOLLADAID(const char* specversion)
{
#ifdef COLLADA_DOM_SUPPORT150
    if( specversion == NULL || strcmp(specversion,"1.5.0") == 0 ) {
        return ColladaDOM150::domCOLLADA::ID();
    }
#endif
#ifdef COLLADA_DOM_SUPPORT141
    if( specversion == NULL || strcmp(specversion,"1.4.1") == 0 ) {
        return ColladaDOM141::domCOLLADA::ID();
    }
#endif
    return NULL;
}

You'll note we expect a specversion argument but have none passed, so we'll always return the version 150 ID it seems.

Comment 1 Till Hofmann 2014-04-14 10:28:52 UTC
Thanks for reporting. I could reproduce the bug. As you said it seems like getDomCOLLADAID() returns the wrong version and therefore, the initialization fails.

I don't think this is a packaging bug. Could you report the bug upstream [1] ? I'll update once upstream fixed this. Also note that somebody already reported this bug on Sourceforge [2]. But since they switched to Github, reporting there would probably be a good idea.

[1] https://github.com/rdiankov/collada-dom/issues
[2] http://sourceforge.net/p/collada-dom/bugs/157/

Comment 2 Casey Dahlin 2014-04-26 16:33:56 UTC
This is now fixed upstream.

https://github.com/rdiankov/collada-dom/commit/6706dd1ca292b22792b1066289e7e5ee21d5649a

Comment 3 Fedora Update System 2014-06-06 10:10:04 UTC
collada-dom-2.4.3-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/collada-dom-2.4.3-1.fc20

Comment 4 Fedora Update System 2014-06-10 03:05:38 UTC
Package collada-dom-2.4.3-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing collada-dom-2.4.3-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-7182/collada-dom-2.4.3-1.fc20
then log in and leave karma (feedback).

Comment 5 Fedora Update System 2014-06-17 23:23:35 UTC
collada-dom-2.4.3-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.