Issue with json_object_set_string in Windows After Code Refactor

[NishantBansal2003]

I'm currently working on a cleanup in the OSGeo/grass repository, specifically moving some code from a module to a library. However, I am encountering an issue where the JSON output for a particular module becomes incomplete after this change.

The problem occurs when using json_object_set_string, which doesn't seem to work as expected. json_object_set_number, on the other hand, works fine. I’ve verified that the string I'm passing to json_object_set_string is correct (using fprintf for debugging), and I also confirmed that the function returns JSONSuccess, so I am not sure why the JSON output is incomplete.

Interestingly, this issue only occurs on Windows, not on macOS or Linux.

I have linked the PR where the changes are happening(Check the OSGeo4W failing CI): PR #4665.

Has anyone encountered a similar issue, or could you suggest possible causes for this behavior on Windows?

[kgabis]

What do you mean by saying that json_object_set_string doesn't work as expected? What is the expected output and what is the actual result? Can you provide a repro for this problem?

[NishantBansal2003]

Expected output is(for eg):

[
    {
        "value": 1,
        "hex": "#00BFBF"
    },
    {
        "value": 286.4,
        "hex": "#00FF00"
    },
    {
        "value": 571.8,
        "hex": "#FFFF00"
    },
    {
        "value": 857.2,
        "hex": "#FF7F00"
    },
    {
        "value": 1142.6,
        "hex": "#BF7F3F"
    },
    {
        "value": 1428,
        "hex": "#C8C8C8"
    },
    {
        "value": "nv",
        "hex": "#FFFFFF"
    },
    {
        "value": "default",
        "hex": "#FFFFFF"
    }
]

Actual output:

[
    {
        "value": 1,
    },
    {
        "value": 286.4,
    },
    {
        "value": 571.8,
    },
    {
        "value": 857.2,
    },
    {
        "value": 1142.6,
    },
    {
        "value": 1428,
    },
  {},
  {}
]

To reproduce this issue, you can follow the steps in the OSGeo4W GitHub Actions workflow. The failure occurs during the build process when running the command in the OSGeo4W environment on Windows, as defined in the workflow.
Link to PR where github action(OSGeo4w) fails: OSGeo/grass#4665.

[kgabis]

Can you provide a simple proof of concept for this issue?

[NishantBansal2003]

Apologies, but unfortunately, I cannot provide a simple PoC for this issue. When using the Parson library directly within the module, everything works fine across all operating systems. However, when I use the Parson library within one of the GRASS libraries, the issue arises—specifically, json_object_set_number works as expected, but json_object_set_string does not, causing incomplete JSON output.

The issue occurs because the r.colors.out module runs the json_color_out.c code, which is where the problem manifests. When I use json_color_out directly within the r.colors.out module and link it there, everything works fine. However, when I move it to a library and link it from there, this error occurs.

To reproduce this issue, you will need to compile GRASS in the OSGeo4W environment, as mentioned in the osgeo4w.yml configuration. Once GRASS is compiled, please run the following commands:

call %grass% --exec g.region s=0 n=90 w=0 e=100 b=0 t=1 rows=3 cols=3 res=10
call %grass% --exec r.mapcalc expr="a = int(row())"
call %grass% --exec r.colors map=a color=elevation
call %grass% --exec r.colors.out map="a" rules="-" format="json" color_format="hex"

This should result in the incomplete JSON output, as described earlier.

Again, I apologize for not being able to provide a simpler PoC, but this issue only appears under these specific conditions within the OSGeo4W environment.

[NishantBansal2003]

Apologies for the confusion, but I do not expect you to compile GRASS from source. You can check the failing CI from the following link to see the issue in action, along with the PR that introduces the problem:

• Failing CI Link
• PR Link

Given this context, could you suggest any way to diagnose whether the issue lies in the Parson library, the OSGeo/GRASS code, or in my implementation? I would appreciate any guidance on how to track down the root cause of this issue.

Thank you!

[NishantBansal2003]

Please feel free to contact me if you need more context or additional information related to the issue.

[kgabis]

Just for test, could you try renaming json_object_set_string to json_object_set_string_parson and see if it still fails? I can't test it locally unfortunately.

[NishantBansal2003]

Amazing! Thanks, this worked for me.

JSON_Status json_object_set_string_parson(JSON_Object *object, const char *name,
                                          const char *string)
{
    return json_object_set_string(object, name, string);
}

However, I’m not entirely sure why this works while the previous definition caused an error. Could you provide some reasons for this, just for my learning?

[nilason]

The cause of this problem was linking to a library with Parson embedded and at the same time another library with json-c embedded (the function name and thus the resulting symbol json_object_set_string is the same and hence conflicting). This situation caused problems (so far, knowingly) only with MinGW builds on Windows.

[kgabis]

Yes, that was my suspicion. It's quite unfortunate that parson is using json_ prefix instead of parson_, but I don't see a good way of changing that.