Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to index page
Thread view  Board view
DOS386

10.01.2008, 01:51
 

[BUG] ESP=0 | push | TripleFault | BOOM! | inside HDPMI32 ? (DOSX)

Post reply

Japheth wrote (IIRC, something like, in old, now deleted :no: forum) :

> The main benefit of running a DPMI application in Ring3 rather than Ring0
> is, that if a dead loop with decreasing stack pointer occurs (very stupid
> and very popular bug), in Ring0 it unavoidably runs into a TripleFault,
> while with application in in Ring3 the DPMI host easily can clean up the trouble.
I found a very interesting (critical/criminal) BUG in Ladsoft's INFOPAD , occurring if an external DOS based DPMI host on "raw" is present. CWSDPMI raises a PageFault - see shot:

[image]

Done in BOCHS (2.3.0). In BOCHS I could type the "dir" after, but didn't work, natively there is a hard freezer - no chance to type anything.

With HDPMI32, the bug becomes even more mallicious :clap: :

========================================================================
                        Bochs x86 Emulator 2.3
              Build from CVS snapshot on August 27, 2006
========================================================================
00000000000i[MEM0 ] 32.00MB
00000000000i[MEM0 ] rom at 0xffff0000/65536 ('BIOS')
00000000000i[MEM0 ] rom at 0xc0000/38400 ('VGAB')
00000480000i[WGUI ] dimension update x=720 y=400 fontheight=16 fontwidth=9 bpp=8
00000778154i[BIOS ] ata0-0: PCHS=59/16/63 translation=none LCHS=59/16/63
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] decrementESPForPush: push outside stack limits
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] can_push(): expand-up: SP > limit
00154790896i[CPU0 ] protected mode
00154790896i[CPU0 ] CS.d_b = 32 bit
00154790896i[CPU0 ] SS.d_b = 32 bit
00154790896i[CPU0 ] | EAX=00000000  EBX=00000000  ECX=00000000  EDX=00000000
00154790896i[CPU0 ] | ESP=fffffff8  EBP=00000000  ESI=00000000  EDI=00000000
00154790896i[CPU0 ] | IOPL=3 id vip vif ac vm RF nt of df if tf SF zf af pf CF
00154790896i[CPU0 ] | SEG selector     base    limit G D
00154790896i[CPU0 ] | SEG sltr(index|ti|rpl)     base    limit G D
00154790896i[CPU0 ] |  CS:0020( 0004| 0|  0) ff801000 00006787 0 1
00154790896i[CPU0 ] |  DS:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] |  SS:0028( 0005| 0|  0) 00026380 000ffffe 1 1
00154790896i[CPU0 ] |  ES:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] |  FS:00ff( 001f| 1|  3) 00000000 0000ffff 0 0
00154790896i[CPU0 ] |  GS:00e7( 001c| 1|  3) 00000000 000fffff 1 1
00154790896i[CPU0 ] | EIP=000000b8 (000000b8)
00154790896i[CPU0 ] | CR0=0x80000031 CR1=0 CR2=0x00000000
00154790896i[CPU0 ] | CR3=0x01fff000 CR4=0x00000200
00154790896i[CPU0 ] >> push ds : 1E
00154790896e[CPU0 ] exception(): 3rd (12) exception with no resolution, shutdown status is 00h, resetting
00154790896i[SYS  ] bx_pc_system_c::Reset(SOFTWARE) called
00154790896i[APIC0] local apic in CPU 0 initializing

Seems that something (damaging HDPMI code in low memory ?) pushes HDPMI into such a self-destructive activity :clap:

It is a bug a INFOPAD, but posting here because 1st CC386 forum is almost dead and 2nd it's a very interesting DOSX/DPMI issue :lol3:

Any ideas what could be the reason of the bug ? Low memory corruption ?

No bug symptoms without CWS/H-DPMI, no bug symptoms with EMM386.

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Japheth

Homepage

Germany (South),
10.01.2008, 07:01

@ DOS386
 

What about CuteMouse?

Post reply

> Japheth wrote (IIRC, something like, in old, now deleted :no: forum):
>
> > The main benefit of running a DPMI application in Ring3 rather than Ring0
> > is, that if a dead loop with decreasing stack pointer occurs (very stupid
> > and very popular bug), in Ring0 it unavoidably runs into a TripleFault,
> > while with application in in Ring3 the DPMI host easily can clean up the trouble.
But that's YOUR typical style ... :-D

> I found a very interesting (critical/criminal) BUG in Ladsoft's
> INFOPAD , occurring if an external DOS based DPMI host on "raw" is
> present. CWSDPMI raises a PageFault - see shot:
[snip]
> With HDPMI32, the bug becomes even more mallicious :clap: :
 [snip]
> Seems that something (damaging HDPMI code in low memory ?) pushes HDPMI
> into such a self-destructive activity :clap:
[snip]
> Any ideas what could be the reason of the bug ? Low memory corruption ?
A crash in a real-mode callback (RMCB) is always somewhat dangerous, because the InDOS flag might be set, making a proper termination "impossible".

