DOS ain't dead

1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB (DOSX)

posted by DOS386, 19.06.2008, 09:04
(edited by DOS386 on 19.06.2008, 09:17)

> BUG? What BUG?

Actually IMHO the opposite is true: this is most likely the best bug report this forum has ever seen (have a better one ? point me to it anyone except me uses this forum for reporting bugs at all ? ) I provided a detailed description, reproductability of this bug is always, supplying a test case, a deep analysis - several 1'000'000's bits are involved in this bug ... and I tracked it down to just 1 single bit and detailed solution suggestions ...

> not in the mood to analyze how Fasm converts its
> segment attributes to COFF section attributes.

1:1, as usual, SSSO And it's not the problem anyway - the problem is the read permission bit only, and nothing else. Manually switching this one bit allows me to switch the bug on and off. YES !!! The reproductability of this bug is always

> dpmild32 doesn't care about the PE "readable" bit (IMAGE_SCN_MEM_READ) at all

COOL ... but what does this code do ?

; PELOAD.ASM

;*** support for PE-files ***
;*** 32-Bit DPMI clients only ***

?SKIPCOMMENTS   equ 1   ;std=1, 1=skip sections not marked as r/w/e

if ?SKIPCOMMENTS
  test byte ptr [edi].IMAGE_SECTION_HEADER.Characteristics+3, 0E0h ;is is read/write/exec?
  jz   @F  ; FAR FAR FAR below
endif       
;-------------------------------------------- section size into ecx
                call    getsectionsize       
 
                shr     ecx, 2
                push    edi
                mov     edi,[edi].IMAGE_SECTION_HEADER.VirtualAddress
                lea     edi,[edi + esi - sizeof MZHDR]
                mov     edx,edi
                xor     eax, eax
                rep     stos dword ptr [edi]
                pop     edi

Maybe it skips my evil non-readable section ? Even worse, it doesn't skip only the loading, but also the memory clearing ? Section is not loaded, but then "fixups" are processed, thus, processing ZERO's or random garbage remaining in memory from previous activity ? The bug symptoms indeed depend from previous activity, besides aforementioned black screen, I also get various DKRNL exceptions, see shot.



IMHO the "?SKIPCOMMENTS" "feature" should get deleted, or moved after the clearing at least.

One more good idea would be in DPMILD32 to check the page block fixup sizes for:
- >=8
and
- divisibility by 4
Because a value <8 or not divisible by 4 is obviously evil -> whine ("Can't load, fixups broken" or so) -> file is missbrewed, misslinked, corrupted, crosslinked, etc. BTW, the "PE" thingie has the very same bug: it crashes if the size is ZERO

Well, implementing the fixup check + __always__ section clearing would allow to keep the "?SKIPCOMMENTS" hack enabled

This actually brings us to the next severe bug: memory clearing. DKRNL seems to correctly clear all allocated memory, also DPMILD32 clears __some__ sections (see above), however, besides sections affected by the "?SKIPCOMMENTS" "feature", it doesn't clear the stack, while Windaube seems to do this job - "almost"

      ; ASSUME SS:(1 MiB stack at least)
      mov   ecx,0       ; Skip bytes at the top
      mov   esi,esp
      dec   esi
      sub   esi,ecx
      xor   edx,edx     ; MONVTQ EDX,0 ; Useless
      xor   ebx,ebx     ; MONVTQ EBX,0
      xor   eax,eax     ; MONVTQ EAX,0
      std               ; !!! run down
@@:   lodsb
      inc   ecx
      add   ebx,eax     ; Sum
      cmp   ecx,$100000 ; 1 MiB
      jne   short @b    ; Limited loop [or dead loop] up to the crash
      ud2
      ;----

This sums the garbage in the stack - Win provides an almost clean stack (sum is slightly random, but only cca $8000...$FFFF, located at the top), while with HX the stack is fully random, depending from previous activity Actually I have some apps working poorly with HX, most likely because of this. Failing to initialize variables located in the stack is of course a severe bug of the application, nevertheless, DPMILD32 also contributes here Solution:

- Always clear the stack after allocating it or before starting the application
- Add a hack - bit 14 (DPMILDR=16384) : fill stack with pseudo-random garbage instead of clearing it - this will remove the dependency of bugginess from previous activity , and add a great debugging feature, allowing me to verify my suspect and give me additional ammunition for reporting such application bugs against "Won't fix - Works for me"

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

Complete thread:

• [BUG] unreadable reloXection deadlocks DPMILD32 - DOS386, 12.06.2008, 23:58 (DOSX)
  • BUG? What BUG? - Japheth, 13.06.2008, 08:40
    • BUG? What BUG? - DOS386, 14.06.2008, 15:02
      • BUG? What BUG? - Japheth, 14.06.2008, 15:57
        • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - DOS386, 19.06.2008, 09:04
          • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - DOS386, 19.06.2008, 09:06
          • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - Japheth, 19.06.2008, 10:29
            • 1. Closed: NOT a BUG | 2. Closed: NOT a BUG | 3. Closed: NB - DOS386, 20.06.2008, 09:51
            • Discovered a NEW BUG in DPMILD32 - DOS386, 18.12.2009, 03:21
              • Discovered a NEW BUG in DPMILD32 - Japheth, 19.12.2009, 07:44
                • Discovered a NEW BUG in DPMILD32 - DOS386, 19.12.2009, 14:04