Author Topic: Find not finding  (Read 3905 times)

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Find not finding
« on: July 19, 2012, 05:25:10 pm »
Slickedit V17 with hotfix 1

I have a file with several instances of "pacer_timer->Interval ..." in it. If I position the cursor at the start of the file and then do a find for "Interval" via Ctrl-F, only the last instance is found.

If I then Ctrl-Home to get to the start of the file again, the hit Ctrl-G, every instance is found (including those where "Instance" is part of a larger word).

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2920
  • Hero Points: 438
Re: Find not finding
« Reply #1 on: July 20, 2012, 12:24:45 pm »
Think you could obfuscate the source file and post it so that we could reproduce the problem?  To obfuscate, in this case, from the SlickEdit command line:

c/Interval/#12#53#36#15#11#/
c/[a-z]/x/riXk
c/#12#53#36#15#11#/Interval/
c/while/if/ew

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #2 on: July 20, 2012, 03:33:30 pm »
Unfortunately, the effect doesn't occur with the single file, or .c/.h pair. I built a new project by using a different compiler option and it's fine in that too. I suspect the fault is actually in the compiler tag file, which in this case is the Embarcadero RAD Studio and, as mentioned elsewhere, rocks in at 280MB or so.

I have had some problems related to this, I think. On adding new class members I often get a SE stack fault when typing in function parameter names. This only occurs in the .h file, appears to be in the C parser, and leaves SE in a state where it has to be restarted.

Prior to my report, I had right clicked 'Interval' and selected 'show references', whereupon SE went off and chewed significant CPU for more than 5 minutes until I killed it off. A subsequent attempt (after saving the work that I had to repeat through losing it the first time) correctly threw up the 3 instances in my code. It was while doing a search to check that there were only 3 instances that I discovered the find problem.

I am happy to send you the compiler tag file if you think that would help. I appreciate that it is tricky to investigate this without being able to replicate it on demand.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2920
  • Hero Points: 438
Re: Find not finding
« Reply #3 on: July 20, 2012, 03:52:38 pm »
Your original post (in this thread) was simply talking about doing a text find in a single file.  So are you now saying that this does not happen?  Or that you have to do a multi-file search, or that you were really reporting a problem with finding references using tagging?

Could you post the Slick-C stack you got from function-parameter help?  You should be able to retrieve it from vs.log in your SlickEdit configuration directory under 'logs'.

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #4 on: July 20, 2012, 05:01:01 pm »
Not sure how the misunderstanding has occured, but to clarify:

Quote
Your original post (in this thread) was simply talking about doing a text find in a single file

Yes, it is about that. I hit Ctl-F to search in a single file for the string 'Interval'.

However, you asked me to send you the files. I checked before doing that that the problem occurs if only that file exists, and it doesn't. Neither does it occur if the file is part of a project that doesn't use the RAD tag file. But it is 100% repeatable if the file is part of a project and that project used the RAD tag file.

For that reason, there seems little point in sending you either the file or the project since you would also need the 280MB tag file to replicate the problem.

As an aside, I mentioned the stack thing and the crash, because it seems to me that all of these are related. That is, the tag file is causing the crash on creating class members, and it caused the lockup when finding references, and somehow it confuses the find function. So whilst all these things are not part of the find problem that is the basis of this report, I think they are evidence that would be useful to know.

Hope that clears things up.
Quote
Could you post the Slick-C stack you got from function-parameter help?

Coming up. A small point, though: there shouldn't be function-parameter help at that stage since I am creating the class member and it therefore can't exist in the tag file yet.

