search

cs-au-dk / Artemis

automated testing for JavaScript
http://www.brics.dk/artemis/
GNU General Public License v3.0
36 stars 10 forks source link

Support name attributes symbolically. #119

Closed BenSpencer closed 9 years ago

BenSpencer commented 9 years ago

Symbolic support for conditions of the form event.target.getAttribute("name") == "interesting".

See test target-name-attr-check in a35b8551.

BenSpencer commented 9 years ago

This seems to be a more general issue with getAttribute, although the case of getAttribute("id") does work, which is strange.

It seems the instrumentation of getAttribute is correctly creating SymbolicObjectPropertyString but SymbolicInterpreter::ail_jmp_iff never receives a symbolic condition.

I know there is special handling of ids in some places, so maybe this is taking a different code path somewhere?

For example, jsHTMLElementId() in JSHTMLElement.cpp is instrumented separately. In this case it does not seem to be used in the getAttribute("id") call, but maybe something like that is going on...?

BenSpencer commented 9 years ago

getAttribute("name") returns null when there is no name attribute defined on the parent element. This is correctly marked as symbolic by jsElementPrototypeFunctionGetAttribute in JSElement.cpp. When we get to the equality check the interpreter executes op_eq which calls SymbolicInterpreter::ail_op_binary with the EQUAL operation. However, this code does not support conditions between string and null values, so the result is not handled symbolically. See here for code.

  1. We need to add support for EQUAL/String/Null conditions to solve the current example.
  2. Maybe we want support for other similar conditions (e.g. STRICT_EQUAL, Int/Null, ...?).
  3. Should the symbolic interpreter print a warning for unhandled cases, to help track down these issues in the future? I have no idea if this is common or not. (The common case of neither argument being symbolic is handled earlier in ail_op_binary.)