Page MenuHomeFreeBSD

libxo: Fix XML output if a container name is a number
Needs ReviewPublic

Authored by kristof on Dec 29 2018, 12:52 PM.

Details

Reviewers
allanjude
phil
Summary

When we xo_open_container() the XML output code generates a tag. There
are some constraints to the tag name which the code does not take into
account. Namely, the tag may contain numbers, but cannot start with a
number.
That constraint is not respected by the calling code, at least in
procstat --libxo xml -ta and potentially in other callers as well.

Tag names are allowed to start with underscores though, so if the tag
starts with something that's not a letter (or underscore) we prefix an
underscore. This changes only the XML output, but presents no risk of
changing schemas people rely on, because the output was previously not
valid XML.

Reported By: Mark Saad

Diff Detail

Repository
rS FreeBSD src repository
Lint
Lint Skipped
Unit
Unit Tests Skipped
Build Status
Buildable 21759

Event Timeline

kristof created this revision.Dec 29 2018, 12:52 PM
phil added a comment.Jan 1 2019, 6:50 PM

The responsibility for valid tags should rest with the caller, but under the "never do the wrong thing", I'll pick up this fix, along with a "warning" call to help coders notice the breakage.

For "procstat -ta", the output is just broken, which is likely my fault from the original procstat patch. The use of PIDs and TIDs as element names is a bug:

Idle [Mail]% procstat --libxo xml,pretty -ta|more<procstat version="1">

<threads>
  <0>
    <process_id>0</process_id>
    <command>kernel</command>
    <threads>
      <100000>
        <thread_id>100000</thread_id>
        <thread_name>swapper</thread_name>
        <cpu>-1</cpu>
        <priority>84</priority>
        <run_state>sleep</run_state>
        <wait_channel>swapin</wait_channel>
      </100000>
      <100007>
        <thread_id>100007</thread_id>
        <thread_name>thread taskq</thread_name>
        <cpu>-1</cpu>
        <priority>108</priority>
        <run_state>sleep</run_state>
        <wait_channel>-</wait_channel>
      </100007>

...

I'll repair that as well.

Thanks,
Phil