[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 308308] New: virtuoso-t cpu usage is at 100% triggered by a search starting with a non-alphanum
From:       <bobsbugs052 () gmail ! com>
Date:       2012-10-12 20:59:39
Message-ID: bug-308308-17878 () http ! bugs ! kde ! org/
[Download RAW message or body]

https://bugs.kde.org/show_bug.cgi?id=308308

            Bug ID: 308308
          Severity: normal
           Version: 4.9
          Priority: NOR
          Assignee: nepomuk-bugs@kde.org
           Summary: virtuoso-t cpu usage is at 100% triggered by a search
                    starting with a non-alphanumeric character .
    Classification: Unclassified
                OS: Linux
          Reporter: bobsbugs052@gmail.com
          Hardware: Fedora RPMs
            Status: UNCONFIRMED
         Component: general
           Product: nepomuk

I found virtuoso-t using 100% of the cpu.  Attaching with gdb multiple times
resulted in similar backtraces.  Stepping through (see below) showed an
infinite loop triggered by a search starting with a '.'.  The search is one I
initiated a day or two ago.  I believe I have restarted akonadi since that
search as it resulted in a freeze of kmail.

Reproducible: Didn't try




I am using Fedora-17 updated a few days ago.  The relevant package is
virtuoso-opensource-6.1.6-1.fc17.x86_64

The search passed into st_utf8_str_contains_unaccented_ucase_wstr as given when
gdb did the attach is

    needle=0x36e41dc L"TGZ", needle@entry=0x36e41d8 L".TGZ"

I believe the leading '.' is key to triggering this.

Below is the stepping through the loop with gdb.  I have edited the strings to
shorten them.  Note that the code at line 119 of bif_search_excerpt.c moves
haystack one character forward while the code at line 122 moves it one
character backward resulting in a loop that repeats forever.  It appears that
first_utf8len is -1.  Looking at the code between lines 107 and 114 it makes
sense that that would be the case.  Line 111

  first_utf8len = (first_utf8buf - res);

appears to be the cause of the problem.  It subtracts the advanced pointer from
the reference which will produce a number less than or equal to zero.


(gdb) next
120           if (NULL == haystack)
(gdb) p haystack
$25 = (const utf8char *) 0x7f3c78145572 ".\n\nI know "...
(gdb) next
122           haystack += first_utf8len;
(gdb) p haystack
$26 = (const utf8char *) 0x7f3c78145572 ".\n\nI know "...
(gdb) next
127            ndl_first = ndl[0];
(gdb) p haystack
$27 = (const utf8char *) 0x7f3c78145571 "w.\n\nI know "...
(gdb) p ndl_first
$28 = <optimized out>
(gdb) next
124        hstk = haystack, ndl = needle;
(gdb) p ndl_first
$29 = <optimized out>
(gdb) next
128            if (0 == ndl_first)
(gdb) next
130            hstk_first = eh_decode_char__UTF8 ((__constcharptr *)(&hstk),
(const char *)(hstk + MAX_UTF8_CHAR));
(gdb) next
131            if (!hstk_first)
(gdb) next
133            hstk_first = unicode3_getupperbasechar (hstk_first);
(gdb) next
134            if (hstk_first != ndl_first)
(gdb) next
136                if (!first_is_plain)
(gdb) next
119           haystack = (utf8char *)((1 == first_utf8len) ? strchr ((const
char *)haystack, first_wide) : strstr ((const char *)haystack, (char
*)first_utf8buf));
(gdb) p haystack
$30 = (const utf8char *) 0x7f3c78145571 "w.\n\nI know "...
(gdb) next
120           if (NULL == haystack)
(gdb) p haystack
$31 = (const utf8char *) 0x7f3c78145572 ".\n\nI know "...

-- 
You are receiving this mail because:
You are watching all bug changes.
[prev in list] [next in list] [prev in thread] [next in thread]