Ncml_handler fails when ascii data (or a server function result) is requested for renamed variables.

Description

Given a simple ncml file that changes the name of a variable:

When I issue the following BES request using 'besstandalone':

I get back this error:

Please note that at the beginning and the end of the error response we see character content that appears to be leaking into the response from somewhere in the BES.

Environment

None

Activity

Show:
Nathan Potter
August 13, 2015, 12:16 AM
Edited

The JSON response for renamed arrays is broken (segmentation fault), and I suspect it's the same issue.

Used lldb to examine the failure. Moving up two stack frames from the point of failure:

Moving down one stack frame (into a->value(src);):

What is interesting here is that when stepping into a->value(src); we don't seem step into RenamedArrayWrapper::value<float>() method but rather into libdap::Vector::value<float>() Since the RenamedArrayWrapper is in theory overriding this method I suspect the source of the error may be right there - the wrong implementation of value() is being called.

Nathan Potter
August 13, 2015, 10:12 PM
Edited

Looking at how this gets expressed in various ways:

  • JoinExisiting aggregations

    • Ascii and JSON responses work for aggregated source data variables, with or without a hyperslab constraint

    • Ascii and JSON responses work for entire (no subset) new (NcML defined) arrays

    • Ascii and JSON responses FAIL for subsets of new (NcML defined) arrays (errors like in BES-7, the Jason Werpy bug)

  • JoinNew aggregations

    • Ascii and JSON responses work for aggregated source data variables, with or without a hyperslab constraint

    • Ascii and JSON responses work for entire (no subset) new (NcML defined) arrays

    • Ascii and JSON responses FAIL for subsets of new (NcML defined) arrays (errors like in BES-7, the Jason Werpy bug)

  • Renamed Variables

    • Ascii response FAILS for renamed arrays:

    • JSON response FAILS for renamed arrays with a seg fault.

  • New (ncml created) variables

    • Ascii and JSON responses works for a new array variable (like "time")

    • Ascii and JSON responses FAIL for a new array variable (like "time") if the variable is subset (errors like in BES-7, the Jason Werpy bug)

  • Does subsetting affect the issue?

    • Subsetting on the outer dimension: No problem for joinExisting or joinNew.

    • I think the subsetting issues here are orthogonal to the problem - in other words the subsetting problems I have encountered in this all appear to be manifestations of the bug.

James Gallagher
August 13, 2015, 10:52 PM

We talked on the phone about this and came to the conclusion that it may be an issue where the methods we think are overloading Vector::value() are not because the methods in Vector are templates and the ones in Renamed... are not. try changing them and see what shakes loose.

Nathan Potter
August 15, 2015, 12:02 AM
Edited

Fixed ncml_module::RenamedArrayWrapper to correctly override the libdap:Vector::value() and libdap:Vector::set_value() methods. This was accomplished by making the use of templates in libdap::Vector private and adding virtual functions for all of the various overloaded versions of libdap::Vector::value() and libdap::Vector::set_value (one version for each DAP atomic type). This fixes the JSON output for renamed array's, but unfortunately not the ascii output. So ascii val is going to take more work

Slav Korolev
November 30, 2018, 5:18 PM

This error already fixed. To test please use following steps:
1. cd ..bes/modules/ncml_module/tests
2. download test4.nc, ascii_rename.ncml and rangeDataError.bescmd
3. besstandalone -d "cerr,ncml" -c bes.conf -i rangeDataError.bescmd

I couldn't get error.

Assignee

Slav Korolev

Reporter

Nathan Potter

Labels

None

Fix versions

None

Time remaining

0m

Story Points

None

Time tracking

0m

Epic Link

Priority

High
Configure