flat assembler - [BUG DOS IDE] - hangs if text has absurdly long line

Index > IDE Development > [BUG DOS IDE] - hangs if text has absurdly long line

Author

Thread

DOS386

Joined: 08 Dec 2006
Posts: 1903

DOS386 27 Oct 2014, 07:59

Flaw: saving is slow

BUG: saving hangs permanently if text in the editor has an absurdly long line

Code:

        mov     ecx,1000h
        mov     [line_buffer_size],ecx
        call    get_memory
        or      eax,eax
        jz      startup_failed
        mov     [line_buffer],eax
        mov     [line_buffer_handle],ebx

OK, more than 4096 char's is fatal ... but I can create such lines when editing!!!

Code:

    flush_to_file:
        push    esi
        mov     edx,[line_buffer]
        mov     ecx,edi
        sub     ecx,edx
        mov     ebx,[file_handle]
        call    write

Does it call the sub "write" and DOS for every single (even empty) line?

Code:

        cmp     [line_buffer],0
        je      line_buffer_reallocate
        cmp     ecx,[line_buffer_size]
        jbe     line_buffer_ok
        mov     [line_buffer],0
        push    ecx
        mov     ebx,[line_buffer_handle]
        call    release_memory
        pop     ecx
    line_buffer_reallocate:
        call    get_memory
        or      eax,eax
        jz      memory_shortage
        mov     [line_buffer],eax
        mov     [line_buffer_handle],ebx
    line_buffer_ok:

It doesn't seem to update "line_buffer_size" ... maybe BUG ?

27 Oct 2014, 07:59

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 27 Oct 2014, 12:06

DOS386 wrote:

It doesn't seem to update "line_buffer_size" ... maybe BUG ?

Yes, this is exactly the problem. I'm uploading to corrected version now.

I'm really glad there is someone who still uses the DOS version. Wink

Myself I use it quite rarely nowadays (though still probably relatively frequently, considering how often DOS is used at all now) so many bugs go unnoticed.

27 Oct 2014, 12:06

DOS386

Joined: 08 Dec 2006
Posts: 1903

DOS386 09 Nov 2014, 06:05

> I'm uploading to corrected version now.

One instruction added and Hang-BUG seems fixed Smile

(unstick the thread now?)

What about the ZERO-and-Truncation-BUG ( http://board.flatassembler.net/topic.php?t=12553 ) ? Consider some 3rd party text, load it into FASM, edit a single trivial typo, save it back, and find out that typo is gone but the text is truncated now (data loss!) because the text had a ZERO inside?

09 Nov 2014, 06:05

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 09 Nov 2014, 12:38

DOS386 wrote:

What about the ZERO-and-Truncation-BUG ( http://board.flatassembler.net/topic.php?t=12553 ) ? Consider some 3rd party text, load it into FASM, edit a single trivial typo, save it back, and find out that typo is gone but the text is truncated now (data loss!) because the text had a ZERO inside?

fedit follows the same text interpretation rules as fasm, including the fact that it treats the zero character as EOF (in addition to the 1Ah character).This reflects the fact that fedit and fasm were supposed to complement each other, though it may have unfortunate consequences when working with some third-party texts. There are other rules, like the treatment of line breaks, that are also specific to fasm+fedit pair.

09 Nov 2014, 12:38

DOS386

Joined: 08 Dec 2006
Posts: 1903

DOS386 12 Nov 2014, 07:45

> may have unfortunate consequences when working with some third-party texts

But it's actually broken even with 1st-party own texts, steps to reproduce (see shot below):

1. run FASM DOS IDE
2. type in some text
3. in the middle of the text push <CTL>-<BREAK> (Observed behavior: SPACE gets inserted)
4. save the text and exit
5. relaunch loading the just saved text

Expected behavior: you can see your complete text

Observed behavior: the text is truncated, at the location where you had pushed <CTL>-<BREAK>

<CTL>-<BREAK> inserts a ZERO into the text. If this is not a BUG ...

Description:	BUG-shot for 2 BUG's
Filesize:	2.12 KB
Viewed:	11300 Time(s)

12 Nov 2014, 07:45

Tomasz Grysztar

Joined: 16 Jun 2003
Posts: 8356
Location: Kraków, Poland

Tomasz Grysztar 12 Nov 2014, 10:48

DOS386 wrote:

<CTL>-<BREAK> inserts a ZERO into the text. If this is not a BUG ...

It certainly is a bug, Ctrl+Break should not insert any character there (and it did not when I tested it now - I'll try later on some other machines).

12 Nov 2014, 10:48

DOS386

Joined: 08 Dec 2006
Posts: 1903

DOS386 13 Jan 2015, 10:05

> Ctrl+Break should not insert any character there (and it did not
> when I tested it now - I'll try later on some other machines

The bug is still in and the reproductability is "always". Better way to test (push <CTL>+<F9> to compile the bugged line) :

Code:

MOV EAX, "ABCD"   -> OK !

MOV EAX, "AB CD"  -> Value out of range !! 

MOV EAX, "AB CD"  -> Missing end quote !!!

in the middle line, I moved cursor to "C" and pushed <SPACE>

in the lower line, I moved cursor to "C" and pushed <CTL>+<BREAK>

The inserting of ZERO-encoded-SPACE can be revereted using <CTL>+<Z>, also <DEL> can remove it.

13 Jan 2015, 10:05

< Last Thread | Next Thread >

Forum Rules:

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum