SciTE freeze on Find (regex)

125 views
Skip to first unread message

zetah

unread,
Dec 19, 2011, 11:34:02 AM12/19/11
to scite-interest
I use 3.0.2 binary (from SciTE download site) on Ubuntu 11.04

Working with some text files I noticed this (reproducible):

regex search pattern ".*\d$"

I hit match all and continue to work

after that I try to search same pattern again and SciTE freezes and I
must terminate process

I tried some some other regex pattern but no problem with repeated
search. Must be some bug

While here, also "SciTE help" menu action doesn't work. HTML files are
on usual location /usr/share/scite/

zetah

unread,
Dec 19, 2011, 11:38:47 AM12/19/11
to scite-interest
I forgot to add also that sometimes SciTE looses focus and it's
somewhat tricky to gain it back. It could be problem with Compiz, but
I noticed this only with SciTE when I drag and drop files on SciTE
launcher

Neil Hodgson

unread,
Dec 19, 2011, 5:32:25 PM12/19/11
to scite-i...@googlegroups.com
zetah:

> Working with some text files I noticed this (reproducible):
>
> regex search pattern ".*\d$"
>
> I hit match all and continue to work
>
> after that I try to search same pattern again and SciTE freezes and I
> must terminate process

Can't reproduce this. Perhaps there is some feature of the files or
the subsequent expression that is associated with this behaviour.

> While here, also "SciTE help" menu action doesn't work. HTML files are
> on usual location /usr/share/scite/

If the global options was installed in the right spot then it
should be calling xdg-open which works for me although there is a
warning from firefox-bin. There may be a stale options file that calls
netscape which is no longer installed.

Looks like the window manager has gone into a strange mode.

Neil

zetah

unread,
Dec 20, 2011, 5:33:32 PM12/20/11
to scite-interest

On Dec 19, 11:32 pm, Neil Hodgson <nyamaton...@gmail.com> wrote:
> zetah:
>
> > Working with some text files I noticed this (reproducible):
>
> > regex search pattern ".*\d$"
>
> > I hit match all and continue to work
>
> > after that I try to search same pattern again and SciTE freezes and I
> > must terminate process
>
>    Can't reproduce this. Perhaps there is some feature of the files or
> the subsequent expression that is associated with this behaviour.

Perhaps it depends on file content. Here is how it can be reproduced:
Open text file (some README or similar with more then ~100 text lines)
and Find "match all" this pattern ".*\w$". Then try again


> > While here, also "SciTE help" menu action doesn't work. HTML files are
> > on usual location /usr/share/scite/
>
>    If the global options was installed in the right spot then it
> should be calling xdg-open which works for me although there is a
> warning from firefox-bin. There may be a stale options file that calls
> netscape which is no longer installed.

If you mean about "SciTEGlobal.properties" it's on same place as help
files : /usr/share/scite/


> > I forgot to add also that sometimes SciTE looses focus and it's
> > somewhat tricky to gain it back. It could be problem with Compiz, but
> > I noticed this only with SciTE when I drag and drop files on SciTE
> > launcher
>
>    Looks like the window manager has gone into a strange mode.

Yeah, Compiz is not the most reliable manager, but it's default on
Ubuntu

Neil Hodgson

unread,
Dec 21, 2011, 1:08:15 AM12/21/11
to scite-i...@googlegroups.com
zetah:

> Perhaps it depends on file content. Here is how it can be reproduced:
> Open text file (some README or similar with more then ~100 text lines)
> and Find "match all" this pattern ".*\w$". Then try again

Could not reproduce with this file:
http://heterobetainas.uah.es/jmol/README.txt

Neil

zetah

unread,
Dec 21, 2011, 3:32:20 PM12/21/11
to scite-interest
Sorry Neil, I should have provided example file, but I thought it's
easy to reproduce

Here is example file: http://pastebin.com/raw.php?i=sD2pgbmH

It even freezes SciTE on first try to match all ".*\d$"

Neil Hodgson

unread,
Dec 21, 2011, 7:00:16 PM12/21/11
to scite-i...@googlegroups.com
zetah:

> Here is example file: http://pastebin.com/raw.php?i=sD2pgbmH
>
> It even freezes SciTE on first try to match all ".*\d$"

This does not freeze for me. You could try running under a debugger
to get a stack trace when the freeze occurs.

Neil

John Yeung

unread,
Dec 22, 2011, 12:00:09 AM12/22/11
to scite-i...@googlegroups.com
On Wed, Dec 21, 2011 at 7:00 PM, Neil Hodgson <nyama...@gmail.com> wrote:
> zetah:
>
>> Here is example file: http://pastebin.com/raw.php?i=sD2pgbmH
>>
>> It even freezes SciTE on first try to match all ".*\d$"

I have not been able to get SciTE to freeze either, using 3.0.2 on
Windows XP. Well, I should say that while I used the test file at the
link above, I didn't do "match all" because I don't see that feature.
I used the regular expression match to repeatedly find one at a time,
and I used it to "Mark All", and neither of those gave me any problems
that I noticed.

John

Holger Kohnen

unread,
Dec 22, 2011, 4:21:08 AM12/22/11
to scite-i...@googlegroups.com
Same here (ubuntu 11.04, scite build from mercurial - gtk2),
but it freezes not if have:

open.asynchronous=0

in .SciTEUser.properties i was required to restart SciTE.

best regards, Holger

2011/12/22 John Yeung <gallium....@gmail.com>:

> --
> You received this message because you are subscribed to the Google Groups "scite-interest" group.
> To post to this group, send email to scite-i...@googlegroups.com.
> To unsubscribe from this group, send email to scite-interes...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/scite-interest?hl=en.
>

--
Holger Kohnen
(Webentwickler)

