Closed Bug 79731 Opened 24 years ago Closed 24 years ago

mfcembed causes IPF in module WEBBRWSR.DLL

Categories

(Core Graveyard :: Embedding: APIs, defect, P1)

x86
Windows 98
defect

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: bmartin, Assigned: chak)

Details

(Keywords: smoketest)

Attachments

(3 files)

latest mfcembed dated: 05-09-01 O/S: win98 System: Dell Latitude CPi 400MHz 128MB RAM Steps: 1. Download latest embed-win32.zip and unzip file 2. Launch mfcembed.exe Results: Mfcembed caused invalid page fault in module webbrwsr.dll at 0167:60b034ed
Seems like a packaging issue since we're missing the DOMScriptObjectFactory Embed packaging. Cc:ing jst to find out the required file name etc. Here's the stack trace: nsDebug::Assertion(const char * 0x01bb1e88, const char * 0x01bb1e80, const char * 0x01bb1e4c, int 4843) line 290 + 13 bytes nsDebug::WarnIfFalse(const char * 0x01bb1e88, const char * 0x01bb1e80, const char * 0x01bb1e4c, int 4843) line 396 + 21 bytes nsDocShell::EnsureScriptEnvironment(nsDocShell * const 0x00efea50) line 4843 + 38 bytes nsWebShell::GetInterface(nsWebShell * const 0x00efea74, const nsID & {...}, void * * 0x0012f2b8) line 332 + 19 bytes nsGetInterface::operator()(const nsID & {...}, void * * 0x0012f2b8) line 37 + 31 bytes nsCOMPtr<nsIDOMWindow>::assign_from_helper(const nsCOMPtr_helper & {...}, const nsID & {...}) line 971 + 18 bytes nsCOMPtr<nsIDOMWindow>::nsCOMPtr<nsIDOMWindow>(const nsCOMPtr_helper & {...}) line 553 nsWebBrowser::GetContentDOMWindow(nsWebBrowser * const 0x00efa080, nsIDOMWindow * * 0x0012f32c) line 325 + 37 bytes nsDocShellTreeOwner::AddToWatcher() line 332 + 42 bytes nsWebBrowser::Create(nsWebBrowser * const 0x00efa090) line 836 CBrowserView::CreateBrowser() line 229 + 26 bytes CBrowserView::OnCreate(tagCREATESTRUCTA * 0x0012f758) line 145 CWnd::OnWndMsg(unsigned int 1, unsigned int 0, long 1242968, long * 0x0012f600) line 1811 + 13 bytes
this is part of smoketests.
Keywords: smoketest
QA Contact: mdunn → bmartin
This seems related to the other blocker today, 79711... Could very well be that both are packaging issues...
I copied the jsdom.dll,jsurl.dll and jsurl.xpt to the embed package but now i'm seeing another assert at http://lxr.mozilla.org/seamonkey/source/dom/src/events/nsJSEventListener.cpp#128 What other files are needed for the packaging?
The DOM needs all it's dom*.xpt files to work now, make sure those files are installed (they might be linked into some other .xpt file).
So, jst, does this mean that mfcembed packaging script needs to be update?
jst wrote: > make sure those files are installed (they might be linked into some other .xpt file). What would be better is you could give me the list of dom .xpt files which are needed since you're the expert in this area. Once i have the list i'll update the package files
Priority: -- → P1
Target Milestone: --- → mozilla0.9.1
did someone add files to the build and not update the packaging files, or is this part of the xpcdom landing yesterday?
Jon: The new dom changes added new files to the build, but, the Embed packaging files basebrowser-win and basebrowser-unix at embedding/config dir were never updated to include the required files.
In addition to the jsurl.xpt here are all the dom*.xpt files. jst/jud : What the are the must have files as far as embedding packaging is concerned? D:\mozilla_src\mozilla\dist\WIN32_D.OBJ\bin\components>dir dom*.xpt Volume in drive D has no label. Volume Serial Number is B01B-34DF Directory of D:\mozilla_src\mozilla\dist\WIN32_D.OBJ\bin\components 05/09/01 12:48p 604 dom.xpt 05/09/01 12:47p 7,057 dom_base.xpt 05/09/01 12:48p 4,783 dom_core.xpt 05/09/01 12:48p 8,677 dom_css.xpt 05/09/01 12:48p 4,935 dom_events.xpt 05/09/01 12:48p 15,906 dom_html.xpt 05/09/01 12:48p 1,267 dom_range.xpt 05/09/01 12:48p 716 dom_stylesheets.xpt 05/09/01 12:48p 226 dom_views.xpt 05/09/01 12:48p 498 dom_xbl.xpt 05/09/01 12:48p 2,125 dom_xul.xpt
Not sure if this is relevant, but this morning 2001-05-09 gtkEmbed didn't expose this bug. How can that be if basebrowser-unix is missing the new DOM files?
Cc:ing blizzard for jj's gtkEmbed question
I'll have blizzard tell me what to do with basebrowser-unix. Also, we still need to decide if we need all of the dom*.xpt for embed packaging. Please let me know what's not needed, if any, and i'll update the patch
Chak, pink pchen if you need help getting the information you need. This is a smoketest blocker bug and should be fixed asap, especially on a "landing day" (tree will probably stay closed for most of the afternoon now :-( Should this bug really be assigned to Adam Lock ? (no input from him so far, and status is still "NEW")
Can we apply this patch to a build machine to quickly test this out?
->chak jj/pchen : I've tried the patch and it works. If i get an r=/sr=/a= i can go ahead and check it in, so the tree can be opened. We can remove the extra files at a later time
Assignee: adamlock → chak
Status: NEW → ASSIGNED
r=valeski. please investigate which files are *needed* after we get this in.
ok Chak, go ahead and check it in, then let me konw so i can run a "repackage-only" on the build machine. a=jj
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
What do you need from me on unix? It should be pretty easy to do. Just do the same thing for unix except use .so.
jj mentioned that he was not seeing this issue with gtkEmbed from this mornings build. Just wanted to make sure from you that these changes are needed to the unix manifests as well...
Attached patch Patch to basebrowser-unix (deleted) — Splinter Review
r=blizzard
verified fixed with mfcembed
Status: RESOLVED → VERIFIED
a=jj for the Unix patch. Should go in after the tree opens later today (despite the 'blocker' severity)
For the record, the only dom .xpt file you might not need in an embedding installation is dom_xul.xpt, but that's only 2125 bytes...
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: