object_attributes constructor bug

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Write following code:
unicode_string us; // not a const_unicode_string
// initialize 'us' by external code (e.g. L"some")...
object_attributes oa(us);
DbgPrint("oa: %d, '%ws'\n", oa.ObjectName->length(), oa.ObjectName-
>data());

2. Compile this code with optimization.
3. Run it under debugger.

What is the expected output?
"4, 'some'"

What do you see instead?
"0, 'null'"

But the following code works fine:
  const_unicode_string cus(us);
  object_attributes oa0(cus);

Original issue reported on code.google.com by icestudent@gmail.com on 14 May 2008 at 12:40

[GoogleCodeExporter]

Original comment by icestudent@gmail.com on 14 May 2008 at 12:41

• Changed title: object_attributes constructor bug

[GoogleCodeExporter]

Unfortunatelly I an not able to reproduce this with cl.exe 8.00.50727.762

// have added a native_string constructor for convenience: template<uint16_t 
Size>native_string(value_type (&str)[Size]); 

wchar_t ws[]= L"some";
unicode_string us(ws); // not a const_unicode_string
object_attributes oa(us);
DbgPrint("oa: %d, '%ws'\n", oa.ObjectName->length(), oa.ObjectName->data());

; Function compile flags: /Ogspy
_ws$ = -12                      ; size = 10
    push    ebp
    mov ebp, esp
    sub esp, 12                 ; 0000000cH
    push    esi
    push    edi
    mov esi, OFFSET $SG-41
    lea edi, DWORD PTR _ws$[ebp]
    movsd
    lea eax, DWORD PTR _ws$[ebp]
    push    eax
    movsd
    push    4
    push    OFFSET $SG-42
    movsw
    call    DWORD PTR __imp__DbgPrint
    add esp, 12                 ; 0000000cH
    pop edi
    or  eax, -1
    pop esi
    leave
    ret 8

---

However the bug is clearly seen in your more complicated example (attached 
files)

   ; 100  : #ifndef BUGGY
    ; 101  :   const_unicode_string cus1(relative1.RelativeName), cusf(fus1);

 !>     mov ax, WORD PTR _relative1$[esp+432]
 !> 
    ; 102  :   object_attributes oa_in1(relative1.ContainingDirectory, cus1), 
oa_in2(cusf);
 <- ; 103  : #else
 <- ; 104  :   object_attributes oa_in1(relative1.ContainingDirectory, 
relative1.RelativeName), oa_in2(fus1);

        mov ecx, DWORD PTR _relative1$[esp+440]
 !>     mov WORD PTR _cus1$[esp+432], ax
 !>     mov ax, WORD PTR _relative1$[esp+434]
 !>     mov WORD PTR _cus1$[esp+434], ax
 !>     mov eax, DWORD PTR _relative1$[esp+436]
 !>     mov DWORD PTR _cus1$[esp+436], eax
 !>     mov ax, WORD PTR _fus1$[esp+432]
 !>     mov WORD PTR _cusf$[esp+432], ax
 !>     mov ax, WORD PTR _fus1$[esp+434]
 !>     mov WORD PTR _cusf$[esp+434], ax
 !>     mov eax, DWORD PTR _fus1$[esp+436]
        push    24                  ; 00000018H
 !>     mov DWORD PTR _cusf$[esp+440], eax
        pop eax
        mov DWORD PTR _oa_in1$[esp+432], eax
        mov DWORD PTR _oa_in2$[esp+432], eax
        push    64                  ; 00000040H
 <!     lea eax, DWORD PTR $T27780[esp+436]
 !>     lea eax, DWORD PTR _cusf$[esp+436]
        mov DWORD PTR _oa_in1$[esp+440], ecx
        pop esi
 <!     lea ecx, DWORD PTR $T27779[esp+432]
 !>     lea ecx, DWORD PTR _cus1$[esp+432]

Both ObjectName member are initialized by pointers to some uninitialized 
variables 
$T27780 and $T27779. I am afraid this may be a optimizer bug since it seems to 
rely 
on the function body size.

P.S. weird issue number :P

Original comment by ntl.supp...@gmail.com on 16 May 2008 at 1:52

• Changed state: Started

Attachments:

• main.asm
• main-buggy.asm

[GoogleCodeExporter]

Fixed in r332.

Original comment by icestudent@gmail.com on 10 Sep 2008 at 6:58

• Changed state: Fixed
• Added labels: Subsystem-NT

[GoogleCodeExporter]

Thanks, it seems you finally catched the bug. However I guess we'd better fix 
every 
possible dead temporary object (const_unicode_string) by removing the copy ctor 
and 
dealing with broken conversion operator. See rev 333

Original comment by ntl.supp...@gmail.com on 10 Sep 2008 at 7:51

[GoogleCodeExporter]

Original comment by icestudent@gmail.com on 9 Nov 2009 at 12:47

• Changed state: Verified