Skip to content

handleBracketingOperators (src/support/string.h) is broken, and list parsing in asyncify is not functioning correctly. #6047

Closed

Description

@caiiiycuk

Hi, I've come across a corner case where asyncify list parsing is failing with an error:

 Fatal: Asyncify: failed to parse lists

The list parsing mechanism is attempting to calculate nesting operators from the code:

Handles bracketing in a list initially split by ",", but the list may contain nested ","s. For example,
void foo(int, double)
must be kept together because of the "(". Likewise, "{", "<", "[" are handled.

The implementation performs simple nesting counting:

    for (const char c : part) {
      if (c == '(' || c == '<' || c == '[' || c == '{') {
        nesting++;
      } else if (c == ')' || c == '>' || c == ']' || c == '}') {
        nesting--;
      }
    }

This doesn't work for the function XStream::operator>(int&). Obviously, the nesting will be -1 at the end, and a fatal error will occur.

I don't have an idea on how to easily fix this. Moreover, I've been using asyncify for a long time, and this list format is hard to maintain. I think that using a one-line-one-function file format is much easier to maintain and will not have this issue.

What do you think? Any suggestion how to fix this?

Activity

  1. caiiiycuk commented on Oct 24, 2023

    @caiiiycuk
    ContributorAuthor

    link to another asyncify parsing problem #5271

  2. caiiiycuk commented on Oct 24, 2023

    @caiiiycuk
    ContributorAuthor

    I think we can add another option, like -sASYNCIFY_STRING_DELIM=newline, and if it is present, then use a one-line-one-function file format.

  3. kripken commented on Oct 24, 2023

    @kripken
    Member

    How about if we find a newline, then we assume that we should split by newlines (and do no other nesting computations, as you said)? That would avoid adding a new option.

  4. caiiiycuk commented on Oct 24, 2023

    @caiiiycuk
    ContributorAuthor

    It appears that -sASYNCIFY_WHITELIST=@file is parsing the file on its own because Binaryen receives the function list as a string, such as func1, func2, func3, instead of a file. Is it possible that the same bug exists on the Emscripten side as well?

  5. kripken commented on Oct 24, 2023

    @kripken
    Member

    I don't think the emscripten side does any parsing of bracketing, but it does expand response files, so @file would turn into the contents of that file. But that can be adjusted on a per-setting basis.

  6. added 4 commits that reference this issue on Oct 25, 2023
    11b1796
    30eaee8
    40e0744
    3c4c264
  7. added a commit that references this issue on Feb 3, 2024
    7dcc532
  8. added a commit that references this issue on Jul 12, 2024
    342c205
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions