Page 3 of 5

Re: Bug in Multiview Search requester

Posted: Sun Aug 27, 2017 10:31 pm
by xenic
Raziel wrote: Has it been fixed in the meantime and could we have a quick fix, please?
What file were you able to reproduce it with? I tried several files in Multiview and no problem. I couldn't really test it in NotePad because the Find window stays open. I couldn't reproduce it in Multiviewer either.

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 8:24 am
by Raziel
xenic wrote:
Raziel wrote: Has it been fixed in the meantime and could we have a quick fix, please?
What file were you able to reproduce it with? I tried several files in Multiview and no problem. I couldn't really test it in NotePad because the Find window stays open. I couldn't reproduce it in Multiviewer either.
All text files that go beyond the scroll window (not sure if that matters, but small files tend to not bring the bug up, maybe there has to be some part of the memory filled before it comes up, don't know)

I'm using a big configure file from on of my projects and look for anything.

First search is a 50/50 chance to fail because the find window is adding some crap right after i pressed enter.
Second find (with pressing enter again to bring up the find window) has an even higher chance.

Chances cummulate the more searces you triggered, it gets unusable after some time.

Just tried right now, first search for "amiga" worked, second, third and fourth as well, fifth brought up an error and the find field had this inside: "amigannfo)"...i never typed anything else than "amiga" into that field.

There seem to be some stuff copied from a fixed memory address, as once the stuff is in the search field it never changes, it just shows more chars, but the stuff that is added always stays the same
It's not always readable, somethimes there is some special chars.

MultiEdit and NotePad seem not to be affected (regardless of what i wrote in the last post) as they use a different find approach, MultiViewer and MultiView are, as they use the "press enter to bring up find" approach, haven't tested any more programs as the bug is clearly there.


Edit: I just tried out of fun and simply kept pressing ENTER for a very long time...

This is the outcome in the search field:
amigannnnnn.pciennZnnn[D
Š°nnnX«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþnnºnnn[nnÂnn

I could keep on doing that and it will probably copy the whole memory to it...

This is the file if one needs a test case: https://github.com/scummvm/scummvm/blob ... /configure

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 11:15 am
by salass00
Raziel wrote: This is the file if one needs a test case: https://github.com/scummvm/scummvm/blob ... /configure
I tried reproducing the bug you described using this text file on my beta AmigaOS installation. I pressed RETURN about 50 times and not even once did the initially entered search term change from "amiga" to something else.

I also tried disabling the WORDWRAP and TABSIZE tooltypes to bring MultiView back to the default settings to see if that mattered but even then I was not able to reproduce this bug.

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 12:10 pm
by Raziel
salass00 wrote:
Raziel wrote: This is the file if one needs a test case: https://github.com/scummvm/scummvm/blob ... /configure
I tried reproducing the bug you described using this text file on my beta AmigaOS installation. I pressed RETURN about 50 times and not even once did the initially entered search term change from "amiga" to something else.

I also tried disabling the WORDWRAP and TABSIZE tooltypes to bring MultiView back to the default settings to see if that mattered but even then I was not able to reproduce this bug.
Do you need any more info from me?
Could you provide a debug binary or some tests i could do?

MultiView 53.8 (17.01.2014)
text.datatype 53.10 (21.09.2015)

It happens reproducable here.


Just tried once again and this is the find field after 20x pressing enter:
amigannfo)nþ«­ÊþnnnnnRÌÌÌÌÌÌÌÌ~(#?.info)nþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­Êþ«­

On some other bug on some other system piece, someone told me that those special chars point to (if converted to readable text) corrupted memory and/or some unfreed memory.

iirc that other bug was telling ABADCAFE if converted.
Can't remember what it was, i *think* it had to do with creating a blank text file in ram: (that bug has been fixed since)
Just something that came to mind, not sure if it's the case here as well.

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 12:40 pm
by salass00
OK, it took about 1000 more tries but I finally got it to fail.

I'm now looking at the text.datatype source code and I've found and fixed one bug to do with the search function. Not sure if it's the culprit though.

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 12:56 pm
by Raziel
Nice, can i test it?

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 9:18 pm
by salass00
Raziel wrote:Nice, can i test it?
I'm sorry, but no. I think that would be breaking the NDA.

Re: Bug in Multiview Search requester

Posted: Mon Aug 28, 2017 11:18 pm
by Raziel
salass00 wrote:
Raziel wrote:Nice, can i test it?
I'm sorry, but no. I think that would be breaking the NDA.
Ok, i don't want to break anything, but do we get a quick AmiUpdate fix then?

I guess i know the answer already...

Re: Bug in Multiview Search requester

Posted: Tue Oct 31, 2017 8:53 am
by Raziel
@salass00

One more question, if i may?

You said you fixed one specific bug in text.datatype that has to do with the search requester.
Might it also affect (and was this probably already fixed then) other text input fields?

Because i lately get more and more instances of file names (e.g. pictures i save to or rename, pictures i convert to other formats and save and such) getting a trailing letter "n" added to my file name (just like it was with the seach field).

It doesn't happen as often and obvious (at least on my system) as it did with the search fields, but it is revealing a more global problem, i believe.

Would that problem still lie inside text.datatype?

And if you are allowed to share it, what was the poblem with the search field bug?
Don't be afraid if the explanation is too technical, i love dirty talk ;-)

Thanks a lot

Re: Bug in Multiview Search requester

Posted: Tue Oct 31, 2017 7:56 pm
by xenic
Raziel wrote:Because i lately get more and more instances of file names (e.g. pictures i save to or rename, pictures i convert to other formats and save and such) getting a trailing letter "n" added to my file name (just like it was with the seach field).
I previously tried to reproduce the search bug with my X1000 but I tried again with your example file on my X5000 and could not reproduce it. With regard to your letter "n" problem; my AmigaONE keyboard that I got with my X1000 is now producing double "t" letters instead of a single "t" (i.e. tt instead of t). In light of that problem, I would suggest you try a different keyboard.