Can you find this bug?

Index > OS Construction > Can you find this bug?

Author

Thread

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 29 Jan 2010, 15:42

I am playing with Nano OS...
After a bunch of keystrokes it locks up. (about 8 lines worth)
The bug appears when echo'ing keystrokes or even
running the hello world application a bunch of times
(not necessarily sequential, breaks in time make no difference)
I have found (through Bochs) that DS is getting trashed somewhere.
I think the problem may be in the irq_timer routine.
Please help me, i have tried to fix this for a week now Sad

Description:		Download
Filename:	nanoos2.zip
Filesize:	4.32 KB
Downloaded:	404 Time(s)

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.

29 Jan 2010, 15:42

edfed

Joined: 20 Feb 2006
Posts: 4334
Location: Now

edfed 29 Jan 2010, 16:04

Code:

timer_irq:
    push   bp                                          ; save task context
    push   di
    push   si
    push   dx
    push   cx
    push   bx
    push   ax

yep, at least, save DS segment in irq handlers.

Code:

push ds cs 
pop ds

29 Jan 2010, 16:04

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 29 Jan 2010, 17:12

Were you able to reproduce this error i speak of?
And why pop CS into DS and let old DS hang?

29 Jan 2010, 17:12

edfed

Joined: 20 Feb 2006
Posts: 4334
Location: Now

edfed 29 Jan 2010, 18:24

i test it as a .com.

i deleted some lines and boot stuff.

i don't have any error.
but i have a BEEEEEP if i try what you say.
then, i predict a keyboard buffer bug.
or things like that.

old DS will not hang if it is not corumpted by IRQ0.

29 Jan 2010, 18:24

edfed

Joined: 20 Feb 2006
Posts: 4334
Location: Now

edfed 29 Jan 2010, 18:43

ok, i got it, i crashes the system in full screen.
then, it is not simple to test.

29 Jan 2010, 18:43

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 29 Jan 2010, 19:47

I recommend using original sources as not to introduce any NEW bugs...

Now i have a bit more info.
If i do code like this...

Code:

timer_irq:
    push   bp                                          ; save task context
    push   di
    push   si
    push   dx
    push   cx
    push   bx
    push   ax

    push   07C0h
    pop    ds

   ...

It seems to be fixed...

Of course since the original sources are 511 bytes (before padding)
you will need to free a few bytes to use it, which should be no problem
since i was easily able to free 100+ bytes from the demo W/O sacrifice.

-- -------------------------------------------------------------------------------

NEW BUG or SAME BUG?
Now, while holding down a key for a long time eventually i get
a NULL character printed to the screen (WTF is happening)
But a simple .com test i did does not ever show this happen.
So it has something to do with BIOS keyboard service inside timer IRQ...

If you comment out this chunk you can see it happen...

Code:

prg1:
    mov    cx, prg2
    call   sys_exec
    mov    di, bx
prg1_0:
    call   sys_getc
    ;;;;;;or     ax, ax   ;;;;;; COMMENTED OUT
    ;;;;;;jz     prg1_0   ;;;;;; COMMENTED OUT
    cmp    al, 'H'
    je     prg1_1
    mov    bx, di
    call   sys_send
    jmp    prg1_0
prg1_1:
    mov    cx, prg3
    call   sys_exec
    jmp    prg1_0

It seem there is problem with BIOS keyboard service within timer IRQ.
Maybe with KB buffer overflow causing it...

Ahh, more work to do...

29 Jan 2010, 19:47

edfed

Joined: 20 Feb 2006
Posts: 4334
Location: Now

edfed 29 Jan 2010, 20:05

maybe a fix will be possible with a new IRQ1 (keyboard) handler in mode 3.

i cutted your code in slices, then, it will be easy to find the code to modify.

the beep is a problem with timer and keyboard IRQs.

Description:		Download
Filename:	nanoos2.zip
Filesize:	12.07 KB
Downloaded:	386 Time(s)

29 Jan 2010, 20:05

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 30 Jan 2010, 02:07

I have been reading about BIOS keyboard buffer.
Maybe when the BIOS remaps (enlarges) the buffer
it is putting a NULL character in the stream and trashing my DS?

Quote:

3.3. Keyboard Buffer
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

The keyboard buffer is a circular data area. This means that when a
pointer in the buffer gets one larger than the buffer, it is wrapped
around to the beginning.

The keyboard buffer is fed by int 9 and function 5 of int 16h. It is
found at the BIOS data segment, 40h. It is pointed to by 4 variables in
the BDA: The head (1ah), the tail (1ch), the Beginning (80h) and the
End (82h). They are all words, pointing at locations in the BDA.

The latter two are only available on ATs and PSs. They are used to
enlarge the keyboard buffer by mapping it to another spot in the BIOS
data area. Normally, that spot is 32 bytes long starting from 1eh.

The head is the pointer to the next word. The tail is the pointer to
the next available word. Each code is two bytes, the scan code and the
ASCII value.

The buffer is empty if the Head = the Tail and it is full if the Tail
is two smaller than the Head, both counted circularly. This means that
the storage space equals (length buffer/2)-1.

I think i need to make a non-BIOS keyboard driver and try it...
Get the whole document here...

Description:		Download
Filename:	kbguide.txt
Filesize:	48.21 KB
Downloaded:	392 Time(s)

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.

30 Jan 2010, 02:07

revolution
When all else fails, read the source

Joined: 24 Aug 2004
Posts: 20338
Location: In your JS exploiting you and your system

revolution 30 Jan 2010, 02:13

bitshifter wrote:

Maybe when the BIOS remaps (enlarges) the buffer
it is putting a NULL character in the stream and trashing my DS?

I doubt that. It will most likely be your bug.

30 Jan 2010, 02:13

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 30 Jan 2010, 15:56

Ok, so after much more testing i think i finally fixed it!
It turns out that DS was junk upon entry of timer_irq
by putting sentinels at the entry and exit i found this out.
The demo can idle forever without any problems but as soon
as you start to use the BIOS keyboard services things go downhill...

So...
I wrote an INT 09 IRQ1 keyboard handler to replace BIOS int 16h
Now BOTH bugs have vanished forever (so it seems)
I wonder if the BIOS was using INT 08 IRQ0 and blowing shit up?

Sad story...
So i shaved over 100 bytes from the original sources so
i could include a sweet task debugger, now at 511 bytes.
Removed debugger to insert keyboard handler (no scan conversion table)
So now i have a choice, a cool debugger with bugs, or no debugger or bugs...

Maybe i will post a complete fix for the sources if people are interested...

_________________
Coding a 3D game engine with fasm is like trying to eat an elephant,
you just have to keep focused and take it one 'byte' at a time.

30 Jan 2010, 15:56

bitshifter

Joined: 04 Dec 2007
Posts: 796
Location: Massachusetts, USA

bitshifter 30 Jan 2010, 17:52

I forgot to mention that DS = 0040h upon error...
That is the BIOS data area segment!

Progress:
Need to free 19 more bytes...
Then we will have all the cool stuff and no bugs!
Woohoo...

30 Jan 2010, 17:52

< 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