Code: [Select]
[T=16988] autocomplete.ex 7955 autocomplete:AutoCompleteGetSymbols(-3178513,0,Message,1,1077936128,440,
[T=16989]    7:   ._typename()=VS-TAG-IDEXP-INFO
[T=16989]    7:   .errorArgs=<empty>
[T=16989]    7:   .prefixexp=
[T=16989]    7:   .lastid=Message
[T=16990]    7:   .lastidstart-col=51
[T=16990]    7:   .lastidstart-offset=702
[T=16990]    7:   .info-flags=262146
[T=16990]    7:   .otherinfo=&
[T=16990]    7:   .prefixexpstart-offset=702
[T=16991]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;]._typename()=VS-TAG-RETURN-TYPE
[T=16991]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].return-type=(null)
[T=16991]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].taginfo=(null)
[T=16991]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].filename=(null)
[T=16992]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].line-number=0
[T=16992]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].pointer-count=0
[T=16992]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].istemplate=0
[T=16992]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].template-args:[\1]=
[T=16993]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].return-flags=0
[T=16993]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].template-names=(null)
[T=16993]    8:   :[parse;TWinControl;Controls;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;TControlActionLink;G:\Borland\RAD Studio 7\Embarcadero\RAD Studio\7.0\include\vcl\Controls.hpp;].template-types=(null)
[T=16993]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;]._typename()=VS-TAG-RETURN-TYPE
[T=16993]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].return-type=TMainForm
[T=16994]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].taginfo=TMainForm(class)
[T=16994]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].filename=D:\code\WheelySafe\LogReplay\LogReplay.h
[T=16994]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].line-number=21
[T=16994]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].pointer-count=0
[T=16995]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].istemplate=0
[T=16995]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].template-args=(null)
[T=16995]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].return-flags=2
[T=16995]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].template-names=(null)
[T=16995]    8:   :[match;TMainForm;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;0;0;1;1488;].template-types=(null)
[T=16996]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;]._typename()=VS-TAG-RETURN-TYPE
[T=16996]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].return-type=TMainForm
[T=16996]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].taginfo=TMainForm(class)
[T=16996]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].filename=D:\code\WheelySafe\LogReplay\LogReplay.h
[T=16997]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].line-number=21
[T=16997]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].pointer-count=0
[T=16997]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].istemplate=0
[T=16997]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].template-args=(null)
[T=16998]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].return-flags=2
[T=16998]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].template-names=(null)
[T=16998]    8:   :[get;TMainForm;;0;0;1488;1;D:\code\WheelySafe\LogReplay\LogReplay.h;].template-types=(null)
[T=16998]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;]._typename()=VS-TAG-RETURN-TYPE
[T=16998]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].return-type=TMainForm
[T=16999]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].taginfo=TMainForm(class)
[T=16999]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].filename=D:\code\WheelySafe\LogReplay\LogReplay.h
[T=16999]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].line-number=21
[T=17000]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].pointer-count=0
[T=17000]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].istemplate=0
[T=17000]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].template-args=(null)
[T=17000]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].return-flags=2
[T=17000]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].template-names=(null)
[T=17001]    8:   :[parse;ReceiveTimerMessage;;D:\code\WheelySafe\LogReplay\LogReplay.h;TMainForm;D:\code\WheelySafe\LogReplay\LogReplay.h;].template-types=(null)
[T=17001]    p_window_id: 83
[T=17001]    p_object: OI_EDITOR
[T=17001]    p_name:

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2920
  • Hero Points: 438
Re: Find not finding
« Reply #5 on: July 20, 2012, 05:25:33 pm »
Please post the entire Slick-C stack, starting with
Code: [Select]
Slick-C STACK TRACE ******************************
Created on ...
SlickEdit Version 17.0.0 ...

Include everything all the way to the last frame.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2920
  • Hero Points: 438
Re: Find not finding
« Reply #6 on: July 20, 2012, 05:31:37 pm »
Doing a plain text search doesn't touch the tagging code, so it would not matter if you have the big tag file or not.  So, could you clarify, are you talking about a plain text search or searching for references using Ctrl+Slash ?

If you are doing a plain text search within a single file, and the circumstances you are reporting are true, then you should open a ticket with support and send us the project, including the offending tag file so that we can reproduce it.

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #7 on: July 20, 2012, 05:41:40 pm »
Sorry, Dennis, I thought the log was an accumulation of stack faults since there are many duplicate sections (it is 315K in total). Since it's not, I can't be sure that it is the result of the class member creation rather than the lock-up. Perhaps it would be better if I wait until the next occurence and then post the full thing in a new thread?