Anklamer Str. 35
10115 Berlin

h.ko...@gmail.com
http://www.holgerkohnen.de

030 / 788 37 22
0173 / 38 62 791

zetah

unread,
Dec 22, 2011, 3:55:02 PM12/22/11
to scite-interest
I run SciTE in gdb and could not reproduce

I run SciTE normally and now I can't reproduce in normal state either,
like something was triggered after running in debugger

Now this looks bad... I'll try from time to time to reproduce and
hopefully get stack trace

Sorry for wasting your time

zetah

unread,
Dec 22, 2011, 4:39:13 PM12/22/11
to scite-interest
OK, I reproduced it again by double copy text

Here is screenshot: http://i.imgur.com/0tpFs.png

SciTE window is dimmed like every unresponsive program on my OS

I still can't reproduce with gdb

CPU usage is high and process never finishes as I left SciTE like that
for some time. Although CPU isn't used greedy (20-25% on P4 3GHz) so
it doesn't stop me doing other things

About help file I mentioned earlier... I didn't know about setting in
global preferences - "command.scite.help" which wasn't present in my
SciTE global properties and I corrected that, so everything is perfect
now

Neil Hodgson

unread,
Dec 22, 2011, 7:37:31 PM12/22/11
to scite-i...@googlegroups.com
Holger Kohnen:

> Same here (ubuntu 11.04, scite build from mercurial - gtk2),
> but it freezes not if have:
>
> open.asynchronous=0
>
> in .SciTEUser.properties i was required to restart SciTE.

open.asynchronous was dropped from 3.0.2 and should have no effect.
This behaviour is now controlled with the background.open.size and
background.save.size properties.

Neil

zetah

unread,
Dec 23, 2011, 3:23:45 AM12/23/11
to scite-interest
I didn't know I can attach to running process.

Here is bt from attaching to hanged scite process: http://pastebin.com/raw.php?i=9a9h0m91

I hope this is what you asked Neil

Neil Hodgson

unread,
Dec 23, 2011, 5:38:41 AM12/23/11
to scite-i...@googlegroups.com
zetah:

> I didn't know I can attach to running process.
>
> Here is bt from attaching to hanged scite process: http://pastebin.com/raw.php?i=9a9h0m91

While it doesn't have symbols for SciTE or Scintilla, its in
ScintillaGTK::ClaimSelection asking to own the primary selection,
probably after setting the selection as a result of a dialog action.
The arguments to the gtk_selection_owner_set call are fairly simple
and unlikely to go wrong. Its communicating with the X server so
perhaps there is another application monitoring the primary selection
or this is a remote X session. Its also possible that there is a loop
in SciTE setting the selection repeatedly.

Neil

zetah

unread,
Dec 23, 2011, 6:25:50 AM12/23/11
to scite-interest
So that's why it wasn't easy to reproduce - if I had left selection in
editor and do a search/mark all than it would freeze. If I didn't had
selection in editor and do the same then it doesn't freeze.

I checked it and it's like that.

Thanks for explanation. Now I can avoid this problem :)

zetah

unread,
Jan 5, 2012, 1:29:24 AM1/5/12
to scite-interest
I misinterpreted your reply too soon, unfortunately.

Main problem is not in some selected text. It happen couple of times
afterwards without anything selected in editor. Backtrace is exactly
same as previously posted. I also changed my clipboard manager, just
in case - this is still open issue to me.

Alfred Peters

unread,
Feb 19, 2012, 6:53:52 AM2/19/12
to scite-i...@googlegroups.com
Es schrieb einmal zetah:

> same as previously posted. I also changed my clipboard manager, just
> in case - this is still open issue to me.

I can reproduce this even with Windows XP. I noticed that you are using
Linux, but your testfile[1] has CRLF line-ends. So if I load your file,
change the SciTE line-end setting to LF and do Find->".*\d$"->Mark All, I
get an unresponsive SciTE. Sometimes SciTE finds some random lines on the
first run, but at last on the second run it get stuck.

> On Dec 23 2011, 11:38 am, Neil Hodgson <nyamaton...@gmail.com> wrote:
>> or this is a remote X session. Its also possible that there is a loop
>> in SciTE setting the selection repeatedly.

Yes. With that line-end setting the expression shouldn't match any line,
because there is always a CR char between the last \d and the
lineend (LF). The Problem is, that SciTE doesn't find the starting point
either. So it is spinning around ("Wrap around") again and again. I can
see this because the slider moves up and down, and the spin-around-sound
is played every few ms ;-)

HTH
Alfred

[1] <http://pastebin.com/raw.php?i=sD2pgbmH>
--
12135.3

Neil Hodgson

unread,
Feb 22, 2012, 7:08:02 AM2/22/12
to scite-i...@googlegroups.com
Alfred Peters:

> Yes. With that line-end setting the expression shouldn't match any line,
> because there is always a CR char between the last \d and the
> lineend (LF).

That's not it. The problem is that the caret is inside a match for
the regular expression. The search starts from the caret and matches
immediately at the caret. The search continues to match later lines
then loops back to the beginning and up towards the first line that
matched. On the line of the first match it matches from the start of
the line which is a different position from the initial match which
was part way along the line. Because it isn't the same location, the
loop doesn't terminate.

Neil

Neil Hodgson

unread,
Feb 26, 2012, 10:48:24 PM2/26/12
to scite-i...@googlegroups.com
Committed a fix for the freeze on find bug. The resulting marks may
not be as expected as the loop stops before creating a mark that will
overlap the initial mark, so for the example ".*\d$" the contents of
the line before the caret position will not be marked.

Available from Hg and from
http://www.scintilla.org/scite.zip Source
http://www.scintilla.org/wscite.zip Windows executable

Neil

Reply all
Reply to author
Forward
0 new messages