Bug Tracker

Ticket #11505 (closed bug: invalid)

Opened 3 years ago

Last modified 2 years ago

100% CPU slow parsing of `href[|=...]` selector

Reported by: trentm@… Owned by:
Priority: low Milestone: None
Component: selector Version: 1.7.1
Keywords: Cc:
Blocking: Blocked by:

Description

Using jquery 1.7.1 (min). Examples here are in the Chrome console (Google Chrome v17.0.963.83)

Start with this:

$("#sidebar a[href|=#xxxxxxxxxxxxxxx'x]")
Error: Syntax error, unrecognized expression: href|=#xxxxxxxxxxxxxxx'x]

Now I'm going to increase the number of x's and show the amount of time taken. It increases faster than linearly such that you get apparent hangs if the string is at all long:

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:22:54 GMT-0700 (PDT)
Thu Mar 22 2012 15:22:54 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:23:00 GMT-0700 (PDT)
Thu Mar 22 2012 15:23:00 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:23:06 GMT-0700 (PDT)
Thu Mar 22 2012 15:23:07 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:23:11 GMT-0700 (PDT)
Thu Mar 22 2012 15:23:13 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:23:17 GMT-0700 (PDT)
Thu Mar 22 2012 15:23:21 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:23:26 GMT-0700 (PDT)
Thu Mar 22 2012 15:23:35 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:26:48 GMT-0700 (PDT)
Thu Mar 22 2012 15:27:05 GMT-0700 (PDT)
undefined

> console.log(new Date()); try { $("#sidebar a[href|=#xxxxxxxxxxxxxxxxxxxxxx'x]"); } catch(e) { console.log(new Date()) }
Thu Mar 22 2012 15:27:21 GMT-0700 (PDT)
Thu Mar 22 2012 15:27:55 GMT-0700 (PDT)
undefined

This shows the time to handle the selector growing from sub-second to over 34 seconds.

Change History

comment:1 Changed 3 years ago by anonymous

Here is a jsFiddle showing this behaviour:  http://jsfiddle.net/hx2T8/

Run that in Chrome and watch CPU usage. I was testing on Mac 10.6. Add more x's to make it take much longer.

comment:2 Changed 3 years ago by trentm

I just created an account (username 'trentm'). I added this bug and the first comment (with the jsfiddle.net link).

comment:3 follow-up: ↓ 4 Changed 3 years ago by dcherman

See:  http://api.jquery.com/category/selectors/

You need to escape your meta characters. When I ran that selector with the characters properly escaped, it was pretty instant.

comment:4 in reply to: ↑ 3 Changed 3 years ago by trentm

Agreed that for a valid selector I need to escape here. However, that isn't the bug I was logging.

The bug is that it takes an exponentially (or geometrically, not sure) longer time to determine that the selector is invalid syntax with the longer the 'value' field.

comment:5 Changed 2 years ago by dmethvin

It might be possible to tweak the regexp to prevent catastrophic backtracking, but when the input is invalid all bets are off.

comment:6 Changed 2 years ago by rwaldron

  • Priority changed from undecided to low
  • Resolution set to invalid
  • Status changed from new to closed
  • Component changed from unfiled to selector

Closing this, please provide a test case that uses a valid selector to re-open.

Note: See TracTickets for help on using tickets.