[Bug translator/22193] New: Regex matching (=~) should be treated as a side-effecting operation

[Bug translator/22193] New: Regex matching (=~) should be treated as a side-effecting operation

[serhei.public at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22193

            Bug ID: 22193
           Summary: Regex matching (=~) should be treated as a
                    side-effecting operation
           Product: systemtap
           Version: unspecified
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: translator
          Assignee: systemtap at sourceware dot org
          Reporter: serhei.public at gmail dot com
  Target Milestone: ---

Now that the regex matching operator modifies context data structures
(CONTEXT->last_match), the translator should no longer elide a regex match as
side-effect-free if its return value is unused.

Currently what happens:

$ stap -e 'probe begin { "foo" =~ "f(.)"; println(matched(1)); exit() }'
WARNING: Eliding side-effect-free expression : string 'foo' at <input>:1:15
 source: probe begin {  ... foo ... "foo" =~ "f(.)"; println(matched(1));
exit() }
                            ^
ERROR: Attempted to get subexpression 1 from failed match near identifier
'matched' at /opt/systemtap/share/systemtap/tapset/regex.stp:36:10
WARNING: Number of errors: 1, skipped probes: 0
WARNING: /opt/systemtap/bin/staprun exited with status: 1
Pass 5: run failed.  [man error::pass5]

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22193] Regex matching (=~) should be treated as a side-effecting operation

[serhei.public at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22193

Serhei Makarov <serhei.public at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |FIXED

--- Comment #1 from Serhei Makarov <serhei.public at gmail dot com> ---
solved in commit 81e03c8fea

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22193] Regex matching (=~) should be treated as a side-effecting operation

[jeremip11 at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22193

Jeremi <jeremip11 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jeremip11 at gmail dot com

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22193] Regex matching (=~) should be treated as a side-effecting operation

[serhei.public at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22193

Serhei Makarov <serhei.public at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|FIXED                       |---

--- Comment #2 from Serhei Makarov <serhei.public at gmail dot com> ---
Actually the earlier commit I made is a bad idea for reasons both tedious and
potentially numerous:

- After this patch, 'unused_var; if (SIDE_EFFECTING_REGEXP_MATCH(unused_var))
{more_unused_stuff}' will force 'more_unused_stuff' to be kept but elide
'unused_var' -- somehow it doesn't pick up that REGEXP_MATCH reads
'unused_var'. For example, see '_af_inet_info_u' in tapset/linux/syscalls.stpm.

- 'embedded_seen' can be referenced in cases that don't make sense for regex:
for example, 'embedded_seen=true' forbids an expression from being used in a
probe condition.

This PR should either be WONTFIXed or these issues should be dealt with, and
the side-effecting state of a regex match should be represented with something
other than 'embedded_seen'. Reverting the patch for now.

-- 
You are receiving this mail because:
You are the assignee for the bug.

[Bug translator/22193] Regex matching (=~) should be treated as a side-effecting operation

[mcermak at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=22193

Martin Cermak <mcermak at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mcermak at redhat dot com

--- Comment #3 from Martin Cermak <mcermak at redhat dot com> ---
After the aforementioned revert, systemtap.pass1-4/runok.exp started to fail.
It's because one of its subtests - regex_noelide.stp - started to fail.

This regex_noelide.stp historically had two variants, but I do not see a
difference between them from the practical point of view:

variant1: 'probe begin { "foo" =~ "f(.)"; println(matched(1)); exit() }'
variant2: 'probe begin { "foo" =~ "(f)oo"; println(matched(1)); exit() }'

This regex_noelide.stp was created at some point but it was failing till
commit 81e03c8fea, which prevented the elision.  Then it was passing till
f579ca5b46, which reverted 81e03c8fea.

(Confusing is that both 81e03c8fea and f579ca5b46 touched regex_noelide.stp,
but it was merely switching between variant1 and variant2 both of which
behave the same way.)

So now, after f579ca5b46, the elision happens again, and so the testcase is
failing.  Shouldn't it simply get dropped?

-- 
You are receiving this mail because:
You are the assignee for the bug.