Quote
So, could you clarify, are you talking about a plain text search or searching for references using Ctrl+Slash ?

Yes, this originated from a plain text search and not a references lookup or anything similar.

Quote
open a ticket with support and send us the project

I need to check that any info embedded in it isn't sensitive first. I've just discovered that there is a newer version of SE, so perhaps I should install that and see if the problem persists.


Graeme

  • Senior Community Member
  • Posts: 2432
  • Hero Points: 322
Re: Find not finding
« Reply #8 on: July 20, 2012, 11:34:33 pm »
Quote
I thought the log was an accumulation of stack faults since there are many duplicate sections (it is 315K in total).

It is an accumulation of stack faults with the most recent at the end of the file.  Each new stack fault starts with  Slick-C STACK TRACE ******

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #9 on: July 21, 2012, 02:56:14 pm »
[blush]
I just noticed that the find dialog was sent to <All Buffers>. If I change that to <Current Buffer> then Ctrl-F finds the stuff it didn't (that is, it's consistent with Ctl-G).

Does that make a difference? Even if it is set to <All Buffers> shouldn't it still find the string, and shouldn't Ctlf-F (find dialog) and Ctl-G (find next) select the same things?

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #10 on: July 21, 2012, 06:40:02 pm »
Trying to narrow this down, it is the all buffers thing rather than the project or tag file that causes the problem. Further, I can replicate this with another project (different search term) and SE 16.0.3.

I haven't managed to get it to happen when loading a single file or several discrete files, but it does occur more often than not if I do the same search on the same file as part of a project. That suggests to me that it's a SE project thing and not my specific project.

If it makes a difference, pretty much all of my source files (that is, the working directory) are in a different directory to the SE project and workspace files. I would think that searching buffers wouldn't take not of that, though.

Dennis

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 2920
  • Hero Points: 438
Re: Find not finding
« Reply #11 on: July 23, 2012, 01:54:20 pm »
Are you sure you are positioning the cursor at the top of the file or just merely scrolling to the top of the file?  The search starts at the cursor position, not viewing position.

You might also get more consistent results if you turn on the "Wrap at beginning/end" option.  I like to set this to the "in-between" state so that it prompts before wrapping to the start of the file.

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #12 on: July 24, 2012, 09:04:59 am »
I position the cursor with Ctl-Home, but also by scrolling to the top of the file and then clicking at the start so the cursor is flashing away on the first line. If it's not at the start I think that's a more important bug to fix :)

Quote
You might also get more consistent results if you turn on the "Wrap at beginning/end" option.

That's not really a useful workaround, I have to say, and it still leaves the problem that there is something amiss.

I've managed to pinpoint this some more. I start with no project or workspace loaded then open two files. At this point there is a single edit window open, and two buffer tabs. I search (all buffers) for a string which is the leading part of some variable and happens to occur 4 times in the displayed file. The first instance is correctly found.

Now, I duplicate the window and then tile the two resulting edit windows (they are side-by-side, my preferred layout). I do exactly the same search on the same file (in the left window, although both windows show the same file), but this time the last instance is found! Ubelievably, it seems that the window layout may be a factor.

It gets better: in order to verify that it is not, say, searching in the wrong window, I change the right edit window to show the other buffer. Now find doesn't fine any instance at all! I change to <current buffer> and the first instance is correctly found, back to <all buffers> and nothing is found.

If you find this hard to replicate I can probably run off a video or something.

Lee

  • SlickEdit Team Member
  • Senior Community Member
  • *
  • Posts: 1299
  • Hero Points: 130
Re: Find not finding
« Reply #13 on: July 24, 2012, 12:32:22 pm »
I have replicated the issue with using Find, All Buffers.  I will see if it can be hotfixed, or at least fixed for next release.

dunkers

  • Senior Community Member
  • Posts: 689
  • Hero Points: 28
Re: Find not finding
« Reply #14 on: July 24, 2012, 01:21:33 pm »
Phew! Thanks, Lee :)