88437 - xpidl.exe crashes during build when .NET Framework is installed

Status: VERIFIED DUPLICATE of bug 123743

(Core :: XPCOM, defect)

Description

[Chad Austin]

Maybe a dup of bug 11195.

After attempting to install VS .NET Beta 1, all of my Mozilla builds would fail
when xpidl.exe would try to access memory at 0x00000010.  After poking around a
bit, I found out that the nmake.exe in VS .NET was in my path earlier than the
one from VC++ 6.

Comment 1

[David Bradley]

Changing this to XPIDL

Comment 2

[David Bradley]

Woops, forgot to give this to myself.

Comment 3

[Chad Austin]

[e-mail] mentioned that if you try to run the xpidl command manually, 
it works.  Inside of nmake 7, however, it GPFs.

The URL for the bug points to the .NET Framework SDK download.

Comment 4

[Chad Austin]

This one is thorn in my side.

Comment 5

[John Bandhauer]

Can you give us a stack trace of the xpidl.exe crash?

Comment 6

[Chad Austin]

Oops, sorry.  It's not nmake that's causing the problem here.  It's cl.exe 7 and
link.exe 7 (I had no idea the .NET Framework SDK came with the new C++
compiler!).  I don't know if the compiler options have changed, or if the build
is using a mix of VS .NET and VC++ 6 executables or what...

Updating summary.
I'll leave this assigned to me, in case I have a chance to look at it.  If
anybody else really feels like fixing it, that's fine by me too.  :)

Comment 7

[Chad Austin]

Oh, and jband:  I couldn't get a stack trace.  Visual C++ 6 wouldn't debug
xpidl.exe if I built with the .NET framework.
Ben:  Maybe try to get a stack trace in VS .NET beta 2?

Comment 8

[David Bradley]

I remember someone else who pulled down the Windows 2000 SDK. They had all kinds
of problems. They ended up excising it from there machine.

Also we link against glib-1.2.lib and libidl-0.6.lib in binary form. I imagine
they might have done something in the new .NET stuff with calling convention or
something that might have hosed things up. I'd suggest building these yourself
if you want to build under VS.

Comment 9

[Jason Kersey]

pushing to 0.9.4 for aegis.  won't make the 0.9.3 train unfortunately...

Comment 10

[Chad Austin]

-> future

It's probably something with cl.exe taking different parameters or something. 
Somehow the new xpidl.exe is different from the one VC++ 6 generates.
At any rate, this will take more time than I thought to investigate.

Comment 11

[Terry J. Deveau]

I have traced this bug to the "IDL_tree_to_IDL" call in xpidl_util.c.
As far as I can tell, this function is only ever called from this one place.
The purpose of this call is to write a comment in the C source code.
Once I commented-out the call to "IDL_tree_to_IDL" the xpidl program stopped 
crashing.

Comment 12

[David Bradley]

Not at all what I would have expected. Would be interesting to see a stack to a
crash. Would tell if it was crashing during the call, or somewhere within.

Comment 13

[hacker formerly known as [e-mail]]

*** This bug has been marked as a duplicate of 123743 ***

Comment 14

[Phil Schwartau]

Verified Duplicate -