Closed Bug 88437 Opened 23 years ago Closed 22 years ago

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

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 123743
Milestone:
Future

People

(Reporter: caustin, Assigned: caustin)

References

(
URL
)

Details

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.
Changing this to XPIDL
Status: NEW → ASSIGNED
Component: XPCOM → xpidl
Woops, forgot to give this to myself.
Assignee: kandrot → dbradley
Status: ASSIGNED → NEW
QA Contact: scc → pschwartau
ben@netscape.com 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.
URL: http://msdn.microsoft.com/downloads/d...
This one is thorn in my side.
Assignee: dbradley → aegis
Target Milestone: --- → mozilla0.9.3
Can you give us a stack trace of the xpidl.exe crash?
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.  :)
Summary: xpidl.exe crashes when using nmake.exe from the .NET Framework → xpidl.exe crashes during build when .NET Framework is installed
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?

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.

pushing to 0.9.4 for aegis.  won't make the 0.9.3 train unfortunately...
Target Milestone: mozilla0.9.3 → mozilla0.9.4
-> 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.
Target Milestone: mozilla0.9.4 → Future
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.
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.

*** This bug has been marked as a duplicate of 123743 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Verified Duplicate -
Status: RESOLVED → VERIFIED
Component: xpidl → XPCOM
QA Contact: pschwartau → xpcom
You need to log in before you can comment on or make changes to this bug.