724822 - Crash in XRE_InitEmbedding2 since Firefox 10

Status: RESOLVED WORKSFORME

(Core Graveyard :: Embedding: APIs, defect)

Description

[Friedemann Kunze]

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20100101 Firefox/10.0
Build ID: 20120129021758

Steps to reproduce:

We are using the embedded Gecko engine (https://wiki.mozilla.org/Embedding/NewApi) for rendering. Since Firefox 10 we get a crash while creating (constructor) the MozApp-object. More precisely the crash is by calling the API 'XRE_InitEmbedding2()' (its function-pointer is valid!) in 'InitEmbedding()' of the MozApp constructor in the xul.dll (Fileversion: 10.0.0.4411 BuildID: 20120129021758). Up to version 9 of Firefox we do not have this crash - only since version 10.


Actual results:

Crash in xul.dll - look at the following callstack:
xul!NS_CycleCollectorSuspect2_P+0x3a8
xul!XRE_InitEmbedding2+0x6b
cmll17hr!InitEmbedding+0xac5
cmll17hr!MozApp::MozApp+0x2d
cmll17hr!CMozRenderer::Render+0xfd
cmll17hr!CHrJob::Process+0xe3
cmll17hr!WorkerThreadFunction+0x216
cmll17hr!_AfxThreadEntry+0x2da
cmll17hr!_callthreadstartex+0x53
cmll17hr!_threadstartex+0xa4
kernel32!BaseThreadStart+0x37

Additionally you can find a corresponding dump-file. The module 'cmll17hr.dll' is our calling DLL which is creating the MozApp-object. If you need more information please let me know. It is very important that the problem gets solved.


Expected results:

No Crash should happened.

Comment 1

[Friedemann Kunze]

Sorry, but I'm not able to upload the dump-file as attachment, because it is to large. If you need it, please let me know.

Comment 2

[Benjamin Smedberg]

You need debug symbols to get a useful stack. If you are using a Mozilla-built XULRunner you can use the Mozilla symbol server to get a good stack. I suspect that you'll need to diagnose this bug yourself, and depending on the cause you may need to help provide the patch: embedding typically isn't a strategic priority for the Mozilla project and there aren't a lot of people (either paid or volunteer) who spend a lot of time on it.

Also, it sounds like you're trying to use a binary built against an old version of gecko with a newer version. This isn't supported: we don't provide binary-stable APIs. You should be compiling against the specific version of the gecko SDK that you will be using.

Comment 3

[Friedemann Kunze]

Maybe this callstack is better?
...
xul.dll!nsRefPtr<nsIDOMEventListener>::~nsRefPtr<nsIDOMEventListener>()  Line 907 + 0x2 bytes	C++
xul.dll!nsXREDirProvider::Initialize(nsIFile * aXULAppDir=0x01f15040, nsILocalFile * aGREDir=0x0d000000, nsIDirectoryServiceProvider * aAppProvider=0x00000000)  Line 144	C++
xul.dll!XRE_InitEmbedding2(nsILocalFile * aLibXULDirectory=0x15f15040, nsILocalFile * aAppDirectory=0x00000000, nsIDirectoryServiceProvider * aAppDirProvider=0x0dbbbf84)  Line 190	C++
cmll17hr.dll!InitEmbedding(const char * aProfilePath=0x0dbffb30, const char * aEmbedPath=0x00000000)  Line 282 + 0x1b bytes	C++
cmll17hr.dll!MozApp::MozApp(const char * aProfilePath=0x0dbffb30, const char * aEmbedPath=0x00000000)  Line 91 + 0xd bytes	C++
cmll17hr.dll!CMozRenderer::Render(const wchar_t * lpszUrl=0x0dbfa1e8, int nWidth=514, int nHeight=0)  Line 422 + 0x51 bytes	C++
cmll17hr.dll!CHrJob::Process(CWebBrowserDlg * pWebBrowserDlg=0x0dbff588)  Line 183 + 0x2e bytes	C++
cmll17hr.dll!WorkerThreadFunction(void * __formal=0x00000000)  Line 55	C++
cmll17hr.dll!_AfxThreadEntry(void * pParam=0x0151d6b0)  Line 109 + 0xf bytes	C++
cmll17hr.dll!_callthreadstartex()  Line 348 + 0xf bytes	C
cmll17hr.dll!_threadstartex(void * ptd=0x0dbff8d0)  Line 331	C
kernel32.dll!_BaseThreadStart@8()  + 0x37 bytes	
...

Actually we are linking against the xul-runner-sdk 2.0 (xul.dll 2.0.0.4094) - but installed is Firefox 10.0.2.

If we try to link against the version 10.0.2 (ftp://ftp.mozilla.org/pub/xulrunner/releases/10.0.2/sdk/xulrunner-10.0.2.en-US.win32.sdk.zip) with 
the current available embedded API we got a lot of build errors... ;-(

Does it make sense to spend a lot of time to adapt the embedded API, so it can be used with the current xul-runner SDK or do we have this problems again, e.g. if version 11 
becomes released and the whole work has to be done again? Can you tell me what is the best practice to use the mozilla sources for rendering URLs (in background) to be able to
convert/print the rendered pages to PDF?

Comment 4

[Benjamin Smedberg]

We do not provide a stable binary API for embedding. You must compile against the sources/SDK of whatever release you are actually using. Normally things don't change a whole lot between releases.

Comment 5

[Friedemann Kunze]

Ok, now we adapted the embedding API and it works with xul-runner 10.0.2... but there are two points left - therefore we actually use simple/stupid workarounds to make it work for us - but this is not a good solution (especially for all). You've probably noticed that I am new in developing with the mozilla sources. Can you give me a tip, with whom and where I can discuss these points?

Comment 6

[Benjamin Smedberg]

The mozilla.dev.embedding newsgroup is the best place to ask questions.