93109 - Orphaned #endif's in IDLs crashes xpidl during build

Status: VERIFIED FIXED

(Core :: XPCOM, defect)

Description

[Takayuki Tamura]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.2) Gecko/20010708
BuildID:    20010708

The following IDL sources contain orphaned #endif's at the end.

  editor/idl/nsIEditorIMESupport.idl
  editor/txmgr/idl/nsITransactionManager.idl

The malloc implementation (actually the sanity checking option) of recent
FreeBSDs causes xpidl to crash (segfault) with the above files.

Reproducible: Always
Steps to Reproduce:
1. Revert malloc options to the default on recent FreeBSDs (such as -current).
   (i.e., no /etc/malloc.conf nor $MALLOC_OPTIONS)
2. cd editor/idl
3. ../../dist/bin/xpidl -m header -w -I ../../dist/idl -I. -o
_xpidlgen/nsIEditorIMESupport nsIEditorIMESupport.idl


Actual Results:  Segmentation fault (core dumped)
(No output generated)


Expected Results:  Emit _xpidlgen/nsIEditorIMESupport.{h,xpt}


Workaround patch:
--- editor/idl/nsIEditorIMESupport.idl.orig     Wed Mar 28 08:11:05 2001
+++ editor/idl/nsIEditorIMESupport.idl  Sun Jul  8 12:31:25 2001
@@ -76,4 +76,3 @@
 };
 
 
-#endif // nsIEditorIMESupport_h__
--- editor/txmgr/idl/nsITransactionManager.idl.orig     Fri Mar  9 23:21:32 2001
+++ editor/txmgr/idl/nsITransactionManager.idl  Sun Jul  8 12:25:38 2001
@@ -155,5 +155,4 @@
   void RemoveListener(in nsITransactionListener aListener);
 };
 
-#endif // nsITransactionManager_h__

Comment 1

[David Bradley]

This is most likely a problem in the parser. As such it's not an easy thing to
address and probably hard to justify the effort for a single platform.

These patches need to be given to the owner of nsIEditorIMESupport so the IDL
files can be fixed.

CC'ing mjudge and kin

Comment 2

[kinmoz]

Attachment: Editor diffs.

Comment 3

[kinmoz]

I just attatched the diffs I will be checkin in. I'll find the necessary 
reviewers for the editor portion.

I also did a search through all the idl files in my tree (Note, my tree is from 
07/29/01) with orphaned #endifs. Here's the list I came up with:


mozilla/modules/plugin/base/public/nsIHTTPHeaderListener.idl
mozilla/modules/plugin/base/public/nsIJRILiveConnectPlugInstPeer.idl
mozilla/modules/plugin/base/public/nsIPluginStreamListener.idl
mozilla/modules/plugin/public/nsIHTTPHeaderListener.idl
mozilla/modules/plugin/public/nsIJRILiveConnectPlugInstPeer.idl
mozilla/modules/plugin/public/nsIPluginStreamListener.idl
mozilla/profile/public/nsIProfile.idl
mozilla/profile/public/nsIProfileChangeStatus.idl
mozilla/profile/public/nsIProfileInternal.idl
mozilla/profile/public/nsIProfileStartupListener.idl
mozilla/widget/public/nsIAppShell.idl


Someone will need to contact the owners of these modules/interfaces.

Comment 4

[Chris Waterson]

sr=waterson

Comment 5

[Takayuki Tamura]

Attachment: Fix for an IDL lexer's bug

Comment 6

[Takayuki Tamura]

After tracking down the problem deeper, I found the bug was in libIDL rather
than xpidl itself.
Though I'm gonna notify libIDL or ORBit maintainers, I just attached a patch for
the version of libIDL bundled with the mozilla source (i.e., libIDL-0.6.5).
The patch will make the parser ignore unknown CPP specs silently/safely.

Comment 7

[kinmoz]

Checked editor idl changes into the trunk anyways:

    mozilla/editor/idl/nsIEditorIMESupport.idl          revision 1.2
    mozilla/editor/idl/nsITableEditor.idl               revision 1.2
    mozilla/editor/txmgr/idl/nsITransactionManager.idl  revision 1.3

Comment 8

[David Bradley]

So this essentially isn't a Mozilla bug anymore, save for the #endif's
themselves which Kin checked in. So is it time to mark this bug, as fixed or
something?

Comment 9

[kinmoz]

Takayuki says it's a bug in libIDL, though I don't know if he checked in his 
patch for the version that gets built and run by mozilla ... if he didn't, 
wouldn't it still be a problem?

Comment 10

[John Bandhauer]

Note that the copy of the libIDL source in the mozilla tree is *only* built on
Mac (and was *supposed* to be temporary!). As things stand... Win32 uses the
binary release in wintools.zip and Unix people are expected to get libIDL on
their own. If this libIDL fix were *required* then we'd have to: fix the version
in the tree, see that a new source release of libIDL is available, arrange for a
new binary release to be included in wintools.zip, *and* get everyone to upgrade.

Comment 11

[David Bradley]

To my view, it's not a mozilla bug, it's a libIDL bug. If it gets fixed in
libIDL, and libIDL is updated, then we could consider updating our libIDL, and
doing what jband lays out.

So as I see it, this bug is either fixed because the idl files have been
addressed or, it's invalid because it's a libIDL issue and not a Mozilla issue.

Comment 12

[Takayuki Tamura]

The libIDL patch I sent to gnome.org was finally commited on orbit-stable-0-5
branch (See #58458 at bugzilla.gnome.org).
So, this bug can be closed.

Comment 13

[David Bradley]

I'm marking this fixed, since the IDL has been fixed and the "real" fix is for a
utility used to build Mozilla and not Mozilla itself.

Comment 14

[Phil Schwartau]

Marking Verified -

Comment 15

[Mike Shaver (:shaver emeritus)]

*** Bug 76624 has been marked as a duplicate of this bug. ***