However, the most stupid contributor to the unrecoverable crash possibly is a "known" bug in CuteMouse. It doesn't "allow" an application to crash inside a mouse event proc. Did you also test without/another mouse driver? For example the very good one from Microsoft?

---
MS-DOS forever!
DOS386

12.01.2008, 02:38

@ Japheth
 

TripleFault HDPMI32 | CuteMouse is INNOCENT (exceptionally)

Post reply

> But that's YOUR typical style ...

OH well :-(

> A crash in a real-mode callback (RMCB) is always somewhat dangerous,
> because the InDOS flag might be set, making a proper termination "impossible".
Thanks.

> However, the most stupid contributor to the unrecoverable crash possibly
> is a "known" bug in CuteMouse.

Did you or anyone else write about it before ? I was not aware of it (OTOH that no version of CT or any other mouse driver is 100% bugfree, YES).

> It doesn't "allow" an application to crash inside a mouse event proc.

There was trouble with HX, Blocek, GVFM, ... :-(

> Did you also test without/another mouse driver?
Good idea :-) , results:

HDPMI32, no mouse driver: still TripleFault :no:

CWSDPMI, no mouse driver: hey, seems to start and work ... just the mouse doesn't for unknown reason :lol3:

CWSDPMI, LOGITECH driver 6.50: The very same PF in RMCB :-(

Are RCMB's used in TEXT based mouse controlled apps at all ? :confused: I don't see any in INFOPAD's source :-(

> For example the very good one from Microsoft?
I would rather eat a rat :no: than use a >100 KiB rat driver from M$ :no: :no: :no:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
jaybur

Homepage E-mail

UK,
12.01.2008, 07:59

@ DOS386
 

TripleFault HDPMI32 | CuteMouse is INNOCENT (exceptionally)

Post reply

> Are RMCB's used in TEXT based mouse controlled apps at all ?
> :confused: I don't see any in INFOPAD's source :-(
It all depends on the application. The text-based (DPMI) Borland IDE's for example do, since they use Int33h/0Ch - Mouse Driver - Set Interrupt routine. Some graphical applications such as PQMagic, don't (and it shows).
Japheth

Homepage

Germany (South),
13.01.2008, 08:51
(edited by Japheth, 13.01.2008, 10:12)

@ DOS386
 

No (Cute)Mouse problem, No "raw" mode problem

Post reply

> HDPMI32, no mouse driver: still TripleFault :no:
>
> CWSDPMI, no mouse driver: hey, seems to start and work ... just the mouse
> doesn't for unknown reason :lol3:
>
> CWSDPMI, LOGITECH driver 6.50: The very same PF in RMCB :-(
>
> Are RCMB's used in TEXT based mouse controlled apps at all ?
> :confused: I don't see any in INFOPAD's source :-(
It's obviously not a mouse problem then. Also, you wrote that the crash occurs in "raw" mode only. That's true, but it's just because in "xms" mode - and most likely "VCPI" as well, which I didn't test - the included dos extender doesn't use the external DPMI host.

edit: the triple fault's cause is a host stack overflow, that is, your application loops (real-mode -> real-mode callback -> prot-mode -> real-mode -> ...)

---
MS-DOS forever!
Japheth

Homepage

Germany (South),
14.01.2008, 03:26

@ Japheth
 

SET HDPMI=1 should help

Post reply

> edit: the triple fault's cause is a host stack overflow, that is, your
> application loops (real-mode -> real-mode callback -> prot-mode ->
> real-mode -> ...)
"set hdpmi=1" most likely will avoid the loop. It has been implemented exactly for those DOS extenders which behave paranoid: they except all interrupt and exception vectors and route IRQs from real-mode to protected-mode themselves - apparently they don't trust any external code. The latter thing is dangerous to do, because it's the DPMI host's job.

---
MS-DOS forever!
DOS386

14.01.2008, 10:18

@ Japheth
 

bug in ??? fixed ???

Post reply

Thanks. Ladsoft just released 3.70 :-) and reportedly fixed it. Test now :hungry:
DOS386

14.01.2008, 11:06

@ Japheth
 

HDPMI=1 did help Ladsoft also | DOS/32A is "paranoid" :-(

Post reply

> "set hdpmi=1" most likely will avoid the loop.
YES. Old INFOPAD does no longer TripleFault :lol3:

> It has been implemented exactly for those DOS extenders which behave
> paranoid: they except all interrupt and exception vectors and

Intercept ?

> route IRQs from real-mode to protected-mode themselves - apparently they
> don't trust any external code. The latter thing is dangerous to do,
> because it's the DPMI host's job.
Acceptable idea for interrupts, faulty for exceptions ? :no:

Still strange why only INFOPAD had this bug :confused:

But it's indeed fixed in 3.70 release :clap:, no TripleFault with HDPMI=0, no RCMB Page Fault with CWSDPMI. Regrettably I'm banned from the CC386 forum so I can't ask there soon :crying:

---
This is a LOGITECH mouse driver, but some software expect here
the following string:*** This is Copyright 1983 Microsoft ***
Back to index page
Thread view  Board view
22593 Postings in 2101 Threads, 402 registered users, 33 users online (0 registered, 33 guests)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum